Published on: 2017-05-28T23:28:11+00:00
Tom Zander suggests a solution to the issues with version 0.13.1+ and its segwit related features. He recommends banning older clients and advising them to upgrade. He proposes replacing the bit1 activation code with a bit4 logic based on 80% and no end-date. James Hilliard discusses the issues with SegWit and the need for multiple activation codepaths. Zander argues that one activation codepath based on 80% is sufficient.The development of a hard fork would require months of testing, so it is necessary to wait until BIP141 is active. The fastest path forward would be to use BIP91 to activate BIP141 via mandatory signalling. Then, the hard fork code can be developed assuming BIP141 is active. This staged rollout of segwit followed by a hard fork allows for a single testable upgrade path.Jacob Eliosoff proposes triggering BIP141 signalling when Silbert/NYC Segwit2MB proposal's lock-in supports 80%. Matt Corallo responds, suggesting continued research into meeting the spirit of the agreement. The proposal aims to minimize incompatibility with existing nodes but still has challenges regarding an aggressive hard fork schedule and possible chain splits.The email thread also discusses the feasibility of scheduling a hard fork, the need for compromise, and finding a safe and collaborative solution. Various proposals and activation strategies are mentioned, emphasizing the importance of addressing capacity increase beyond 2MB and replay protection. The writer expresses doubts about Barry Silbert's proposal and suggests activating BIP141 first, then hardforking to 2MB later. Other options such as BIP148 and different activation methods are discussed.On May 22, 2017, a proposal known as the Barry Silbert agreement was shared. This agreement, made between select participants, suggested changing the signaling mechanism to trick people into upgrading their node software to support a hard fork code. James Hilliard proposed an alternative option called BIP148 miner triggered (MASF) with a lower threshold above 50%, which would be compatible with the existing segwit protocol once activated. However, the writer suspects political engineering behind this proposal.The writer has received a copy of the Barry Silbert agreement, which can be found at https://pastebin.com/VuCYteJh. According to the agreement, participants are required to immediately activate Segwit under a different activation proposal. This proposal does not activate BIP141 and instead introduces a completely new deployment that is incompatible with the BIP141 deployment. The reason for this is that they could not convince 95% of the hashpower to trigger activation, so they opted for a lower 80% threshold.There are several options for activating Segwit now, including having 95% of the hashrate signal, deploying BIP148 UASF, redeploying Segwit on a new bit, or implementing the BIP148 miner triggered (MASF) with a lower threshold above 50%. The writer recommends the fourth option, as it lowers the threshold from 95% to 65%, increasing the chances of quick activation. However, this still leaves the activation in the hands of miners, which may have its drawbacks.The writer criticizes the Barry Silbert agreement for being ill-considered and lacking peer review from the technical community. The suggestion of a hard fork in four months is deemed unrealistic and without technical merits. The writer believes that closed-door agreements among selected participants are not the appropriate way to achieve consensus for changing a decentralized system worth $30 billion. The writer aims to assist in the immediate activation of Segwit, which only requires hashrate participation, and is open to all reasonable options that facilitate safe and collaborative progress.
Updated on: 2023-08-01T20:39:47.720027+00:00