I can't think of any resistance to this, but the code, on a tight timeline, isn't going to be easy. Is anyone volunteering for this? On May 29, 2017 6:19 AM, "James Hilliard via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > 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. > > > > > > 
> > BIP: ?
> > Layer: Consensus
> > Title: Compatibility-oriented omnibus proposal
> > Author: Calvin Rechner 
> > Comments-Summary: No comments yet.
> > Comments-URI: ?
> > Status: Draft
> > Type: Standards Track
> > Created: 2017-05-28
> > License: PD
> >
> > > > > > ===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 >