Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UbnEH-0006hh-HM for bitcoin-development@lists.sourceforge.net; Mon, 13 May 2013 07:31:29 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of googlemail.com designates 74.125.83.48 as permitted sender) client-ip=74.125.83.48; envelope-from=john.dillon892@googlemail.com; helo=mail-ee0-f48.google.com; Received: from mail-ee0-f48.google.com ([74.125.83.48]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UbnEG-0007qa-Ct for bitcoin-development@lists.sourceforge.net; Mon, 13 May 2013 07:31:29 +0000 Received: by mail-ee0-f48.google.com with SMTP id c4so3011706eek.35 for ; Mon, 13 May 2013 00:31:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.14.1.7 with SMTP id 7mr32755188eec.41.1368430282044; Mon, 13 May 2013 00:31:22 -0700 (PDT) Received: by 10.223.101.82 with HTTP; Mon, 13 May 2013 00:31:21 -0700 (PDT) In-Reply-To: <20130511102209.GA27823@netbook.cypherspace.org> References: <20130511045342.GA28588@petertodd.org> <20130511102209.GA27823@netbook.cypherspace.org> Date: Mon, 13 May 2013 07:31:21 +0000 Message-ID: From: John Dillon To: Adam Back Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.4 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (john.dillon892[at]googlemail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (john.dillon892[at]googlemail.com) -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UbnEG-0007qa-Ct Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] merged mining hashcash & bitcoin (Re: Coinbase TxOut Hashcash) X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 07:31:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, May 11, 2013 at 10:22 AM, Adam Back 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-----