diff options
| author | Tamas Blummer <tamas@bitsofproof.com> | 2014-12-15 14:06:32 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-12-15 13:06:42 +0000 |
| commit | 10854f8777a032587448f0deec05ed23a7b0d28d (patch) | |
| tree | e4d6a8c8d4496abe2b9ca98db40fd99978ed0b24 | |
| parent | 0b7a2abafef7c92f466c1c65cb7c8f18cd98269c (diff) | |
| download | pi-bitcoindev-10854f8777a032587448f0deec05ed23a7b0d28d.tar.gz pi-bitcoindev-10854f8777a032587448f0deec05ed23a7b0d28d.zip | |
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
| -rw-r--r-- | ad/4468bf3fee8f0d5f7933b1cd0da794a876fc65 | 262 |
1 files changed, 262 insertions, 0 deletions
diff --git a/ad/4468bf3fee8f0d5f7933b1cd0da794a876fc65 b/ad/4468bf3fee8f0d5f7933b1cd0da794a876fc65 new file mode 100644 index 000000000..a22b1836c --- /dev/null +++ b/ad/4468bf3fee8f0d5f7933b1cd0da794a876fc65 @@ -0,0 +1,262 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <tamas@bitsofproof.com>) id 1Y0VMI-0004aK-NI + for bitcoin-development@lists.sourceforge.net; + Mon, 15 Dec 2014 13:06:42 +0000 +X-ACL-Warn: +Received: from wp059.webpack.hosteurope.de ([80.237.132.66]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) + (Exim 4.76) id 1Y0VMG-0004Vx-IF + for bitcoin-development@lists.sourceforge.net; + Mon, 15 Dec 2014 13:06:42 +0000 +Received: from [37.143.74.116] (helo=[192.168.0.101]); authenticated + by wp059.webpack.hosteurope.de running ExIM with esmtpsa + (TLS1.0:RSA_AES_128_CBC_SHA1:16) + id 1Y0VM9-0005xl-Pi; Mon, 15 Dec 2014 14:06:33 +0100 +Content-Type: multipart/signed; + boundary="Apple-Mail=_FB760CE6-E0E4-4E53-B917-6B6144B0B6CF"; + protocol="application/pgp-signature"; micalg=pgp-sha512 +Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) +From: Tamas Blummer <tamas@bitsofproof.com> +In-Reply-To: <20141215123942.GA28381@savin.petertodd.org> +Date: Mon, 15 Dec 2014 14:06:32 +0100 +Message-Id: <709AAA00-A40A-42EF-A17D-9B3E07FE902A@bitsofproof.com> +References: <417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com> + <CA+s+GJAe9MeO+Sr0+2BRwu3q-Be5JQt_s_xdnBBEcquXqOyxcA@mail.gmail.com> + <20141211120916.E912EE22B92@quidecco.de> + <B8D7AE7E-567E-4656-9231-17EEAD6ED603@bitsofproof.com> + <AEDF060A-17E7-4519-950A-30974D1520E3@bitsofproof.com> + <20141215123942.GA28381@savin.petertodd.org> +To: Peter Todd <pete@petertodd.org> +X-Mailer: Apple Mail (2.1878.6) +X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1418648800; + e44f5a56; +X-Spam-Score: 1.0 (+) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, + no trust [80.237.132.66 listed in list.dnswl.org] + 1.0 HTML_MESSAGE BODY: HTML included in message +X-Headers-End: 1Y0VMG-0004Vx-IF +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Merged mining a side chain with proof of + burn on parent chain +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Mon, 15 Dec 2014 13:06:42 -0000 + + +--Apple-Mail=_FB760CE6-E0E4-4E53-B917-6B6144B0B6CF +Content-Type: multipart/alternative; + boundary="Apple-Mail=_5F22290B-0424-492B-867E-BE02C7840005" + + +--Apple-Mail=_5F22290B-0424-492B-867E-BE02C7840005 +Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; + charset=windows-1252 + +Peter, + +Thanks for the research, I am glad that the idea, that proof-of-burn can = +=93transfer" proof-of-work=20 +was discussed earlier, as those discussions give some attack vectors = +that I can reevaluate in=20 +a new context, that is side chains.=20 + +I think that the lottery component I suggested, makes it much more = +resilient to =93outspend=94 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 <pete@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. +>>=20 +>> I am puzzled by the lack of feedback on the idea. +>=20 +> It's not a new idea actually - I outlined a system I eventually called +> "zookeyv"=B9 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: +>=20 +> https://download.wpsoftware.net/bitcoin/wizards/2013/05/13-05-29.log +>=20 +> I later wrote up the idea in the context of adding Zerocoin to = +Bitcoin: +>=20 +> = +http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg0= +2472.html +>=20 +> 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.=B2 +>=20 +> 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!) +>=20 +> 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. +>=20 +>=20 +> 1) In honor of Zooko's triangle. +>=20 +> 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}. +>=20 +> --=20 +> 'peter'[:-1]@petertodd.org +> 000000000000000018d439a78581d2a9ecd762a2b37dd5b403a82beb58dcbc7c + + +--Apple-Mail=_5F22290B-0424-492B-867E-BE02C7840005 +Content-Transfer-Encoding: quoted-printable +Content-Type: text/html; + charset=windows-1252 + +<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = +charset=3Dwindows-1252"></head><body style=3D"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 =93transfer" = +proof-of-work </div><div>was discussed earlier, as those = +discussions give some attack vectors that I can reevaluate = +in </div><div>a new context, that is side = +chains. </div><div><br></div><div>I think that the lottery = +component I suggested, makes it much more resilient to =93outspend=94 = +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=3D"true"> +<div style=3D"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=3D"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 <<a = +href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>> = +wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = +type=3D"cite">On Mon, Dec 15, 2014 at 11:21:01AM +0100, Tamas Blummer = +wrote:<br><blockquote type=3D"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"=B9 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=3D"https://download.wpsoftware.net/bitcoin/wizards/2013/05/13-05-29.l= +og">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.sour= +ceforge.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.=B2<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> can work backwards from = +the most recent block(s) if the scheme<br> requires block = +B_i to include the decryption key for block B_{i-1}.<br><br>-- = +<br>'peter'[:-1]@petertodd.org<br>000000000000000018d439a78581d2a9ecd762a2= +b37dd5b403a82beb58dcbc7c<br></blockquote></div><br></body></html>= + +--Apple-Mail=_5F22290B-0424-492B-867E-BE02C7840005-- + +--Apple-Mail=_FB760CE6-E0E4-4E53-B917-6B6144B0B6CF +Content-Transfer-Encoding: 7bit +Content-Disposition: attachment; + filename=signature.asc +Content-Type: application/pgp-signature; + name=signature.asc +Content-Description: Message signed with OpenPGP using GPGMail + +-----BEGIN PGP SIGNATURE----- +Comment: GPGTools - https://gpgtools.org + +iQEcBAEBCgAGBQJUjtzYAAoJEPZykcUXcTkcspQH/iIohpunKCq2JMdI9RCjehHy +7YA+TMliFl25beX5AOum0TiXS1j4xnKKYeEkOoff0CnlvFqO95Ii0UgT6wW9iBU8 +l77RiHd4tF+loEvlYs7KfhfRBJ4VkxTvJBH7cJ1bOJtrmlgC1MAV3P8Bj+BI+sv3 +CHn7+OkoJkviuvIwZOJYiPXXLM2zp1P7EUJ3yb/QS7ye1NovvHQzOo6VEnH+HwqQ +iKsyEqK2X4me41ahjlqtUcZi577PERsjGtv1P4G7fV+ZTVYiQ7k9FkWoz6mhndqp +XrySeS2kw8vPkN+v6W6G8lkEwXG1kj19LtkLqzC9e7qcj4PYJ7+Ec2/Z4MAyXyE= +=74tg +-----END PGP SIGNATURE----- + +--Apple-Mail=_FB760CE6-E0E4-4E53-B917-6B6144B0B6CF-- + + |