summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorErik Aronesty <earonesty@gmail.com>2017-05-29 18:52:36 -0400
committerbitcoindev <bitcoindev@gnusha.org>2017-05-29 22:52:40 +0000
commit1df3cd3c7b42722dc1007a6360dfa2dfcb719471 (patch)
tree1b5267851a9ce3b4cdf08d8b867a59c78f45bff5
parentc32caad42b057202d24900c01a28d352cd0f2556 (diff)
downloadpi-bitcoindev-1df3cd3c7b42722dc1007a6360dfa2dfcb719471.tar.gz
pi-bitcoindev-1df3cd3c7b42722dc1007a6360dfa2dfcb719471.zip
Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
-rw-r--r--ab/ca6cb01d37a081917f42e5cc675f4145682593759
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&#39;t think of any resistance to this, but the code=
+, on a tight timeline, isn&#39;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, &quot;James Hilliard via bitcoin-dev&quot; &lt=
+;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
+.linuxfoundation.org</a>&gt; 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>
+&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
+sts.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
+&gt; This proposal is written under the assumption that the signatories to =
+the<br>
+&gt; Consensus 2017 Scaling Agreement[1] are genuinely committed to the ter=
+ms of<br>
+&gt; the agreement, and intend to enact the updates described therein. As s=
+uch,<br>
+&gt; criticisms pertaining to the chosen deployment timeline or hard fork u=
+pgrade<br>
+&gt; path should be treated as out-of-scope during the initial discussion o=
+f this<br>
+&gt; proposal.<br>
+&gt;<br>
+&gt; Because it includes the activation of a hard fork for which community<=
+br>
+&gt; consensus does not yet exist, this proposal is not likely to be merged=
+ into<br>
+&gt; Bitcoin Core in the immediate future, and must instead be maintained a=
+nd<br>
+&gt; reviewed in a separate downstream repository. However, it is written w=
+ith<br>
+&gt; the intent to remain cleanly compatible with future network updates an=
+d<br>
+&gt; changes, to allow for the option of a straightforward upstream merge i=
+f<br>
+&gt; community consensus for the proposal is successfully achieved in the<b=
+r>
+&gt; following months.<br>
+&gt;<br>
+&gt;<br>
+&gt; &lt;pre&gt;<br>
+&gt; BIP: ?<br>
+&gt; Layer: Consensus<br>
+&gt; Title: Compatibility-oriented omnibus proposal<br>
+&gt; Author: Calvin Rechner &lt;<a href=3D"mailto:calvinrechner@protonmail.=
+com">calvinrechner@protonmail.com</a>&gt;<br>
+&gt; Comments-Summary: No comments yet.<br>
+&gt; Comments-URI: ?<br>
+&gt; Status: Draft<br>
+&gt; Type: Standards Track<br>
+&gt; Created: 2017-05-28<br>
+&gt; License: PD<br>
+&gt; &lt;/pre&gt;<br>
+&gt;<br>
+&gt;<br>
+&gt; =3D=3D=3DAbstract=3D=3D=3D<br>
+&gt;<br>
+&gt; This document describes a virtuous combination of James Hilliard=E2=80=
+=99s =E2=80=9CReduced<br>
+&gt; signalling threshold activation of existing segwit deployment=E2=80=9D=
+[2], Shaolin<br>
+&gt; Fry=E2=80=99s =E2=80=9CMandatory activation of segwit deployment=E2=80=
+=9D[3], Sergio Demian Lerner=E2=80=99s<br>
+&gt; =E2=80=9CSegwit2Mb=E2=80=9D[4] proposal, Luke Dashjr=E2=80=99s =E2=80=
+=9CPost-segwit 2 MB block size<br>
+&gt; hardfork=E2=80=9D[5], and hard fork safety mechanisms from Johnson Lau=
+=E2=80=99s<br>
+&gt; =E2=80=9CSpoonnet=E2=80=9D[6][7] into a single omnibus proposal and pa=
+tchset.<br>
+&gt;<br>
+&gt;<br>
+&gt; =3D=3D=3DMotivation=3D=3D=3D<br>
+&gt;<br>
+&gt; The Consensus 2017 Scaling Agreement[1] stipulated the following<br>
+&gt; commitments:<br>
+&gt;<br>
+&gt; =E2=80=A2 Activate Segregated Witness at an 80% threshold, signaling a=
+t bit 4<br>
+&gt; =E2=80=A2 Activate a 2 MB hard fork within six months<br>
+&gt;<br>
+&gt; This proposal seeks to fulfill these criteria while retaining maximum<=
+br>
+&gt; compatibility with existing deployment approaches, thereby minimizing =
+the<br>
+&gt; risks of a destructive chain split. Additionally, subsequent indicatio=
+ns of<br>
+&gt; implied criteria and expectations of the Agreement[8][9] are satisfied=
+.<br>
+&gt;<br>
+&gt; The proposed hard fork incorporates a legacy witness discount and 2MB<=
+br>
+&gt; blocksize limit along with the enactment of Spoonnet-derived protectio=
+nary<br>
+&gt; measures, to ensure the safest possible fork activation within the<br>
+&gt; constraints of the requirements outlined in the Scaling Agreement.<br>
+&gt;<br>
+&gt;<br>
+&gt; =3D=3D=3DRationale=3D=3D=3D<br>
+&gt;<br>
+&gt; To the extent possible, this represents an effort at a best-of-all-wor=
+lds<br>
+&gt; proposal, intended to provide a common foundation from which all<br>
+&gt; mutually-inclusive goals can be achieved while risks are minimized.<br=
+>
+&gt;<br>
+&gt; The individual constituent proposals include the following respective<=
+br>
+&gt; rationales:<br>
+&gt;<br>
+&gt; James Hilliard=E2=80=99s =E2=80=9CReduced signalling threshold activat=
+ion of existing segwit<br>
+&gt; deployment=E2=80=9D[2] explains:<br>
+&gt;<br>
+&gt;&gt; The goal here is to minimize chain split risk and network disrupti=
+on while<br>
+&gt;&gt; maximizing backwards compatibility and still providing for rapid a=
+ctivation<br>
+&gt;&gt; of segwit at the 80% threshold using bit 4.<br>
+&gt;<br>
+&gt; Shaolin Fry=E2=80=99s =E2=80=9CMandatory activation of segwit deployme=
+nt=E2=80=9D[3] is included to:<br>
+&gt;<br>
+&gt;&gt; cause the existing &quot;segwit&quot; deployment to activate witho=
+ut needing to<br>
+&gt;&gt; release a new deployment.<br>
+&gt;<br>
+&gt; Both of the aforementioned activation options (=E2=80=9Cfast-activatio=
+n=E2=80=9D and<br>
+&gt; =E2=80=9Cflag-day activation=E2=80=9D) serve to prevent unnecessary de=
+lays in the network<br>
+&gt; upgrade process, addressing a common criticism of the Scaling Agreemen=
+t and<br>
+&gt; providing an opportunity for cooperation and unity instead.<br>
+&gt;<br>
+&gt; Sergio Demian Lerner=E2=80=99s =E2=80=9CSegwit2Mb=E2=80=9D[4] proposal=
+ explains the reasoning behind<br>
+&gt; linking SegWit=E2=80=99s activation with that of a later hard fork blo=
+ck size<br>
+&gt; increase:<br>
+&gt;<br>
+&gt;&gt; Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2=
+MB block<br>
+&gt;&gt; size hard-fork activated ONLY if segwit activates (95% of miners s=
+ignaling<br>
+&gt;&gt; ... to re-unite the Bitcoin community and avoid a cryptocurrency s=
+plit.<br>
+&gt;<br>
+&gt; Luke Dashjr=E2=80=99s =E2=80=9CPost-segwit 2 MB block size hardfork=E2=
+=80=9D[5] suggestions are<br>
+&gt; included to reduce the marginal risks that such an increase in the blo=
+ck<br>
+&gt; size might introduce:<br>
+&gt;<br>
+&gt;&gt; if the community wishes to adopt (by unanimous consensus) a 2 MB b=
+lock<br>
+&gt;&gt; size hardfork, this is probably the best way to do it right now...=
+ Legacy<br>
+&gt;&gt; Bitcoin transactions are given the witness discount, and a block s=
+ize limit<br>
+&gt;&gt; of 2 MB is imposed.<br>
+&gt;<br>
+&gt; Johnson Lau=E2=80=99s anti-replay and network version updates[6][7] ar=
+e included as<br>
+&gt; general hard fork safety measures:<br>
+&gt;<br>
+&gt;&gt; In a blockchain split, however, since both forks share the same hi=
+storical<br>
+&gt;&gt; ledger, replay attack would be possible, unless some precautions a=
+re taken.<br>
+&gt;<br>
+&gt;<br>
+&gt; =3D=3D=3DCopyright=3D=3D=3D<br>
+&gt;<br>
+&gt; This document is placed in the public domain.<br>
+&gt;<br>
+&gt;<br>
+&gt; =3D=3D=3DSpecification=3D=3D=3D<br>
+&gt;<br>
+&gt; ###Proposal Signaling###<br>
+&gt;<br>
+&gt; The string =E2=80=9CCOOP=E2=80=9D is included anywhere in the txn-inpu=
+t (scriptSig) of the<br>
+&gt; coinbase-txn to signal compatibility and support.<br>
+&gt;<br>
+&gt; ###Soft Fork###<br>
+&gt;<br>
+&gt; Fast-activation (segsignal):=C2=A0 deployed by a &quot;version bits&qu=
+ot; with an 80%<br>
+&gt; activation threshold BIP9 with the name &quot;segsignal&quot; and usin=
+g bit 4... [with<br>
+&gt; a] start time of midnight June 1st, 2017 (epoch time 1496275200) and t=
+imeout<br>
+&gt; on midnight November 15th 2017 (epoch time 1510704000). This BIP will =
+cease<br>
+&gt; to be active when segwit is locked-in.[2]<br>
+&gt;<br>
+&gt; Flag-day activation (BIP148): While this BIP is active, all blocks mus=
+t set<br>
+&gt; the nVersion header top 3 bits to 001 together with bit field (1&lt;&l=
+t;1)<br>
+&gt; (according to the existing segwit deployment). Blocks that do not sign=
+al as<br>
+&gt; required will be rejected... This BIP will be active between midnight =
+August<br>
+&gt; 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoc=
+h time<br>
+&gt; 1510704000) if the existing segwit deployment is not locked-in or acti=
+vated<br>
+&gt; before epoch time 1501545600. This BIP will cease to be active when se=
+gwit<br>
+&gt; is locked-in. While this BIP is active, all blocks must set the nVersi=
+on<br>
+&gt; header top 3 bits to 001 together with bit field (1&lt;&lt;1) (accordi=
+ng to the<br>
+&gt; existing segwit deployment). Blocks that do not signal as required wil=
+l be<br>
+&gt; rejected.[3]<br>
+&gt;<br>
+&gt; ###Hard Fork###<br>
+&gt;<br>
+&gt; The hard fork deployment is scheduled to occur 6 months after SegWit<b=
+r>
+&gt; activates:<br>
+&gt;<br>
+&gt; (HardForkHeight =3D SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280)<br>
+&gt;<br>
+&gt; For blocks equal to or higher than HardForkHeight, Luke-Jr=E2=80=99s l=
+egacy witness<br>
+&gt; discount and 2MB limit are enacted, along with the following Spoonnet-=
+based<br>
+&gt; improvements[6][7]:<br>
+&gt;<br>
+&gt; * A &quot;hardfork signalling block&quot; is a block with the sign bit=
+ of header<br>
+&gt; nVersion is set [Clearly invalid for old nodes; easy opt-out for light=
+<br>
+&gt; wallets]<br>
+&gt;<br>
+&gt; * If the median-time-past of the past 11 blocks is smaller than the<br=
+>
+&gt; HardForkHeight... a hardfork signalling block is invalid.<br>
+&gt;<br>
+&gt; * Child of a hardfork signalling block MUST also be a hardfork signall=
+ing<br>
+&gt; block<br>
+&gt;<br>
+&gt; * Hardfork network version bit is 0x02000000. A tx is invalid if the h=
+ighest<br>
+&gt; nVersion byte is not zero, and the network version bit is not set.<br>
+&gt;<br>
+&gt;<br>
+&gt; =3D=3D=3DDeployment=3D=3D=3D<br>
+&gt;<br>
+&gt; Deployment of the =E2=80=9Cfast-activation=E2=80=9D soft fork is exact=
+ly identical to<br>
+&gt; Hilliard=E2=80=99s segsignal proposal[2]. Deployment of the =E2=80=9Cf=
+lag-day=E2=80=9D soft fork is<br>
+&gt; exactly identical to Fry=E2=80=99s BIP148 proposal[3]. HardForkHeight =
+is defined as<br>
+&gt; 26280 blocks after SegWit is set to ACTIVE. All blocks with height gre=
+ater<br>
+&gt; than or equal to this value must adhere to the consensus rules of the =
+2MB<br>
+&gt; hard fork.<br>
+&gt;<br>
+&gt;<br>
+&gt; =3D=3D=3DBackwards compatibility=3D=3D=3D<br>
+&gt;<br>
+&gt; This deployment is compatible with the existing &quot;segwit&quot; bit=
+ 1 deployment<br>
+&gt; scheduled between midnight November 15th, 2016 and midnight November 1=
+5th,<br>
+&gt; 2017.<br>
+&gt;<br>
+&gt; To prevent the risk of building on top of invalid blocks, miners shoul=
+d<br>
+&gt; upgrade their nodes to support segsignal as well as BIP148.<br>
+&gt;<br>
+&gt; The intent of this proposal is to maintain full legacy consensus<br>
+&gt; compatibility for users up until the HardForkHeight block height, afte=
+r<br>
+&gt; which backwards compatibility is waived as enforcement of the hard for=
+k<br>
+&gt; consensus ruleset begins.<br>
+&gt;<br>
+&gt;<br>
+&gt; =3D=3D=3DReferences=3D=3D=3D<br>
+&gt;<br>
+&gt; [1]<br>
+&gt; <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>
+&gt; [2]<br>
+&gt; <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>
+&gt; [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>
+&gt; [4]<br>
+&gt; <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>
+&gt; [5]<br>
+&gt; <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>
+&gt; [6]<br>
+&gt; <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>
+&gt; [7]<br>
+&gt; <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>
+&gt; [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>
+&gt; [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>
+&gt;<br>
+&gt;<br>
+&gt; ______________________________<wbr>_________________<br>
+&gt; bitcoin-dev mailing list<br>
+&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
+ists.<wbr>linuxfoundation.org</a><br>
+&gt; <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>
+&gt;<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--
+