diff options
author | Erik Aronesty <earonesty@gmail.com> | 2017-05-29 18:52:36 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-05-29 22:52:40 +0000 |
commit | 1df3cd3c7b42722dc1007a6360dfa2dfcb719471 (patch) | |
tree | 1b5267851a9ce3b4cdf08d8b867a59c78f45bff5 | |
parent | c32caad42b057202d24900c01a28d352cd0f2556 (diff) | |
download | pi-bitcoindev-1df3cd3c7b42722dc1007a6360dfa2dfcb719471.tar.gz pi-bitcoindev-1df3cd3c7b42722dc1007a6360dfa2dfcb719471.zip |
Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
-rw-r--r-- | ab/ca6cb01d37a081917f42e5cc675f4145682593 | 759 |
1 files changed, 759 insertions, 0 deletions
diff --git a/ab/ca6cb01d37a081917f42e5cc675f4145682593 b/ab/ca6cb01d37a081917f42e5cc675f4145682593 new file mode 100644 index 000000000..899f888ce --- /dev/null +++ b/ab/ca6cb01d37a081917f42e5cc675f4145682593 @@ -0,0 +1,759 @@ +Return-Path: <earonesty@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 364952C + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 29 May 2017 22:52:38 +0000 (UTC) +Received: by mail-qt0-f169.google.com with SMTP id c13so58472918qtc.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CADvTj4q2r7sxXfgkdXjgSD5KaEW010aLq8c3YBvqs50FM_ExGg@mail.gmail.com> +References: <aC4avUiJPnHXxIxPlh4w2XA-SLB6ueTUlVTW7TreFwGV12L7L9CAGoB2E9msVYhV0M6xPTERpatAIeZO3kK-ikCRkwYQcJeEMHS7WWZKDAM=@protonmail.com> + <CADvTj4q2r7sxXfgkdXjgSD5KaEW010aLq8c3YBvqs50FM_ExGg@mail.gmail.com> +From: Erik Aronesty <earonesty@gmail.com> +Date: Mon, 29 May 2017 18:52:36 -0400 +Message-ID: <CAJowKgJxCZruMKVESTbguWHDx5Y+KqJKUYDbiv+ZU_SvPdE3Ow@mail.gmail.com> +To: James Hilliard <james.hilliard1@gmail.com> +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 <bitcoin-dev@lists.linuxfoundation.org>, + CalvinRechner <calvinrechner@protonmail.com> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 +> <bitcoin-dev@lists.linuxfoundation.org> 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. +> > +> > +> > <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 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 + +<div dir=3D"auto">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?</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= +te">On May 29, 2017 6:19 AM, "James Hilliard via bitcoin-dev" <= +;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists= +.linuxfoundation.org</a>> wrote:<br type=3D"attribution"><blockquote cla= +ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= +dding-left:1ex">For the reasons listed<br> +here(<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0091.mediaw= +iki#Motivation" rel=3D"noreferrer" target=3D"_blank">https://github.com/<wb= +r>bitcoin/bips/blob/master/bip-<wbr>0091.mediawiki#Motivation</a>)<br> +you should have it so that the HF can not lock in unless the existing<br> +BIP141 segwit deployment is activated.<br> +<br> +The biggest issue is that a safe HF is very unlikely to be able to be<br> +coded and tested within 6 months.<br> +<br> +On Sun, May 28, 2017 at 8:18 PM, CalvinRechner via bitcoin-dev<br> +<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li= +sts.<wbr>linuxfoundation.org</a>> wrote:<br> +> This proposal is written under the assumption that the signatories to = +the<br> +> Consensus 2017 Scaling Agreement[1] are genuinely committed to the ter= +ms of<br> +> the agreement, and intend to enact the updates described therein. As s= +uch,<br> +> criticisms pertaining to the chosen deployment timeline or hard fork u= +pgrade<br> +> path should be treated as out-of-scope during the initial discussion o= +f this<br> +> proposal.<br> +><br> +> 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<br> +> Bitcoin Core in the immediate future, and must instead be maintained a= +nd<br> +> reviewed in a separate downstream repository. However, it is written w= +ith<br> +> the intent to remain cleanly compatible with future network updates an= +d<br> +> changes, to allow for the option of a straightforward upstream merge i= +f<br> +> community consensus for the proposal is successfully achieved in the<b= +r> +> following months.<br> +><br> +><br> +> <pre><br> +> BIP: ?<br> +> Layer: Consensus<br> +> Title: Compatibility-oriented omnibus proposal<br> +> Author: Calvin Rechner <<a href=3D"mailto:calvinrechner@protonmail.= +com">calvinrechner@protonmail.com</a>><br> +> Comments-Summary: No comments yet.<br> +> Comments-URI: ?<br> +> Status: Draft<br> +> Type: Standards Track<br> +> Created: 2017-05-28<br> +> License: PD<br> +> </pre><br> +><br> +><br> +> =3D=3D=3DAbstract=3D=3D=3D<br> +><br> +> This document describes a virtuous combination of James Hilliard=E2=80= +=99s =E2=80=9CReduced<br> +> signalling threshold activation of existing segwit deployment=E2=80=9D= +[2], Shaolin<br> +> Fry=E2=80=99s =E2=80=9CMandatory activation of segwit deployment=E2=80= +=9D[3], Sergio Demian Lerner=E2=80=99s<br> +> =E2=80=9CSegwit2Mb=E2=80=9D[4] proposal, Luke Dashjr=E2=80=99s =E2=80= +=9CPost-segwit 2 MB block size<br> +> hardfork=E2=80=9D[5], and hard fork safety mechanisms from Johnson Lau= +=E2=80=99s<br> +> =E2=80=9CSpoonnet=E2=80=9D[6][7] into a single omnibus proposal and pa= +tchset.<br> +><br> +><br> +> =3D=3D=3DMotivation=3D=3D=3D<br> +><br> +> The Consensus 2017 Scaling Agreement[1] stipulated the following<br> +> commitments:<br> +><br> +> =E2=80=A2 Activate Segregated Witness at an 80% threshold, signaling a= +t bit 4<br> +> =E2=80=A2 Activate a 2 MB hard fork within six months<br> +><br> +> This proposal seeks to fulfill these criteria while retaining maximum<= +br> +> compatibility with existing deployment approaches, thereby minimizing = +the<br> +> risks of a destructive chain split. Additionally, subsequent indicatio= +ns of<br> +> implied criteria and expectations of the Agreement[8][9] are satisfied= +.<br> +><br> +> The proposed hard fork incorporates a legacy witness discount and 2MB<= +br> +> blocksize limit along with the enactment of Spoonnet-derived protectio= +nary<br> +> measures, to ensure the safest possible fork activation within the<br> +> constraints of the requirements outlined in the Scaling Agreement.<br> +><br> +><br> +> =3D=3D=3DRationale=3D=3D=3D<br> +><br> +> To the extent possible, this represents an effort at a best-of-all-wor= +lds<br> +> proposal, intended to provide a common foundation from which all<br> +> mutually-inclusive goals can be achieved while risks are minimized.<br= +> +><br> +> The individual constituent proposals include the following respective<= +br> +> rationales:<br> +><br> +> James Hilliard=E2=80=99s =E2=80=9CReduced signalling threshold activat= +ion of existing segwit<br> +> deployment=E2=80=9D[2] explains:<br> +><br> +>> The goal here is to minimize chain split risk and network disrupti= +on while<br> +>> maximizing backwards compatibility and still providing for rapid a= +ctivation<br> +>> of segwit at the 80% threshold using bit 4.<br> +><br> +> Shaolin Fry=E2=80=99s =E2=80=9CMandatory activation of segwit deployme= +nt=E2=80=9D[3] is included to:<br> +><br> +>> cause the existing "segwit" deployment to activate witho= +ut needing to<br> +>> release a new deployment.<br> +><br> +> Both of the aforementioned activation options (=E2=80=9Cfast-activatio= +n=E2=80=9D and<br> +> =E2=80=9Cflag-day activation=E2=80=9D) serve to prevent unnecessary de= +lays in the network<br> +> upgrade process, addressing a common criticism of the Scaling Agreemen= +t and<br> +> providing an opportunity for cooperation and unity instead.<br> +><br> +> Sergio Demian Lerner=E2=80=99s =E2=80=9CSegwit2Mb=E2=80=9D[4] proposal= + explains the reasoning behind<br> +> linking SegWit=E2=80=99s activation with that of a later hard fork blo= +ck size<br> +> increase:<br> +><br> +>> Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2= +MB block<br> +>> size hard-fork activated ONLY if segwit activates (95% of miners s= +ignaling<br> +>> ... to re-unite the Bitcoin community and avoid a cryptocurrency s= +plit.<br> +><br> +> Luke Dashjr=E2=80=99s =E2=80=9CPost-segwit 2 MB block size hardfork=E2= +=80=9D[5] suggestions are<br> +> included to reduce the marginal risks that such an increase in the blo= +ck<br> +> size might introduce:<br> +><br> +>> if the community wishes to adopt (by unanimous consensus) a 2 MB b= +lock<br> +>> size hardfork, this is probably the best way to do it right now...= + Legacy<br> +>> Bitcoin transactions are given the witness discount, and a block s= +ize limit<br> +>> of 2 MB is imposed.<br> +><br> +> Johnson Lau=E2=80=99s anti-replay and network version updates[6][7] ar= +e included as<br> +> general hard fork safety measures:<br> +><br> +>> In a blockchain split, however, since both forks share the same hi= +storical<br> +>> ledger, replay attack would be possible, unless some precautions a= +re taken.<br> +><br> +><br> +> =3D=3D=3DCopyright=3D=3D=3D<br> +><br> +> This document is placed in the public domain.<br> +><br> +><br> +> =3D=3D=3DSpecification=3D=3D=3D<br> +><br> +> ###Proposal Signaling###<br> +><br> +> The string =E2=80=9CCOOP=E2=80=9D is included anywhere in the txn-inpu= +t (scriptSig) of the<br> +> coinbase-txn to signal compatibility and support.<br> +><br> +> ###Soft Fork###<br> +><br> +> Fast-activation (segsignal):=C2=A0 deployed by a "version bits&qu= +ot; with an 80%<br> +> activation threshold BIP9 with the name "segsignal" and usin= +g bit 4... [with<br> +> a] start time of midnight June 1st, 2017 (epoch time 1496275200) and t= +imeout<br> +> on midnight November 15th 2017 (epoch time 1510704000). This BIP will = +cease<br> +> to be active when segwit is locked-in.[2]<br> +><br> +> Flag-day activation (BIP148): While this BIP is active, all blocks mus= +t set<br> +> the nVersion header top 3 bits to 001 together with bit field (1<&l= +t;1)<br> +> (according to the existing segwit deployment). Blocks that do not sign= +al as<br> +> required will be rejected... This BIP will be active between midnight = +August<br> +> 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoc= +h time<br> +> 1510704000) if the existing segwit deployment is not locked-in or acti= +vated<br> +> before epoch time 1501545600. This BIP will cease to be active when se= +gwit<br> +> is locked-in. While this BIP is active, all blocks must set the nVersi= +on<br> +> header top 3 bits to 001 together with bit field (1<<1) (accordi= +ng to the<br> +> existing segwit deployment). Blocks that do not signal as required wil= +l be<br> +> rejected.[3]<br> +><br> +> ###Hard Fork###<br> +><br> +> The hard fork deployment is scheduled to occur 6 months after SegWit<b= +r> +> activates:<br> +><br> +> (HardForkHeight =3D SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280)<br> +><br> +> For blocks equal to or higher than HardForkHeight, Luke-Jr=E2=80=99s l= +egacy witness<br> +> discount and 2MB limit are enacted, along with the following Spoonnet-= +based<br> +> improvements[6][7]:<br> +><br> +> * A "hardfork signalling block" is a block with the sign bit= + of header<br> +> nVersion is set [Clearly invalid for old nodes; easy opt-out for light= +<br> +> wallets]<br> +><br> +> * If the median-time-past of the past 11 blocks is smaller than the<br= +> +> HardForkHeight... a hardfork signalling block is invalid.<br> +><br> +> * Child of a hardfork signalling block MUST also be a hardfork signall= +ing<br> +> block<br> +><br> +> * Hardfork network version bit is 0x02000000. A tx is invalid if the h= +ighest<br> +> nVersion byte is not zero, and the network version bit is not set.<br> +><br> +><br> +> =3D=3D=3DDeployment=3D=3D=3D<br> +><br> +> Deployment of the =E2=80=9Cfast-activation=E2=80=9D soft fork is exact= +ly identical to<br> +> Hilliard=E2=80=99s segsignal proposal[2]. Deployment of the =E2=80=9Cf= +lag-day=E2=80=9D soft fork is<br> +> exactly identical to Fry=E2=80=99s BIP148 proposal[3]. HardForkHeight = +is defined as<br> +> 26280 blocks after SegWit is set to ACTIVE. All blocks with height gre= +ater<br> +> than or equal to this value must adhere to the consensus rules of the = +2MB<br> +> hard fork.<br> +><br> +><br> +> =3D=3D=3DBackwards compatibility=3D=3D=3D<br> +><br> +> This deployment is compatible with the existing "segwit" bit= + 1 deployment<br> +> scheduled between midnight November 15th, 2016 and midnight November 1= +5th,<br> +> 2017.<br> +><br> +> To prevent the risk of building on top of invalid blocks, miners shoul= +d<br> +> upgrade their nodes to support segsignal as well as BIP148.<br> +><br> +> The intent of this proposal is to maintain full legacy consensus<br> +> compatibility for users up until the HardForkHeight block height, afte= +r<br> +> which backwards compatibility is waived as enforcement of the hard for= +k<br> +> consensus ruleset begins.<br> +><br> +><br> +> =3D=3D=3DReferences=3D=3D=3D<br> +><br> +> [1]<br> +> <a href=3D"https://medium.com/@DCGco/bitcoin-scaling-agreement-at-cons= +ensus-2017-133521fe9a77" rel=3D"noreferrer" target=3D"_blank">https://mediu= +m.com/@DCGco/<wbr>bitcoin-scaling-agreement-at-<wbr>consensus-2017-133521fe= +9a77</a><br> +> [2]<br> +> <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201= +7-May/014380.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux= +foundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2017-May/014380.html</a><br> +> [3] <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0148.me= +diawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/<w= +br>bips/blob/master/bip-0148.<wbr>mediawiki</a><br> +> [4]<br> +> <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201= +7-March/013921.html" rel=3D"noreferrer" target=3D"_blank">https://lists.lin= +uxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2017-March/013921.html</a>= +<br> +> [5]<br> +> <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201= +7-May/014399.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux= +foundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2017-May/014399.html</a><br> +> [6]<br> +> <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201= +7-February/013542.html" rel=3D"noreferrer" target=3D"_blank">https://lists.= +linuxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2017-February/013542.ht= +ml</a><br> +> [7]<br> +> <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201= +7-January/013473.html" rel=3D"noreferrer" target=3D"_blank">https://lists.l= +inuxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2017-January/013473.html= +</a><br> +> [8] <a href=3D"https://twitter.com/sysmannet/status/867124645279006720= +" rel=3D"noreferrer" target=3D"_blank">https://twitter.com/sysmannet/<wbr>s= +tatus/867124645279006720</a><br> +> [9] <a href=3D"https://twitter.com/JihanWu/status/867139046786465792" = +rel=3D"noreferrer" target=3D"_blank">https://twitter.com/JihanWu/<wbr>statu= +s/867139046786465792</a><br> +><br> +><br> +> ______________________________<wbr>_________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= +ists.<wbr>linuxfoundation.org</a><br> +> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= +dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb= +r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br> +><br> +______________________________<wbr>_________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +<wbr>linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= +/mailman/listinfo/bitcoin-<wbr>dev</a><br> +</blockquote></div></div> + +--001a11472ba024988c0550b18bfa-- + |