[Bitcoin-segwit2x] PROPOSAL: B0RG (Bitcoin zero replay guarantee) - Ensuring a smooth 2X upgrade without a chain split

robtcspier1 at tutanota.com robtcspier1 at tutanota.com
Wed Oct 18 15:43:33 UTC 2017


THIS IS A DRAFT


A lot of anxiety and confusion regarding the future direction ofBitcoin around the 2x fork date has appeared. The potential of a chainsplit and resulting chaos in the markets keeps coming up repeatedly.

In here, a comparatively simple change to the legacy ("1x") and 2xchain is proposed that will solve this problem.

This change is a combination of two soft forks (one on eachchain), meaning it will be backwards compatible with all existingclients, no matter on which chain they operate. As a soft fork, itis also an upgrade that solely concerns the Bitcoin miners, needingno further action on part of the users of any touched block chain.

This change will ensure a smooth transition through the 2x phase ofSegWit2x and ensure just a single chain will emerge.




Principle

The change involves a deliberation of abandonment (DOA) chain,defined as follows:

This DOA is the chain of just block headers and coin base transactions,compatible with the legacy chain rules, starting at the 2x fork point(FP; starting at block height 494,784). All rules for difficulty andmaximum cumulative difficulty and so forth are left unchanged.

>From the maximum difficulty DOA, a state flag "abandoned" (A) will becalculated, like this:

If the DOA is empty, A amounts to 'true'.If the DOA is non-empty, the coin base transactions and merkle roots inthe DOA will be checked:

if any transaction merkle roots in any of the DOA block headersindicate that more than just the coin base transaction would be inthe merkle tree, A amounts to 'false'. (Requirement 1)

likewise, if any coin base transaction in the DOA has more than oneoutput or an output that does not follow a simple TBD "burn"pattern, A amounts to 'false' as well. (Requirement 2)

If the above checks pass, 'A' will be true.




It should be noted here that the DOA chain of headers can not beconfused with the 2x chain, as the 2x chain has a requirement ofhaving a base block being truly bigger than 1000,000 bytes at the FP,contradicting Requirement 1.




To ensure a smooth transaction on the 2x chain, a soft fork ruleis then added to that chain. It simply requires that the DOA criterion, as defined above,evaluates to true.




If this hash is out of date (does not reflect the DOA chain tip) or the DOA criterionfalse, a block is to be considered invalid and orphaned.




Implementing this change on 2x will ensure that each miner isurged to create empty blocks on the legacy chain, assuminga simple 50% majority is willing to upgrade to SegWit2X at the FP. And if not, it will symmetrically cause all miners to stick with the legacy chain - and thus ensure a smooth, continuous operation.




>From the POV of both chains, this appears as a simple, respective softfork.

It is compatible with all old legacy nodes and will cleanly signalthat it is time to upgrade.




Protocol issues




On the network level, the change is conceptually simple. "block"messages will be accepted, both if they fulfill the "must be greaterthan 1MB" rule of the SegWit2X chain, as well as if they don't.

But in the latter case, the messages are added to the DOA chain, ifthe checks for proof of work on the block header pass.

SegWit2X compatible clients will will forward both DOA blocks as well asregular blocks in "block" messages.




Sunset clause

After 3 months, the requirement to keep track of the DOA chain will be dropped.




Activation

The soft forks in this proposal are to be considered active with the simple majority (>50%) of blocks from height 494352 .. 494783 have the uppercase string "B0RG" anywhere in their coin base or by an activation through another, TBD mechanism.





This idea has been posted to reddit a discussion thread as well: https://www.reddit.com/r/btc/comments/775o5q/proposal_b0rg_bitcoin_zero_replay_guarantee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171018/8a5d16df/attachment.html>


More information about the Bitcoin-segwit2x mailing list