John Dillon [ARCHIVE] on Nostr: 📅 Original date posted:2013-05-13 📝 Original message:-----BEGIN PGP SIGNED ...

📅 Original date posted:2013-05-13
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, May 11, 2013 at 10:22 AM, Adam Back <adam at cypherspace.org> wrote:
> I didnt quite understand the writeup and the references were ambiguous.

No you didn't. :)

What is special about what Peter is proposing is that it is *not* merge-mining.
You see, merge-mining is essentially where you use one PoW for two purposes,
two different blockchains. So you are getting more value from just one unit of
work.

But Peter's coinbase hashcash protocol carefully ensures that the act of mining
the hashcash is guaranteed to cost the miner at least some well-defined amount,
and that amount can be easily calculated by considering the probability that a
block could have been found with the effort required to generate the proof of
work, and the amount of value the miner would have then given away in a
"anyone-can-spend" output. (you may not realize this, but a scriptPubKey with a
single pushdata opcode is always evaluated as true, which means it can be
respent by anyone)

Don't feel bad though, I had to ask him to explain it to me too. :)

> Rivest's PayWord for people who dont know the reference in this context is
> the observation that for a low value micro-payment, you dont mind if you
> only receive a payment 1 time in k so long as the expected payment is n
> after receiving n (eg satoshi sized) payments. Eg like a penny tip jar so
> long as your expected payment is correct long term (win as often as you
> lose) you dont mind. And a fair 100% payout lottery can be fun of itself.

I think you are misremembering. I just checked the paper and PayWord is based
on chains of hashes and you give the receiver a digest and if after n repeated
hashes it is considered to have been worth n*k It is not a probabalistic
scheme.

Incedentally while it is an obvious enough idea, though I didn't see a
reference to it, PayWords can be easily extended with a time-bandwidth
trade-off by using a structure similar to a merkle tree. The roots could be
created from some fixed nonce K and a increaing integer, H(K | n) Then you
would provide a merkle path to the previously agreed upon final digest. So
proof size for your payment would be log(n), and time to check the proof
log(n). Unfortunately setting up the scheme is still 2*n however that only
needs to be done once.

> So let say each email client sends in an email header the head of the

I have to respect a man who after all these years is still thinking
about anti-spam for email. :)

> Maybe one can put the bitcoin hash in DNS with a 5min TTL and have mail
> clients read that to reduce scope for stale mining.

Peter actually made a blockchain headers over DNS system, and a blockchain
headers over twitter system as an April fools joke. See
https://twitter.com/blockheaders

> In this way one can merge mine bitcoin & hashcash to the benefit of the
> recipient (or some beneficiary trusted not to be paying the proceeds to the
> spammer). And in a way that scales to email scale, and does not involve
> installing a bitcoin client in every client, nor mail server.

Blockchain header data may very well be one of the most widely distributed
single data sets in the history of mankind, and most of its closest cousins are
definitions such as the ASCII table or near definitions like the DNS root
servers. Not something with new data every 10 minutes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJRkJZoAAoJEEWCsU4mNhiPtscIAL4eM+reWCfAjw0FAv5c5lwQ
tJvuVgmkCVyVurQLFbMt0hxXiYAFeTJ31uW0QBEdvitzIUAWR4QO/wfqNULAdZoA
RzTCOBTjfFFGQLd7UdRuDSSEvq23oeJCoixbtdGpAmM1ySRvCExkO+fYehNqXEDN
FF1PVv9VPc5KXbDw3mB6l8dkMCLEHmYpkdrNRvHHQMhyLXO8q3Q6H3zDy3YbztZC
rxibYprOtF1Z2dZzIYTWaGoA9ONLqSgOU2J1htj6kastsjW1d3XKIkdU/eRP2cEs
CG2EWyyrm59e4zpYL4BJj0zBMW9+pQQsSvrAtAoAFVdLojsAWBVL0PIQ8h8N6SY=
=+ptH
-----END PGP SIGNATURE-----