For the reasons listed here(https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki#Motivation) you should have it so that the HF can not lock in unless the existing BIP141 segwit deployment is activated.
The biggest issue is that a safe HF is very unlikely to be able to be coded and tested within 6 months. On Sun, May 28, 2017 at 8:18 PM, CalvinRechner via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > This proposal is written under the assumption that the signatories to the > Consensus 2017 Scaling Agreement[1] are genuinely committed to the terms of > the agreement, and intend to enact the updates described therein. As such, > criticisms pertaining to the chosen deployment timeline or hard fork upgrade > path should be treated as out-of-scope during the initial discussion of this > proposal. > > Because it includes the activation of a hard fork for which community > consensus does not yet exist, this proposal is not likely to be merged into > Bitcoin Core in the immediate future, and must instead be maintained and > reviewed in a separate downstream repository. However, it is written with > the intent to remain cleanly compatible with future network updates and > changes, to allow for the option of a straightforward upstream merge if > community consensus for the proposal is successfully achieved in the > following months. > > > <pre> > BIP: ? > Layer: Consensus > Title: Compatibility-oriented omnibus proposal > Author: Calvin Rechner <calvinrech...@protonmail.com> > Comments-Summary: No comments yet. > Comments-URI: ? > Status: Draft > Type: Standards Track > Created: 2017-05-28 > License: PD > </pre> > > > ===Abstract=== > > This document describes a virtuous combination of James Hilliard’s “Reduced > signalling threshold activation of existing segwit deployment”[2], Shaolin > Fry’s “Mandatory activation of segwit deployment”[3], Sergio Demian Lerner’s > “Segwit2Mb”[4] proposal, Luke Dashjr’s “Post-segwit 2 MB block size > hardfork”[5], and hard fork safety mechanisms from Johnson Lau’s > “Spoonnet”[6][7] into a single omnibus proposal and patchset. > > > ===Motivation=== > > The Consensus 2017 Scaling Agreement[1] stipulated the following > commitments: > > • Activate Segregated Witness at an 80% threshold, signaling at bit 4 > • Activate a 2 MB hard fork within six months > > This proposal seeks to fulfill these criteria while retaining maximum > compatibility with existing deployment approaches, thereby minimizing the > risks of a destructive chain split. Additionally, subsequent indications of > implied criteria and expectations of the Agreement[8][9] are satisfied. > > The proposed hard fork incorporates a legacy witness discount and 2MB > blocksize limit along with the enactment of Spoonnet-derived protectionary > measures, to ensure the safest possible fork activation within the > constraints of the requirements outlined in the Scaling Agreement. > > > ===Rationale=== > > To the extent possible, this represents an effort at a best-of-all-worlds > proposal, intended to provide a common foundation from which all > mutually-inclusive goals can be achieved while risks are minimized. > > The individual constituent proposals include the following respective > rationales: > > James Hilliard’s “Reduced signalling threshold activation of existing segwit > deployment”[2] explains: > >> The goal here is to minimize chain split risk and network disruption while >> maximizing backwards compatibility and still providing for rapid activation >> of segwit at the 80% threshold using bit 4. > > Shaolin Fry’s “Mandatory activation of segwit deployment”[3] is included to: > >> cause the existing "segwit" deployment to activate without needing to >> release a new deployment. > > Both of the aforementioned activation options (“fast-activation” and > “flag-day activation”) 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. > > Sergio Demian Lerner’s “Segwit2Mb”[4] proposal explains the reasoning behind > linking SegWit’s activation with that of a later hard fork block size > increase: > >> Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB block >> size hard-fork activated ONLY if segwit activates (95% of miners signaling >> ... to re-unite the Bitcoin community and avoid a cryptocurrency split. > > Luke Dashjr’s “Post-segwit 2 MB block size hardfork”[5] suggestions are > included to reduce the marginal risks that such an increase in the block > size might introduce: > >> if the community wishes to adopt (by unanimous consensus) a 2 MB block >> size hardfork, this is probably the best way to do it right now... Legacy >> Bitcoin transactions are given the witness discount, and a block size limit >> of 2 MB is imposed. > > Johnson Lau’s anti-replay and network version updates[6][7] are included as > general hard fork safety measures: > >> In a blockchain split, however, since both forks share the same historical >> ledger, replay attack would be possible, unless some precautions are taken. > > > ===Copyright=== > > This document is placed in the public domain. > > > ===Specification=== > > ###Proposal Signaling### > > The string “COOP” is included anywhere in the txn-input (scriptSig) of the > coinbase-txn to signal compatibility and support. > > ###Soft Fork### > > Fast-activation (segsignal): deployed by a "version bits" with an 80% > activation threshold BIP9 with the name "segsignal" and using bit 4... [with > a] start time of midnight June 1st, 2017 (epoch time 1496275200) and timeout > on midnight November 15th 2017 (epoch time 1510704000). This BIP will cease > to be active when segwit is locked-in.[2] > > Flag-day activation (BIP148): While this BIP is active, all blocks must set > the nVersion header top 3 bits to 001 together with bit field (1<<1) > (according to the existing segwit deployment). Blocks that do not signal as > required will be rejected... This BIP will be active between midnight August > 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoch time > 1510704000) if the existing segwit deployment is not locked-in or activated > before epoch time 1501545600. This BIP will cease to be active when segwit > is locked-in. While this BIP is active, all blocks must set the nVersion > header top 3 bits to 001 together with bit field (1<<1) (according to the > existing segwit deployment). Blocks that do not signal as required will be > rejected.[3] > > ###Hard Fork### > > The hard fork deployment is scheduled to occur 6 months after SegWit > activates: > > (HardForkHeight = SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280) > > For blocks equal to or higher than HardForkHeight, Luke-Jr’s legacy witness > discount and 2MB limit are enacted, along with the following Spoonnet-based > improvements[6][7]: > > * A "hardfork signalling block" is a block with the sign bit of header > nVersion is set [Clearly invalid for old nodes; easy opt-out for light > wallets] > > * If the median-time-past of the past 11 blocks is smaller than the > HardForkHeight... a hardfork signalling block is invalid. > > * Child of a hardfork signalling block MUST also be a hardfork signalling > block > > * Hardfork network version bit is 0x02000000. A tx is invalid if the highest > nVersion byte is not zero, and the network version bit is not set. > > > ===Deployment=== > > Deployment of the “fast-activation” soft fork is exactly identical to > Hilliard’s segsignal proposal[2]. Deployment of the “flag-day” soft fork is > exactly identical to Fry’s BIP148 proposal[3]. HardForkHeight is defined as > 26280 blocks after SegWit is set to ACTIVE. All blocks with height greater > than or equal to this value must adhere to the consensus rules of the 2MB > hard fork. > > > ===Backwards compatibility=== > > This deployment is compatible with the existing "segwit" bit 1 deployment > scheduled between midnight November 15th, 2016 and midnight November 15th, > 2017. > > To prevent the risk of building on top of invalid blocks, miners should > upgrade their nodes to support segsignal as well as BIP148. > > The intent of this proposal is to maintain full legacy consensus > compatibility for users up until the HardForkHeight block height, after > which backwards compatibility is waived as enforcement of the hard fork > consensus ruleset begins. > > > ===References=== > > [1] > https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77 > [2] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014380.html > [3] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki > [4] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013921.html > [5] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014399.html > [6] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html > [7] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013473.html > [8] https://twitter.com/sysmannet/status/867124645279006720 > [9] https://twitter.com/JihanWu/status/867139046786465792 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
