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 <ta...@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 <ta...@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 >
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
