<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Peter,</div><div><br></div><div>Thanks for the research, I am glad that the idea, that proof-of-burn can “transfer" proof-of-work&nbsp;</div><div>was discussed earlier, as those discussions give some attack vectors that I can reevaluate in&nbsp;</div><div>a new context, that is side chains.&nbsp;</div><div><br></div><div>I think that the lottery component I suggested, makes it much more resilient to “outspend” attack, since</div><div>the attacker not only needs to outspend but win the lottery for a reorg. This raises the cost of the attack</div><div>by magnitudes above the regular miner burn cost.</div><div><br></div><div>In addition, I suggest the burn transaction to include the Bitcoin block height, thereby disabling re-use of a burn,</div><div>for a later reorg.</div><br><div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Tamas Blummer</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Bits of Proof</div></div>
<br><div><div>On Dec 15, 2014, at 1:39 PM, Peter Todd &lt;<a href="mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Mon, Dec 15, 2014 at 11:21:01AM +0100, Tamas Blummer wrote:<br><blockquote type="cite">Burn mining side chains might be one of the foundation ideas for that ecosystem, enabling permission-less merge mining for<br>anyone with interest in a side chain.<br><br>I am puzzled by the lack of feedback on the idea.<br></blockquote><br>It's not a new idea actually - I outlined a system I eventually called<br>"zookeyv"¹ based on the notion of sacrificing Bitcoins to achieve<br>consensus a year and a half ago on #bitcoin-wizards. The discussion<br>started here and continued for a few days:<br><br><a href="https://download.wpsoftware.net/bitcoin/wizards/2013/05/13-05-29.log">https://download.wpsoftware.net/bitcoin/wizards/2013/05/13-05-29.log</a><br><br>I later wrote up the idea in the context of adding Zerocoin to Bitcoin:<br><br>http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html<br><br>For key-value mapping I eventually decided that the system didn't<br>necessarily need to be a strict linear blockchain - a directed acyclic<br>graph of commitments had advantages as there needed to be less<br>syncronization between transactions. This also means that the graph<br>doesn't necessarily need to be revealed directly in the blockchain,<br>exposing it to miner censorship. OTOH revealing it makes it easy to<br>determine if an attacker larger than you exists. These days I'd suggest<br>using timelock crypto to defeat miner censorship, while ensuring that in<br>principle consensus over all possible parts of the chain can eventually<br>be reached.²<br><br>Proof-of-sacrifice for consensus has a few weird properties. For<br>instance you can defeat attackers after the fact by simply sacrificing<br>more than the attacker. Not unlike having a infinite amount of mining<br>equipment available with the only constraint being funds to pay for the<br>electricity. (which *is* semi-true with altcoins!)<br><br>As for your specific example, you can improve it's censorship resistance<br>by having the transactions commit to a nonce in advance in some way<br>indistinguishable from normal transactions, and then making the<br>selection criteria be some function of H(nonce | blockhash) - for<br>instance highest wins. So long as the chain selection is based on<br>cumulative difficulty based on a fixed target - as is the case in<br>Bitcoin proper - you should get a proper incentive to publish blocks, as<br>well as the "total work information rachet" effect Bitcoin has against<br>attackers.<br><br><br>1) In honor of Zooko's triangle.<br><br>2) This doesn't necessarily take as much work as you might expect: you<br> &nbsp;&nbsp;can work backwards from the most recent block(s) if the scheme<br> &nbsp;&nbsp;requires block B_i to include the decryption key for block B_{i-1}.<br><br>-- <br>'peter'[:-1]@petertodd.org<br>000000000000000018d439a78581d2a9ecd762a2b37dd5b403a82beb58dcbc7c<br></blockquote></div><br></body></html>