[Bitcoin-development] merged mining hashcash & bitcoin (Re: Coinbase TxOut Hashcash)

John Dillon john.dillon892 at googlemail.com
Mon May 13 07:31:21 UTC 2013

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

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

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

> 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.
Version: GnuPG v1.4.11 (GNU/Linux)


More information about the bitcoin-dev mailing list