Author: Jared Lee Richardson 2017-06-02 20:13:58
Published on: 2017-06-02T20:13:58+00:00
There is controversy brewing over the decision to include a secondary limit on the block size increase in the segwit + 2mb agreement, as it may not be what most users had in mind. The current 1MB+SegWit testing has shown normal usage results in ~2 or 2.1MB blocks, and users expect a linear increase when Base Size is increased to 2000000 bytes and Total Weight is increased to 8000000 bytes. With normal usage, the expected results would then be ~4 or 4.2MB blocks. Jared suggests that hard data is needed to justify the secondary limitation or it should be left out in favor of a transaction size limit. Shaolin Fry's "Mandatory activation of segwit deployment" is included to cause the existing "segwit" deployment to activate without needing to release a new deployment. Both fast-activation and flag-day activation options serve to prevent unnecessary delays in the network upgrade process, addressing a common criticism of the Scaling Agreement and providing an opportunity for cooperation and unity instead.However, this may cause more controversy as it has tight timelines and requires bit1 signaling only, which may activate bit1 accidental activation without clear signaling for the required bit4 2mb hard fork. Jared suggests that flag day should be modified to accept either bit1 signaling, OR to accept bit4 signaling IF the 80% threshold hasn't been met. Jared thinks this is a minor compromise for BIP148. He also suggests that the aggressiveness of the timelines and the complexity of the merged COOP proposal may require the BIP148 flag day to be pushed back. Calvin Rechner believes that incorporating Luke-Jr's 2MB limit and discount-rebalancing was to satisfy the conditions of the Scaling Agreement while ensuring maximum safety, minimum code discrepancies, and minimum controversy among the community. He suggests that a gradual increase to a larger size cap, especially if it were reasonably conservative, would be wholly in accordance with the Omnibus Proposal if that is what it takes to achieve the cooperation between community, industry, and developers in this critical moment of Bitcoin's history. The purpose of the Omnibus Proposal is to achieve the goals of the Consensus 2017 Scaling Agreement in the most maximally-compatible way. Rechner believes that the most rational option is to join forces and avoid any chain-split potential for as long as possible. Under the Omnibus Proposal, once SegWit is activated, the terms of the hard fork are locked in automatically, set to activate 6 months later. The proposal guarantees that a successful SegWit activation is followed by a hard fork. Beyond enforcing the hard fork rules beginning at block height HardForkHeight, the Omnibus Proposal simply represents compatibility with the existing SegWit-activation deployment approaches. Rechner calls upon the developers and maintainers of the Segwit2x Team to consider and honor the Omnibus Proposal as the guiding approach to their development effort.
Updated on: 2023-06-12T01:26:24.241158+00:00