On Mon, May 13, 2013 at 07:31:21AM +0000, John Dillon wrote: >[with] merge-mining [you get] more value from just one unit of work.
correct. >But Peter's coinbase hashcash protocol carefully ensures [...] the amount >of value the miner would have then given away in a "anyone-can-spend" >output. I think there are 3 choices: 1. merged-mine (almost zero incremental cost as the bitcoin mining return is still earned) 2. destroy bitcoin (hash of public key is all 00s so no computible private key) 3. anyone-can-spend (= first to spend gets coin?) Surely in 3 if you mine the bitcoin its no particular assurance a you will do your best to make sure that it is *you* tht spends it, so it devolves to merged-mine. (Eg delay revealing it for 10 seconds while you broadcast your spend widely) Peter talks about value, but the proof only proves cost equal to bitcoin. Those are not the same thing. And they are so-far non-respendable. I still dont understand what he was saying. If you do please speakup. I think potentially a publicly auditable pooled mining protocol would be a place to start thinking about respendble micropayments. I made a post on the bitcointalk forum outlining how that could be done: https://bitcointalk.org/index.php?topic=1976.msg2035637#msg2035637 if you have a publicly auditable pool, where users can prove to each other outside of the bitcoin transaction log that they contributed a number of shares to a block, those could be traded somehow. Possibly eg with the pool keeping a double-spend db. If the payments are low value, people maybe happy trusting a pool. If the pool cheats, everyone stops using the pool. You rely on the pool not to spend the backing bitcoin blocks. But it remains possible for the pool to cashout people who collected enough shares. Probably you could do that with blinding if desired. >> [probabilistic micro-payments] > >I think you are misremembering [...] It is not a probabalistic scheme. You are right I was thinking of Rivest's peppercoin. >> 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. Well there doesnt need to be a one-true-blockchain DNS, though the power to output a hash at any reasonable rate is a big proportion of the network power. And the outputs are instantly verifiable, so it forms a kind of trapdoor hashchain (where the trap door is not a secret but havng a huge amount of CPU power). And there can and should be many blockchain via DNS. For namesaces in general another approach other than DHT/flood is numerous competing hierarchical, heavily cached, but publicly auditable. Cheaters are shunned. Same effect, more scalable, most people are not cheating most of the time. http://cypherspace.org/p2p/auditable-namespace.html Adam ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development