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

[bitPico]

This is the SegWit2x mailing list; if you desire to discuss the legacy 1x chain this is not the place.

Kind Regards

> On Oct 18, 2017, at 11:43 AM, robtcspierre via Bitcoin-segwit2x <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
> 
> THIS IS A DRAFT
> 
> A lot of anxiety and confusion regarding the future direction of Bitcoin around the 2x fork date has appeared. The potential of a chain split and resulting chaos in the markets keeps coming up repeatedly.
> 
> In here, a comparatively simple change to the legacy ("1x") and 2x chain is proposed that will solve this problem.
> 
> This change is a combination of two soft forks (one on each chain), meaning it will be backwards compatible with all existing clients, no matter on which chain they operate. As a soft fork, it is also an upgrade that solely concerns the Bitcoin miners, needing no further action on part of the users of any touched block chain.
> 
> This change will ensure a smooth transition through the 2x phase of SegWit2x 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 and maximum cumulative difficulty and so forth are left unchanged.
> 
> From the maximum difficulty DOA, a state flag "abandoned" (A) will be calculated, like this:
> 
> If the DOA is empty, A amounts to 'true'. If the DOA is non-empty, the coin base transactions and merkle roots in the DOA will be checked:
> 
> if any transaction merkle roots in any of the DOA block headers indicate that more than just the coin base transaction would be in the merkle tree, A amounts to 'false'. (Requirement 1)
> 
> likewise, if any coin base transaction in the DOA has more than one output 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 be confused with the 2x chain, as the 2x chain has a requirement of having 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 rule is 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 criterion false, a block is to be considered invalid and orphaned.
> 
> 
> 
> Implementing this change on 2x will ensure that each miner is urged to create empty blocks on the legacy chain, assuming a 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 soft fork.
> 
> It is compatible with all old legacy nodes and will cleanly signal that 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 greater than 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, if the checks for proof of work on the block header pass.
> 
> SegWit2X compatible clients will will forward both DOA blocks as well as regular 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
> 
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171021/624094ac/attachment.html>