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>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Merged mining a side chain with proof of
	burn	on parent chain
Precedence: list


--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&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 =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 &lt;<a =
href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; =
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> &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>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--