path: root/8a/66ce2b6589aed774fb83a092f2b063c204a773

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <tamas@bitsofproof.com>) id 1Y1drx-0000nI-SN
	for bitcoin-development@lists.sourceforge.net;
	Thu, 18 Dec 2014 16:24:05 +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 1Y1drv-0005Pt-6V
	for bitcoin-development@lists.sourceforge.net;
	Thu, 18 Dec 2014 16:24:05 +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 1Y1dro-0000AR-9q; Thu, 18 Dec 2014 17:23:56 +0100
From: Tamas Blummer <tamas@bitsofproof.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_C2FE1BE3-3730-439A-854E-D01D2CF08C72";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <09D82E62-C816-4BD9-8EE4-8CBD39C946C9@bitsofproof.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Date: Thu, 18 Dec 2014 17:23:53 +0100
References: <54876653.4020403@certimix.com> <548769FA.5040406@bluematt.me>
	<CA+s+GJAe9MeO+Sr0+2BRwu3q-Be5JQt_s_xdnBBEcquXqOyxcA@mail.gmail.com>
	<417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com>
	<C90BC633-9BB0-4886-B818-02980ED3D6C4@bitsofproof.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
In-Reply-To: <C90BC633-9BB0-4886-B818-02980ED3D6C4@bitsofproof.com>
X-Mailer: Apple Mail (2.1878.6)
X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1418919843;
	0f336aa6; 
X-Spam-Score: 2.1 (++)
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.1 TRACKER_ID             BODY: Incorporates a tracking ID number
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1Y1drv-0005Pt-6V
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: Thu, 18 Dec 2014 16:24:06 -0000


--Apple-Mail=_C2FE1BE3-3730-439A-854E-D01D2CF08C72
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A720C081-4AC5-4D20-8938-D4BCBFD7D79B"


--Apple-Mail=_A720C081-4AC5-4D20-8938-D4BCBFD7D79B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Moving further with the Idea:

Alternative to re-adjusting the lottery criteria, the side chain block =
candidate could be required to prove a work to be eligible for the burn =
lottery.=20

A mix of required burn, work and luck could be tailored to achieve the =
desired "51% resilience=94 of the side chain.=20

The side chain could use work for regular blocks and a much higher =
=93difficulty=94 parent chain burn lottery for less frequent =
=93checkpoints".=20

Eg. the side chain difficulty of 1/n of Bitcoin is attainable for a =
small side chain miner community to advance its chain at Bitcoin=92s =
speed. Simultaneously the block candidates
would be submitted to a Bitcoin burn lottery with 1/n odds, so the =
security of the side chain roughly equals that of Bitcoin at every =
successful burn mined checkpoint.

Tamas Blummer
Bits of Proof

On Dec 16, 2014, at 1:30 PM, Tamas Blummer <tamas@bitsofproof.com> =
wrote:

