Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 364952C for ; Mon, 29 May 2017 22:52:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f169.google.com (mail-qt0-f169.google.com [209.85.216.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 59516F3 for ; Mon, 29 May 2017 22:52:38 +0000 (UTC) Received: by mail-qt0-f169.google.com with SMTP id c13so58472918qtc.1 for ; Mon, 29 May 2017 15:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=USuq383BiMKsYiXqZtf2R9thbTuGnjPdYgsb+h2LCHI=; b=nXXnKYNPS9KDTrVDFIb72m0QY03CqVQk53XT5vdUaPzhcPoXihimVhNjiOGxDXZUTv kbwz46QENUxnCd2SdsSCBBMY84Fx8qAmssIALAgV1ux042NffqBlAxRCvbfG4mQjMOCQ 6Naw3WVEuuoCtGHvWttjOPuhgpRcDA7d36JVpnVMbpBZr7N4Ony4Un3ZkfNZ2phf4Tn3 FPrVGpjflRZOuoKSL0g/Dp4xX8aJLigBloCUv6sU4b6O+3HF7gpwmkaaeiL5tFCsd9ip vNXDp3IR3YmAVf1IOJSclIstF9zjeXcY5rhMjdqQXglrpDY0H2Icv7lgz/i94yOKfVoU +osg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=USuq383BiMKsYiXqZtf2R9thbTuGnjPdYgsb+h2LCHI=; b=SmrUpIewB4gFS3PGxSs3x0f3f79XPq9Dr27ZhLZl1aK2mKLp/Egu9OYDaxhyYgCZUW finnVU07Y2hDKSfPs7rk12aNu4BvgEShF8ApDBaa2IsQZRP2bqOGNIVAN0Re31m+EoG8 FPL/k/EyWE66WCmHnjHHrYFMT7Y9K2MIazcrecmk0jos2KDCZSRDD3WVY4SF2fFzJF68 JaNgufu4eXVCBbi8uDgC7I2y1uwpmwyo3SoWCdXI/vax+RV/wMCdq7ApzcjVI5zC1a/m s/JPVBJJZZ6BjxpbgYPQTFVfa/ixKhGEZuMZqXhgKCYQ1bYVQlrmXO7fR8XLkF/GsVwB T62g== X-Gm-Message-State: AODbwcCzTlALNzT4kazom5wkaRGzo5+gAGnZuFlV8XCDM7vQ8TpGJ0Rb sqvOufQRS9I+jl3h4c5QFbRp1WlvAg== X-Received: by 10.237.55.106 with SMTP id i97mr21491559qtb.68.1496098357416; Mon, 29 May 2017 15:52:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.102 with HTTP; Mon, 29 May 2017 15:52:36 -0700 (PDT) Received: by 10.237.48.102 with HTTP; Mon, 29 May 2017 15:52:36 -0700 (PDT) Reply-To: erik@q32.com In-Reply-To: References: From: Erik Aronesty Date: Mon, 29 May 2017 18:52:36 -0400 Message-ID: To: James Hilliard Content-Type: multipart/alternative; boundary="001a11472ba024988c0550b18bfa" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 29 May 2017 23:14:09 +0000 Cc: Bitcoin Protocol Discussion , CalvinRechner Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 22:52:40 -0000 --001a11472ba024988c0550b18bfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 t= he > > Consensus 2017 Scaling Agreement[1] are genuinely committed to the term= s > 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 an= d > > reviewed in a separate downstream repository. However, it is written wi= th > > 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
> >
> > > > > > =3D=3D=3DAbstract=3D=3D=3D > > > > This document describes a virtuous combination of James Hilliard=E2=80= =99s > =E2=80=9CReduced > > signalling threshold activation of existing segwit deployment=E2=80=9D[= 2], > Shaolin > > Fry=E2=80=99s =E2=80=9CMandatory activation of segwit deployment=E2=80= =9D[3], Sergio Demian > Lerner=E2=80=99s > > =E2=80=9CSegwit2Mb=E2=80=9D[4] proposal, Luke Dashjr=E2=80=99s =E2=80= =9CPost-segwit 2 MB block size > > hardfork=E2=80=9D[5], and hard fork safety mechanisms from Johnson Lau= =E2=80=99s > > =E2=80=9CSpoonnet=E2=80=9D[6][7] into a single omnibus proposal and pat= chset. > > > > > > =3D=3D=3DMotivation=3D=3D=3D > > > > The Consensus 2017 Scaling Agreement[1] stipulated the following > > commitments: > > > > =E2=80=A2 Activate Segregated Witness at an 80% threshold, signaling at= bit 4 > > =E2=80=A2 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 t= he > > risks of a destructive chain split. Additionally, subsequent indication= s > 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. > > > > > > =3D=3D=3DRationale=3D=3D=3D > > > > To the extent possible, this represents an effort at a best-of-all-worl= ds > > 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=E2=80=99s =E2=80=9CReduced signalling threshold activati= on of existing > segwit > > deployment=E2=80=9D[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=E2=80=99s =E2=80=9CMandatory activation of segwit deploymen= t=E2=80=9D[3] is included > to: > > > >> cause the existing "segwit" deployment to activate without needing to > >> release a new deployment. > > > > Both of the aforementioned activation options (=E2=80=9Cfast-activation= =E2=80=9D and > > =E2=80=9Cflag-day activation=E2=80=9D) serve to prevent unnecessary del= ays 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=E2=80=99s =E2=80=9CSegwit2Mb=E2=80=9D[4] proposal = explains the reasoning > behind > > linking SegWit=E2=80=99s activation with that of a later hard fork bloc= k 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=E2=80=99s =E2=80=9CPost-segwit 2 MB block size hardfork=E2= =80=9D[5] suggestions are > > included to reduce the marginal risks that such an increase in the bloc= k > > 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=E2=80=99s 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. > > > > > > =3D=3D=3DCopyright=3D=3D=3D > > > > This document is placed in the public domain. > > > > > > =3D=3D=3DSpecification=3D=3D=3D > > > > ###Proposal Signaling### > > > > The string =E2=80=9CCOOP=E2=80=9D 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 signa= l > 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 nVersio= n > > header top 3 bits to 001 together with bit field (1<<1) (according to t= he > > 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 =3D SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280) > > > > For blocks equal to or higher than HardForkHeight, Luke-Jr=E2=80=99s le= gacy > 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 signalli= ng > > 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. > > > > > > =3D=3D=3DDeployment=3D=3D=3D > > > > Deployment of the =E2=80=9Cfast-activation=E2=80=9D soft fork is exactl= y identical to > > Hilliard=E2=80=99s segsignal proposal[2]. Deployment of the =E2=80=9Cfl= ag-day=E2=80=9D soft fork > is > > exactly identical to Fry=E2=80=99s BIP148 proposal[3]. HardForkHeight i= s 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 2= MB > > hard fork. > > > > > > =3D=3D=3DBackwards compatibility=3D=3D=3D > > > > This deployment is compatible with the existing "segwit" bit 1 deployme= nt > > 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. > > > > > > =3D=3D=3DReferences=3D=3D=3D > > > > [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 > --001a11472ba024988c0550b18bfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can't think of any resistance to this, but the code= , on a tight timeline, isn't going to be easy. =C2=A0 Is anyone volunte= ering 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
<bitcoin-dev@li= sts.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 ter= ms of
> the agreement, and intend to enact the updates described therein. As s= uch,
> criticisms pertaining to the chosen deployment timeline or hard fork u= pgrade
> path should be treated as out-of-scope during the initial discussion o= f this
> proposal.
>
> Because it includes the activation of a hard fork for which community<= br> > 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 a= nd
> reviewed in a separate downstream repository. However, it is written w= ith
> the intent to remain cleanly compatible with future network updates an= d
> changes, to allow for the option of a straightforward upstream merge i= f
> community consensus for the proposal is successfully achieved in the > following months.
>
>
> <pre>
> BIP: ?
> Layer: Consensus
> Title: Compatibility-oriented omnibus proposal
> Author: Calvin Rechner <calvinrechner@protonmail.com>
> Comments-Summary: No comments yet.
> Comments-URI: ?
> Status: Draft
> Type: Standards Track
> Created: 2017-05-28
> License: PD
> </pre>
>
>
> =3D=3D=3DAbstract=3D=3D=3D
>
> This document describes a virtuous combination of James Hilliard=E2=80= =99s =E2=80=9CReduced
> signalling threshold activation of existing segwit deployment=E2=80=9D= [2], Shaolin
> Fry=E2=80=99s =E2=80=9CMandatory activation of segwit deployment=E2=80= =9D[3], Sergio Demian Lerner=E2=80=99s
> =E2=80=9CSegwit2Mb=E2=80=9D[4] proposal, Luke Dashjr=E2=80=99s =E2=80= =9CPost-segwit 2 MB block size
> hardfork=E2=80=9D[5], and hard fork safety mechanisms from Johnson Lau= =E2=80=99s
> =E2=80=9CSpoonnet=E2=80=9D[6][7] into a single omnibus proposal and pa= tchset.
>
>
> =3D=3D=3DMotivation=3D=3D=3D
>
> The Consensus 2017 Scaling Agreement[1] stipulated the following
> commitments:
>
> =E2=80=A2 Activate Segregated Witness at an 80% threshold, signaling a= t bit 4
> =E2=80=A2 Activate a 2 MB hard fork within six months
>
> This proposal seeks to fulfill these criteria while retaining maximum<= br> > compatibility with existing deployment approaches, thereby minimizing = the
> risks of a destructive chain split. Additionally, subsequent indicatio= ns of
> implied criteria and expectations of the Agreement[8][9] are satisfied= .
>
> The proposed hard fork incorporates a legacy witness discount and 2MB<= br> > blocksize limit along with the enactment of Spoonnet-derived protectio= nary
> measures, to ensure the safest possible fork activation within the
> constraints of the requirements outlined in the Scaling Agreement.
>
>
> =3D=3D=3DRationale=3D=3D=3D
>
> To the extent possible, this represents an effort at a best-of-all-wor= lds
> 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<= br> > rationales:
>
> James Hilliard=E2=80=99s =E2=80=9CReduced signalling threshold activat= ion of existing segwit
> deployment=E2=80=9D[2] explains:
>
>> The goal here is to minimize chain split risk and network disrupti= on while
>> maximizing backwards compatibility and still providing for rapid a= ctivation
>> of segwit at the 80% threshold using bit 4.
>
> Shaolin Fry=E2=80=99s =E2=80=9CMandatory activation of segwit deployme= nt=E2=80=9D[3] is included to:
>
>> cause the existing "segwit" deployment to activate witho= ut needing to
>> release a new deployment.
>
> Both of the aforementioned activation options (=E2=80=9Cfast-activatio= n=E2=80=9D and
> =E2=80=9Cflag-day activation=E2=80=9D) serve to prevent unnecessary de= lays in the network
> upgrade process, addressing a common criticism of the Scaling Agreemen= t and
> providing an opportunity for cooperation and unity instead.
>
> Sergio Demian Lerner=E2=80=99s =E2=80=9CSegwit2Mb=E2=80=9D[4] proposal= explains the reasoning behind
> linking SegWit=E2=80=99s activation with that of a later hard fork blo= ck size
> increase:
>
>> Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2= MB block
>> size hard-fork activated ONLY if segwit activates (95% of miners s= ignaling
>> ... to re-unite the Bitcoin community and avoid a cryptocurrency s= plit.
>
> Luke Dashjr=E2=80=99s =E2=80=9CPost-segwit 2 MB block size hardfork=E2= =80=9D[5] suggestions are
> included to reduce the marginal risks that such an increase in the blo= ck
> size might introduce:
>
>> if the community wishes to adopt (by unanimous consensus) a 2 MB b= lock
>> size hardfork, this is probably the best way to do it right now...= Legacy
>> Bitcoin transactions are given the witness discount, and a block s= ize limit
>> of 2 MB is imposed.
>
> Johnson Lau=E2=80=99s anti-replay and network version updates[6][7] ar= e included as
> general hard fork safety measures:
>
>> In a blockchain split, however, since both forks share the same hi= storical
>> ledger, replay attack would be possible, unless some precautions a= re taken.
>
>
> =3D=3D=3DCopyright=3D=3D=3D
>
> This document is placed in the public domain.
>
>
> =3D=3D=3DSpecification=3D=3D=3D
>
> ###Proposal Signaling###
>
> The string =E2=80=9CCOOP=E2=80=9D is included anywhere in the txn-inpu= t (scriptSig) of the
> coinbase-txn to signal compatibility and support.
>
> ###Soft Fork###
>
> Fast-activation (segsignal):=C2=A0 deployed by a "version bits&qu= ot; with an 80%
> activation threshold BIP9 with the name "segsignal" and usin= g bit 4... [with
> a] start time of midnight June 1st, 2017 (epoch time 1496275200) and t= imeout
> 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 mus= t set
> the nVersion header top 3 bits to 001 together with bit field (1<&l= t;1)
> (according to the existing segwit deployment). Blocks that do not sign= al as
> required will be rejected... This BIP will be active between midnight = August
> 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoc= h time
> 1510704000) if the existing segwit deployment is not locked-in or acti= vated
> before epoch time 1501545600. This BIP will cease to be active when se= gwit
> is locked-in. While this BIP is active, all blocks must set the nVersi= on
> header top 3 bits to 001 together with bit field (1<<1) (accordi= ng to the
> existing segwit deployment). Blocks that do not signal as required wil= l be
> rejected.[3]
>
> ###Hard Fork###
>
> The hard fork deployment is scheduled to occur 6 months after SegWit > activates:
>
> (HardForkHeight =3D SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280)
>
> For blocks equal to or higher than HardForkHeight, Luke-Jr=E2=80=99s l= egacy 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 signall= ing
> block
>
> * Hardfork network version bit is 0x02000000. A tx is invalid if the h= ighest
> nVersion byte is not zero, and the network version bit is not set.
>
>
> =3D=3D=3DDeployment=3D=3D=3D
>
> Deployment of the =E2=80=9Cfast-activation=E2=80=9D soft fork is exact= ly identical to
> Hilliard=E2=80=99s segsignal proposal[2]. Deployment of the =E2=80=9Cf= lag-day=E2=80=9D soft fork is
> exactly identical to Fry=E2=80=99s BIP148 proposal[3]. HardForkHeight = is defined as
> 26280 blocks after SegWit is set to ACTIVE. All blocks with height gre= ater
> than or equal to this value must adhere to the consensus rules of the = 2MB
> hard fork.
>
>
> =3D=3D=3DBackwards compatibility=3D=3D=3D
>
> This deployment is compatible with the existing "segwit" bit= 1 deployment
> scheduled between midnight November 15th, 2016 and midnight November 1= 5th,
> 2017.
>
> To prevent the risk of building on top of invalid blocks, miners shoul= d
> 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, afte= r
> which backwards compatibility is waived as enforcement of the hard for= k
> consensus ruleset begins.
>
>
> =3D=3D=3DReferences=3D=3D=3D
>
> [1]
> https://mediu= m.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe= 9a77
> [2]
> https://lists.linux= foundation.org/pipermail/bitcoin-dev/2017-May/014380.html
> [3] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
> [4]
> https://lists.lin= uxfoundation.org/pipermail/bitcoin-dev/2017-March/013921.html=
> [5]
> https://lists.linux= foundation.org/pipermail/bitcoin-dev/2017-May/014399.html
> [6]
> https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.ht= ml
> [7]
> https://lists.l= inuxfoundation.org/pipermail/bitcoin-dev/2017-January/013473.html=
> [8] https://twitter.com/sysmannet/s= tatus/867124645279006720
> [9] https://twitter.com/JihanWu/statu= s/867139046786465792
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.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
--001a11472ba024988c0550b18bfa--