From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y0rGZ-0000Ke-RR for bitcoin-development@lists.sourceforge.net; Tue, 16 Dec 2014 12:30:15 +0000 X-ACL-Warn: Received: from wp059.webpack.hosteurope.de ([80.237.132.66]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Y0rGX-0001QH-M5 for bitcoin-development@lists.sourceforge.net; Tue, 16 Dec 2014 12:30:15 +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 1Y0rGR-0003RM-67; Tue, 16 Dec 2014 13:30:07 +0100 From: Tamas Blummer Content-Type: multipart/signed; boundary="Apple-Mail=_3F31F3BC-24A3-4B3D-A12D-CA4E69785925"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: 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> <417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com> To: Bitcoin Dev In-Reply-To: <417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com> X-Mailer: Apple Mail (2.1878.6) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1418733013; cbd51ad8; 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: 1Y0rGX-0001QH-M5 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: Tue, 16 Dec 2014 12:30:16 -0000 --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 = 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
Let me be more concrete in implementation = details: 

1) burn transaction sends at = least n satoshis to an OP_RETURN h, 
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. 

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. 

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:


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.

In following I outline a new mining algorithm = for side chains, that burn Bitcoins to secure them.

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.

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.

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

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.

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.

The = difficulty to mine with burn would be dynamic and would also imply a = floating exchange rate between Bitcoin and the side coin.

Tamas = Blummer
Bits of = Proof

00000000000000001172380e63346e3e915b52fcbae838ba958948ac9aa85= edd

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