Segwit2Mb - combined soft/hard fork - Request For Comments

Summary:

Bitcoin developer Sergio Demian Lerner has proposed a new solution to the ongoing debate over how to scale the Bitcoin network. The SegWit2Mb proposal aims to combine the activation of Segregated Witness (SegWit) with a hard fork that increases the block size limit from 1MB to 2MB. According to Lerner, this approach should satisfy both those in favour of SegWit and those who want a block size increase. He suggests that once developers have discussed and approved the patch and it has been reviewed and merged and 95% of the hashing power has signaled for it, there could be a similar or lower time to upgrade for a hard fork. However, Lerner believes that if there is a real need to delay the hard fork date then it should be done so. Lerner wants to see the Lightning Network in action this year and use the non-malleability features in SegWit. He also wants to see miners, developers and industry side-by-side pushing Bitcoin forward, to increase the value of Bitcoin and prevent high transaction fees to put out of business use-cases that could have high positive social impact. Lerner believes in the strength of a unified Bitcoin community and is inviting developers to give their opinion, suggest changes, audit it, and take a stand with him to unlock the current Bitcoin deadlock. The proof of concept patch was made for Bitcoin Core but should be easily ported to other Bitcoin protocol implementations that already support versionbits. Lightweight (SPV) wallets should not be affected as they generally do not check the block size. Contributions to the SegWit2Mb project are welcomed and awaited, with the only limitation being to stick to the principle that the patch should be as simple to audit as possible. The proposal should not prevent other consensus proposals to be simultaneously merged: SegWit2Mb is a last resort solution in case we cannot reach consensus on anything better.Lerner said that although he has coded a first version of the segwit2mb patch, he would prefer to wait to publish the source code until more comments have been received from the community. He also mentioned that the current patch does not implement the hard-fork signaling, as requested by Matt. For now, the segwit2mb repo has a single test file using the old internal blockchain building method. This must be replaced soon with a better external test using the bitcoin/qa/rpc-tests tests, which he will begin to work on now after collecting all comments from the community.The hard-fork is conditional to 95% of the hashing power approving the segwit2mb soft-fork, and the segwit soft-fork has been activated. The tentative lock-in and hard-fork dates are April 29th, 2017, August 29th, 2017, and December 14th, 2017, respectively. The proposal does not imply a compromise to the future scalability or decentralization of Bitcoin as a small increase in block size has been proven by several core and non-core developers not to affect Bitcoin value propositions. However, Matt Corallo from Bitcoin-dev has raised concerns about the aggressive hard fork parameters and has suggested some technical changes in terms of pure technical changes like utilizing the "hard fork signaling bit" in the nVersion of the block, replay protection, tweaking the witness discount, and additional commitments at the top of the merkle root, among others. He also pointed out that activating a hard fork with less than 18/24 months from a fully-audited and supported release of full node software to activation date poses significant risks to many large software projects and users. In spite of these concerns, contributions to the SegWit2Mb project are welcomed and awaited. The only limitation is that the patch should be as simple to audit as possible. The proposal should not prevent other consensus proposals to be simultaneously merged: SegWit2Mb is a last resort solution in case we cannot reach consensus on anything better.

Updated on: 2023-06-11T23:08:54.548687+00:00