From: John Dillon <john.dillon892@googlemail•com>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] merged mining hashcash & bitcoin (Re: Coinbase TxOut Hashcash)
Date: Mon, 13 May 2013 07:31:21 +0000 [thread overview]
Message-ID: <CAPaL=UV7B2ULcUSBBQNWKc70PzGnveeF2WiWQE7msteZ6TZAbQ@mail.gmail.com> (raw)
In-Reply-To: <20130511102209.GA27823@netbook.cypherspace.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sat, May 11, 2013 at 10:22 AM, Adam Back <adam@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-----
next prev parent reply other threads:[~2013-05-13 7:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-11 4:53 [Bitcoin-development] Coinbase TxOut Hashcash Peter Todd
2013-05-11 10:22 ` [Bitcoin-development] merged mining hashcash & bitcoin (Re: Coinbase TxOut Hashcash) Adam Back
2013-05-13 7:31 ` John Dillon [this message]
2013-05-13 10:54 ` Adam Back
2013-05-13 18:38 ` Jeff Garzik
2013-05-13 21:12 ` Adam Back
2013-05-13 22:00 ` Jeff Garzik
2013-05-14 9:25 ` Adam Back
2013-05-14 16:50 ` Jeff Garzik
2013-05-14 20:07 ` Adam Back
2013-05-14 2:30 ` John Dillon
2013-05-14 17:25 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPaL=UV7B2ULcUSBBQNWKc70PzGnveeF2WiWQE7msteZ6TZAbQ@mail.gmail.com' \
--to=john.dillon892@googlemail$(echo .)com \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox