Segwit2Mb - combined soft/hard fork - Request For Comments



Summary:

Sergio Demian Lerner has proposed a solution to the ongoing conflict within the Bitcoin community regarding segwit activation vs. an increase of the on-chain blockchain space through a standard block size increase. His proposal, called Segwit2Mb, combines SegWit with a 2MB block size hard-fork activated ONLY if SegWit activates (95% of miners signaling), but at a fixed future date. The objective of this proposal is to re-unite the Bitcoin community and avoid a cryptocurrency split. The tentative lock-in and hard-fork dates are April 29th, 2017 for Bit 2 signaling StartTime, August 29th, 2017 for Bit 2 signaling Timeout, and December 14th, 2017 for HardForkTime.The hard-fork is conditional to 95% of the hashing power approving the SegWit2Mb soft-fork and the segwit soft-fork being activated. Once SegWit is activated, the hard-fork is unavoidable. Sergio suggested that instead of having a significant discontinuity in block size increase, the hard fork activate technical changes, and then slowly increasing the block size over the following several years keeps things nice and continuous and also keeps us from having to revisit the old blocksize debate again six months after activation.Regarding Matt Corallo's message about technical changes, Sergio stated that he has read every proposal that was published in the last two years and the choice for NOT implementing any of the super cool research cited is intentional. Sergio also suggested that the hard forking date could be moved forward. Sergio agreed to consider utilizing the "hard fork signaling bit" in the nVersion of the block, adding simple replay protection, and tweaking the witness discount and possibly discounting other parts of the input. However, he stated that additional commitments at the top of the merkle root and making FindAndDelete runtime and memory usage issues were out of the scope of SegWit2Mb.Lerner concludes by stating that if SegWit2Mb locks-in before the hard-fork occurs, all Bitcoin nodes should be updated to a SegWit2Mb enabled node to prevent them from being forked-away in a chain with almost no hashing-power. He personally wants to see the Lightning Network in action this year, use the non-malleability features in SegWit, see the community discussing other exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechains and MAST. Sergio believes in the strength of a unified Bitcoin community and encourages developers to give their opinion, suggest changes, audit it, and take a stand to unlock the current Bitcoin deadlock. Contributions to the SegWit2Mb project are welcomed and awaited, but improvements unrelated to a 2 Mb increase or SegWit should not be part of SegWit2Mb. Finally, Lerner notes that the proposal should not prevent other consensus proposals from being simultaneously merged: SegWit2Mb is a last resort solution in case we cannot reach consensus on anything better.In his post, he argues that no more than 91% of the network nodes reported by Bitnodes are active economic nodes, as prior to the release of Bitcoin Core 0.12, constant manual intervention was required for any Bitcoin automatic payment system to operate. He suggests that we can expect a similar or lower time to upgrade for a hard-fork, after developers have discussed and approved the patch, and it has been reviewed and merged and 95% of the hashing power has signaled for it. He also suggests delaying the hard-fork date if there is a real need to do so, and states that most of the community agree that halting innovation for several years is a bad option. Technologies like Lightning, TumbleBit, and even RootStock could significantly reduce fee pressure as transactions move to much faster and more featureful systems.


Updated on: 2023-06-11T23:11:09.811354+00:00