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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) 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 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> <417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com> To: Bitcoin Dev In-Reply-To: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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 = 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
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. 

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

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

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: 

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