Peter, Thanks for the research, I am glad that the idea, that proof-of-burn can “transfer" proof-of-work was discussed earlier, as those discussions give some attack vectors that I can reevaluate in a new context, that is side chains.
I think that the lottery component I suggested, makes it much more resilient to “outspend” attack, since the attacker not only needs to outspend but win the lottery for a reorg. This raises the cost of the attack by magnitudes above the regular miner burn cost. In addition, I suggest the burn transaction to include the Bitcoin block height, thereby disabling re-use of a burn, for a later reorg. Tamas Blummer Bits of Proof On Dec 15, 2014, at 1:39 PM, Peter Todd <p...@petertodd.org> wrote: > On Mon, Dec 15, 2014 at 11:21:01AM +0100, Tamas Blummer wrote: >> Burn mining side chains might be one of the foundation ideas for that >> ecosystem, enabling permission-less merge mining for >> anyone with interest in a side chain. >> >> I am puzzled by the lack of feedback on the idea. > > It's not a new idea actually - I outlined a system I eventually called > "zookeyv"¹ based on the notion of sacrificing Bitcoins to achieve > consensus a year and a half ago on #bitcoin-wizards. The discussion > started here and continued for a few days: > > https://download.wpsoftware.net/bitcoin/wizards/2013/05/13-05-29.log > > I later wrote up the idea in the context of adding Zerocoin to Bitcoin: > > http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html > > For key-value mapping I eventually decided that the system didn't > necessarily need to be a strict linear blockchain - a directed acyclic > graph of commitments had advantages as there needed to be less > syncronization between transactions. This also means that the graph > doesn't necessarily need to be revealed directly in the blockchain, > exposing it to miner censorship. OTOH revealing it makes it easy to > determine if an attacker larger than you exists. These days I'd suggest > using timelock crypto to defeat miner censorship, while ensuring that in > principle consensus over all possible parts of the chain can eventually > be reached.² > > Proof-of-sacrifice for consensus has a few weird properties. For > instance you can defeat attackers after the fact by simply sacrificing > more than the attacker. Not unlike having a infinite amount of mining > equipment available with the only constraint being funds to pay for the > electricity. (which *is* semi-true with altcoins!) > > As for your specific example, you can improve it's censorship resistance > by having the transactions commit to a nonce in advance in some way > indistinguishable from normal transactions, and then making the > selection criteria be some function of H(nonce | blockhash) - for > instance highest wins. So long as the chain selection is based on > cumulative difficulty based on a fixed target - as is the case in > Bitcoin proper - you should get a proper incentive to publish blocks, as > well as the "total work information rachet" effect Bitcoin has against > attackers. > > > 1) In honor of Zooko's triangle. > > 2) This doesn't necessarily take as much work as you might expect: you > can work backwards from the most recent block(s) if the scheme > requires block B_i to include the decryption key for block B_{i-1}. > > -- > 'peter'[:-1]@petertodd.org > 000000000000000018d439a78581d2a9ecd762a2b37dd5b403a82beb58dcbc7c
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
