From: Tamas Blummer <tamas@bitsofproof•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Date: Thu, 18 Dec 2014 17:23:53 +0100 [thread overview]
Message-ID: <09D82E62-C816-4BD9-8EE4-8CBD39C946C9@bitsofproof.com> (raw)
In-Reply-To: <C90BC633-9BB0-4886-B818-02980ED3D6C4@bitsofproof.com>
[-- Attachment #1.1: Type: text/plain, Size: 5530 bytes --]
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” of the side chain.
The side chain could use work for regular blocks and a much higher “difficulty” parent chain burn lottery for less frequent “checkpoints".
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’s 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 = 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 “nothing at stake” 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’s 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’s 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 “merged mining” 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
>>
>> 00000000000000001172380e63346e3e915b52fcbae838ba958948ac9aa85edd
>
[-- Attachment #1.2: Type: text/html, Size: 7927 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]
next prev parent reply other threads:[~2014-12-18 16:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-09 21:14 [Bitcoin-development] ACK NACK utACK "Concept ACK" Sergio Lerner
2014-12-09 21:30 ` Matt Corallo
2014-12-10 6:47 ` Wladimir
2014-12-10 7:35 ` [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain Tamas Blummer
2014-12-10 8:30 ` patrick
2014-12-16 9:55 ` Alex Mizrahi
2014-12-16 12:36 ` Peter Todd
2014-12-15 14:55 ` Isidor Zeuner
2014-12-16 8:28 ` Tamas Blummer
2014-12-16 12:30 ` Tamas Blummer
2014-12-18 16:23 ` Tamas Blummer [this message]
2014-12-10 8:21 ` [Bitcoin-development] ACK NACK utACK "Concept ACK" Wladimir
2014-12-10 15:45 ` Austin Walne
2014-12-17 8:44 ` Wladimir
2014-12-10 15:52 ` Jeff Garzik
2014-12-16 23:40 ` Btc Drak
2014-12-11 12:09 ` [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain Isidor Zeuner
2014-12-11 14:56 ` Tamas Blummer
2014-12-15 10:21 ` Tamas Blummer
2014-12-15 12:39 ` Peter Todd
2014-12-15 13:06 ` Tamas Blummer
2015-02-04 13:54 ` Isidor Zeuner
2015-02-06 1:34 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=09D82E62-C816-4BD9-8EE4-8CBD39C946C9@bitsofproof.com \
--to=tamas@bitsofproof$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox