path: root/ab/ca6cb01d37a081917f42e5cc675f4145682593

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--