Published on: 2017-07-14T13:50:14+00:00
Recently in the Bitcoin community, concerns have been raised about the urgency of a consensus change and the reasons for not delaying it until a better-engineered solution can be deployed. Sergio Demian Lerner from the bitcoin-dev team has updated the technical specifications of the Bitcoin Improvement Proposal (BIP), specifying the block size increase in terms of weight and documenting the maximum block sigops after the hard fork. He urges users to start signaling something before block 475776. There is a discussion on the mailing list about the code to support the hard fork, with some members claiming it has been tested for much longer than a year, while others argue that it has not been properly tested yet.Block 475776 is mentioned as an important milestone before August 1st, and Sergio Demian Lerner emphasizes the need to start signaling before this block. The email exchange also includes a debate between Jorge Timón and Tom Zander about the testing of the code to support the hard fork. Timón believes that any hard fork should wait at least a year after the release of tested code, while Zander claims that the code has been tested for much longer than that. However, Zander clarifies that the code is different on top of segwit and that the first attempt did not even increase the size.The discussion also touches on the issue of the N² hashing problem and proposes soft-forking solutions to address it. The suggested maximum transaction size limit is not considered ideal but is seen as a good starting point. A worst-case scenario for block size is mentioned, and the blame is placed on the Segwit discount factor. The proposed solution is to remove the discount factor altogether and add a fixed discount for each input with respect to outputs. The email thread also mentions the need to redefine the signal "segsignal" in the modified BIP91 proposal.Another email exchange focuses on the responsibility of implementing a hard fork without sufficient testing. Jorge Timón argues that any hard fork should wait at least a year after the release of tested code, while Tom Zander claims that the code to support the hard fork has been tested for much longer than that. However, Zander admits that the code is different on top of segwit and has not been properly tested yet.Luke Dashjr expresses his belief that a hard fork attempt for Bitcoin would fail even with Core's support. He questions the accuracy of claims that more than 80% of miners and users are willing to go in the Segwit2x direction. Dashjr also discusses the issue of a temporary split without Core and expresses his disagreement with Sergio Demian Lerner's approach. He suggests that the only way to achieve a united Bitcoin today would be through Segwit+Drivechain, not Segwit+Hardfork.There is also discussion about the proposed Bitcoin Improvement Proposal (BIP) that matches the reference code published by the Segwit2x group. The timeline and political aspects of the proposal are debated, including concerns about hard forks requiring consensus from the entire ecosystem and the potential for confusion, harm, and fund loss. The email thread includes opposition to the proposal due to its short timeline and lack of detail. Strong opposition is expressed towards the draft proposal for a Bitcoin hard fork, citing concerns about technical, ethical, and process-related issues. The rushed timeline, lack of consensus, and insufficient detail in the draft BIP are criticized. The author suggests that coercion has been used behind closed doors to gain support for the proposal and believes the best outcome is for it to be ignored.In summary, there are ongoing discussions in the Bitcoin community regarding the urgency of a consensus change and the need for proper testing before implementing a hard fork. There are debates about the code to support the hard fork, the responsible timeline for a hard fork, and the potential risks and consequences of such a fork. The email exchanges also touch on issues related to the N² hashing problem and propose solutions to address it. Overall, there are differing opinions and concerns within the community regarding the proposed changes.Luke Dashjr, a Bitcoin developer, believes that larger block sizes will not have a significant impact on fee pressure. However, another individual disagrees, stating that larger block sizes will affect fees in the short term. The maximum transaction size has been increased by approximately 81 bytes, allowing for nearly four MB transactions with Segwit transactions not counting witness data. A modified BIP91 is being deployed to activate Segwit, replacing 'segsignal' with 'segwit2x.' If segwit2x activates at block N, then block N+12960 will activate a new weight limit of 8M. Any transaction with a non-witness serialized size exceeding 1,000,000 is considered invalid.Matt Corallo clarifies via email that adding a new limit is a soft fork and not a hard fork.
Updated on: 2023-08-01T21:18:05.782681+00:00