> Let me be more concrete in implementation details:=20
>=20
> 1) burn transaction sends at least n satoshis to an OP_RETURN h,=20
> 2) h mod m matches the bitcoin block hash mod m, for the block the =
burn transaction was mined into.
> 3) The side chain block header hashes to h and also contains the =
bitcoin block hight.
> 4) a side chain block releases x new side coins
>=20
> Since the burn hash does not reveal in advance which side chain it =
will be used for, the Bitcoin miner can not selectively block burn =
mining. They will include loosing bets for the Bitcoin fee. Bitcoin =
miner have no advantage over independent burn miner of the side chain.
>=20
> Anyone who issues a burn transaction that complies the rules 1-3 has =
1/m the chance to win the next block on the side chain. This implies a =
fair exchange rate of n*m satoshis =3D x side coins (at the margin).
>=20
> Should two burn transactions fulfill the mod m lottery criteria, then =
we have a competing fork on the side chain. Just as for Bitcoin, the =
next block(s) will pick the winner.=20
>=20
> To contain fork rate, the parameter m would have to be adjusted =
dynamically, similar to Bitcoins difficulty. It needs to increase if =
fork rate increases and decrease if no valid block is burned with =
Bitcoin blocks. Unfortunately SPV can only prove the existence of a =
transaction, but not the non-existence of an alternative. Therefore the =
fork rate within a block cycle can not be evaluated with SPV proofs.=20
>=20
> Rational burn miner who frequently faces and loses head-to-head runs =
with a competing forks would increase his bet for the next burn cycle, =
as increasing the individual bet amount has the advantage that if he =
wins his victory is more stable. Remember the side chain trunk is =
selected as the one with highest cumulative burn.
>=20
> Consequently cumulative burn within an adjustment period (measured in =
Bitcoin blocks) is expected to rise in face of high fork rate. If the =
sample period burn exceeds a target, then it would trigger a rise to the =
lottery criteria m, reducing the fork rate and vs.
>=20
> Tamas Blummer
> Bits of Proof
>=20
> On Dec 10, 2014, at 8:35 AM, Tamas Blummer <tamas@bitsofproof.com> =
wrote:
>=20
>>=20
>> We spend scarce resources external to the digital realm to create =
Bitcoin. Real world sacrifice is needed to avoid =93nothing at stake=94  =
and sybil attacks. With Bitcoin we now have a scarce resource within the =
digital realm, so it appeals my intuition to re-use it for sacrifice =
instead of linking again an external, real world resource.=20
>>=20
>> In following I outline a new mining algorithm for side chains, that =
burn Bitcoins to secure them.
>>=20
>> The side chain block validity rules would require that a transaction =
on the Bitcoin block chain provably destroys Bitcoins with an OP_RET =
output, that contains the hash of the block header of the side chain. To =
also introduce a lottery, the burn transaction=92s hash is required to =
satisfy some function of the block hash it was included in on the =
Bitcoin block chain. For example modulo m of the burn transaction hash =
must match modulo m of the block hash, that is not known in advance.
>>=20
>> Those who want to mine the side chain will assemble  side chain block =
candidates that comply the rules of the side chain, then a Bitcoin =
transaction burning to the hash of the block candidate and submit it to =
the Bitcoin network. Should he burn transaction be included into the =
Bitcoin block chain and the Bitcoin block=92s hash satisfy the lottery =
criteria, then the block candidate can be submitted to extend the side =
chain.
>>=20
>> A side chain block header sequence would be accepted as side chain =
trunk if a sequence of Bitcoin SPV proofs for burn transactions prove, =
that linked blocks have the highest cumulative burn, if compared to =
alternative sequences.=20
>>=20
>> The Bitcoin miner will include burn transactions because they offer =
Bitcoin fees. Bitcoin miner can not selectively block side chains since =
the hashes associated with the burn do not disclose which side chain or =
other project they are for. Here you have a =93merged mining=94 that =
does not need Bitcoin miner support or even consent.
>>=20
>> Mining difficulty of the side chain could be adjusted by stepping up =
the required burn and/or hardening the criteria that links a burn proof =
transaction with the bitcoin block hash it is included in.
>>=20
>> The difficulty to mine with burn would be dynamic and would also =
imply a floating exchange rate between Bitcoin and the side coin.
>>=20
>> Tamas Blummer
>> Bits of Proof
>>=20
>> 00000000000000001172380e63346e3e915b52fcbae838ba958948ac9aa85edd
>=20


