From: Tamas Blummer <tamas@bitsofproof.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_3F31F3BC-24A3-4B3D-A12D-CA4E69785925";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <C90BC633-9BB0-4886-B818-02980ED3D6C4@bitsofproof.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Date: Tue, 16 Dec 2014 13:30:04 +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>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
In-Reply-To: <417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com>
Subject: Re: [Bitcoin-development] Merged mining a side chain with proof of
	burn on parent chain
Precedence: list


--Apple-Mail=_3F31F3BC-24A3-4B3D-A12D-CA4E69785925
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_18E02D29-AA29-4EB6-BAF1-57F2558051B9"


--Apple-Mail=_18E02D29-AA29-4EB6-BAF1-57F2558051B9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Let me be more concrete in implementation details:=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

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.

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).

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

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

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.

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.

Tamas Blummer
Bits of Proof

On Dec 10, 2014, at 8:35 AM, Tamas Blummer <tamas@bitsofproof.com> =
wrote:

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


--Apple-Mail=_18E02D29-AA29-4EB6-BAF1-57F2558051B9
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>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"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 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></body></html>=

--Apple-Mail=_18E02D29-AA29-4EB6-BAF1-57F2558051B9--

--Apple-Mail=_3F31F3BC-24A3-4B3D-A12D-CA4E69785925
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

iQEcBAEBCgAGBQJUkCXMAAoJEPZykcUXcTkcj4oIALrQ22bNJ8fbE47zvr06QRoR
bUF/4G8QELCV8gUBEaqLhrLeSwJvAFZWjMUWFqVWnhOW/ElIPRWFFXYqhfWJ+ibp
GKyHCGspM4jnKCJY3p/9r83ghEgxuDqMlGU+X6mFCzXhbf10Am+BvDC0Sd5ndUQI
ofyNuZx89D++7AESp54gpCvPb4TaRe3bG9sRSVbdH+F/w5k1l8Kiw8k1rf3AJQa3
E5EmK6RXjA7QQfIAIfNoHF3Dw8rPqmUiY+0vR0gNO1nmNqWOH5a633XQle1EpntZ
Rc7MU5xB3N/mw1x0QGj462ovmVa1jjXi1plRAmo7nNDpmtTQZsaLCM1n/2LYZsg=
=pU3A
-----END PGP SIGNATURE-----

--Apple-Mail=_3F31F3BC-24A3-4B3D-A12D-CA4E69785925--