From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 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> <20141211120916.E912EE22B92@quidecco.de> <20141215123942.GA28381@savin.petertodd.org> To: Peter Todd 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
Peter,

Thanks for the = research, I am glad that the idea, that proof-of-burn can =93transfer" = 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 =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.

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"=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:

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.sour= ceforge.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.=B2

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
000000000000000018d439a78581d2a9ecd762a2= b37dd5b403a82beb58dcbc7c

= --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--