--Apple-Mail=_A720C081-4AC5-4D20-8938-D4BCBFD7D79B
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>Moving further with the =
Idea:</div><div><br></div><div>Alternative to re-adjusting the lottery =
criteria, the side chain block candidate could be required to prove a =
work to be eligible for the burn =
lottery.&nbsp;</div><div><br></div><div>A mix of required burn, work and =
luck could be tailored to achieve the desired "51% resilience=94 of the =
side chain.&nbsp;</div><div><br></div><div>The side chain could use work =
for regular blocks and a much higher =93difficulty=94 parent chain burn =
lottery for less frequent =
=93checkpoints".&nbsp;</div><div><br></div><div>Eg. the side chain =
difficulty of 1/n of Bitcoin is attainable for a small side chain miner =
community to advance its chain at Bitcoin=92s speed. Simultaneously the =
block candidates</div><div>would be submitted to a Bitcoin burn lottery =
with 1/n odds, so the security of the side chain roughly equals that of =
Bitcoin at every successful burn mined checkpoint.</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 16, 2014, at 1:30 PM, Tamas Blummer &lt;<a =
href=3D"mailto:tamas@bitsofproof.com">tamas@bitsofproof.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"><div style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div>Let me be more concrete in implementation =
details:&nbsp;</div><div><br></div><div>1) burn transaction sends at =
least n satoshis to an OP_RETURN h,&nbsp;</div><div>2) h mod m matches =
the bitcoin block hash mod m, for the block the burn transaction was =
mined into.</div><div>3) The side chain block header hashes to h and =
also contains the bitcoin block hight.</div><div>4) a side chain block =
releases x new side coins</div><div><br></div><div>Since the burn hash =
does not reveal in advance which side chain it will be used for, the =
Bitcoin miner can not selectively block burn mining. They will include =
loosing bets for the Bitcoin fee. Bitcoin miner have no advantage over =
independent burn miner of the side =
chain.</div><div><br></div><div>Anyone who issues a burn transaction =
that complies the rules 1-3 has 1/m the chance to win the next block on =
the side chain. This implies a fair exchange rate of n*m satoshis =3D x =
side coins (at the margin).</div><div><br></div><div>Should two burn =
transactions fulfill the mod m lottery criteria, then we have a =
competing fork on the side chain. Just as for Bitcoin, the next block(s) =
will pick the winner.&nbsp;</div><div><br></div><div>To contain fork =
rate, the parameter m would have to be adjusted dynamically, similar to =
Bitcoins difficulty. It needs to increase if fork rate increases and =
decrease if no valid block is burned with Bitcoin blocks. Unfortunately =
SPV can only prove the existence of a transaction, but not the =
non-existence of an alternative. Therefore the fork rate within a block =
cycle can not be evaluated with SPV =
proofs.&nbsp;</div><div><br></div><div>Rational burn miner who =
frequently faces and loses head-to-head runs with a competing forks =
would increase his bet for the next burn cycle, as increasing the =
individual bet amount has the advantage that if he wins his victory is =
more stable. Remember the side chain trunk is selected as the one with =
highest cumulative burn.</div><div><br></div><div>Consequently =
cumulative burn within an adjustment period (measured in Bitcoin blocks) =
is expected to rise in face of high fork rate. If the sample period burn =
exceeds a target, then it would trigger a rise to the lottery criteria =
m, reducing the fork rate and vs.</div><div><br></div><div =
apple-content-edited=3D"true">
<div style=3D"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"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 10, 2014, at 8:35 AM, Tamas Blummer &lt;<a =
href=3D"mailto:tamas@bitsofproof.com">tamas@bitsofproof.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><br>We spend scarce resources external to the digital =
realm to create Bitcoin. Real world sacrifice is needed to avoid =
=93nothing at stake=94 &nbsp;and sybil attacks. With Bitcoin we now have =
a scarce resource within the digital realm, so it appeals my intuition =
to re-use it for sacrifice instead of linking again an external, real =
world resource. <br><br>In following I outline a new mining algorithm =
for side chains, that burn Bitcoins to secure them.<br><br>The side =
chain block validity rules would require that a transaction on the =
Bitcoin block chain provably destroys Bitcoins with an OP_RET output, =
that contains the hash of the block header of the side chain. To also =
introduce a lottery, the burn transaction=92s hash is required to =
satisfy some function of the block hash it was included in on the =
Bitcoin block chain. For example modulo m of the burn transaction hash =
must match modulo m of the block hash, that is not known in =
advance.<br><br>Those who want to mine the side chain will assemble =
&nbsp;side chain block candidates that comply the rules of the side =
chain, then a Bitcoin transaction burning to the hash of the block =
candidate and submit it to the Bitcoin network. Should he burn =
transaction be included into the Bitcoin block chain and the Bitcoin =
block=92s hash satisfy the lottery criteria, then the block candidate =
can be submitted to extend the side chain.<br><br>A side chain block =
header sequence would be accepted as side chain trunk if a sequence of =
Bitcoin SPV proofs for burn transactions prove, that linked blocks have =
the highest cumulative burn, if compared to alternative sequences. =
<br><br>The Bitcoin miner will include burn transactions because they =
offer Bitcoin fees. Bitcoin miner can not selectively block side chains =
since the hashes associated with the burn do not disclose which side =
chain or other project they are for. Here you have a =93merged mining=94 =
that does not need Bitcoin miner support or even consent.<br><br>Mining =
difficulty of the side chain could be adjusted by stepping up the =
required burn and/or hardening the criteria that links a burn proof =
transaction with the bitcoin block hash it is included in.<br><br>The =
difficulty to mine with burn would be dynamic and would also imply a =
floating exchange rate between Bitcoin and the side coin.<br><br>Tamas =
Blummer<br>Bits of =
Proof<br><br>00000000000000001172380e63346e3e915b52fcbae838ba958948ac9aa85=
edd<br></blockquote></div><br></div></blockquote></div><br></body></html>=

--Apple-Mail=_A720C081-4AC5-4D20-8938-D4BCBFD7D79B--

--Apple-Mail=_C2FE1BE3-3730-439A-854E-D01D2CF08C72
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

iQEcBAEBCgAGBQJUkv+ZAAoJEPZykcUXcTkcBrwH/31cOuD0rqVe6N0SKSt+IoER
1Xv4IxC8LhtG1kbjX7+fqax9Qzh4MRZwW0ynQ6awC2vokFLi2RYtjKsOvq3Hr33T
LGYX0+R4ZIgbAFx9+M3QH8Ua7a4k6Rv/X7FDigAb+09Gr+OnL5rS0HT12cHGel/y
MpFKaGyGXrBw7DmB0Z3Hk1uubuktvDyLQLcNEE3wFTGhmJiSqjWO5UBTagWPFl19
bHS4pmKZN8k5ST5K0cPe99C5hsWhnW8Sz7nrrq+YSMlWz3gzTc6y91NWF2Ipznvo
BdqAHViNmY+TUEM8o/LO//9axE0EnZG4z1uMOog07lUN5IA1YDzcjVUFXX671J8=
=v5fk
-----END PGP SIGNATURE-----

--Apple-Mail=_C2FE1BE3-3730-439A-854E-D01D2CF08C72--