path: root/2d/d46d7497254f6e842432dcf6b5da00eba7a9d5

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 EE10F88A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 23 May 2017 04:00:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com
	[209.85.220.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A2790175
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 23 May 2017 04:00:55 +0000 (UTC)
Received: by mail-qk0-f181.google.com with SMTP id a72so121754376qkj.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 May 2017 21:00:55 -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=ElD+g5V32h1VtL0vFM9l3nMd5N78/X0Q44CiEOijqMg=;
	b=rtgQnWftk7QxXctv0yy1fF7M3zkP26XZ2ViWNOSgVbo5pzelRKpus7/A2EfWyXsoBB
	AQaRxO/fS4dfAY36x9gogXzgYYVl4YJ7u9bpVGCO4HrlliWX/6kabASi5iry0iFmsgea
	cc4jJgo7bfV5Ja1ka88+MExvdEKuMFB28AB775KWcudf7K/u9snSLGIFd+F4Tm+WYTIi
	oM3RPD00joHoAL455EBH/rDtL9ifOh17bhqmwYhF2TlfKtK+gqzQ6se2UbvzezyQbUW5
	pd5TGg3lRGLac7pu5rmJ23yGVX3pPlDZgY8qKYAzMB7t/b9BF+UyqWpr2Jgpy5aV249P
	nxFA==
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=ElD+g5V32h1VtL0vFM9l3nMd5N78/X0Q44CiEOijqMg=;
	b=DRFumuZjTTi49/CSuzTCT/q3+YAaVGEWxcME7KgyrMj/xmApWoYCxZWhM4ttLk4GIe
	yHME4/j98JZjUTOT9bJvA56R8GGYlY5bWX1+6PwQOshTU8v6ZT6pbZYlogDYDt/iM3U/
	Z6Ay3x6IgEJE3t+duVQHnxBx6O3hxhCJTA4dP8ySTva2XKiaSw/GO4n1uutNhIT1y19k
	q0yKzzLRjpfNp1jDKXvvP/ec+tw8q2NxbUbkYac0X7Z0RVkWI4oTnS49Ywth0Q2DNJRm
	wgISauPoq6KmE+XIzG767oABcGorjNzjHfes6AVQGPjd2OyukpNeZrbmgkWODkZIF3lm
	dUvQ==
X-Gm-Message-State: AODbwcCe/Gphf4G29qZKRKucPuJnkfGG8eJWkHbq9jpFxegsz+KzT9rC
	QRJHFEbNpHd6JCcVaqwbPJKvyVhScA==
X-Received: by 10.55.19.205 with SMTP id 74mr22343638qkt.220.1495512054766;
	Mon, 22 May 2017 21:00:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.48.102 with HTTP; Mon, 22 May 2017 21:00:52 -0700 (PDT)
Received: by 10.237.48.102 with HTTP; Mon, 22 May 2017 21:00:52 -0700 (PDT)
Reply-To: erik@q32.com
In-Reply-To: <CAJowKgL0BgtKWQDsE7onygfuv8n2afbEdwotWNzfyV1t9_wxJA@mail.gmail.com>
References: <CADvTj4pQ8eJvzm9UOgC8bYm1ERGuTX7qq+a7etRe55S=KodrHQ@mail.gmail.com>
	<76B73DE9-82D7-4EFA-866A-6531B1F6B480@mattcorallo.com>
	<CAJowKgJyMKxOarUhnZ4yJLftranFCvOnxCGUMs6gDy0MuwS-MQ@mail.gmail.com>
	<CAJowKgL0BgtKWQDsE7onygfuv8n2afbEdwotWNzfyV1t9_wxJA@mail.gmail.com>
From: Erik Aronesty <earonesty@gmail.com>
Date: Tue, 23 May 2017 00:00:53 -0400
Message-ID: <CAJowKg+Mk3GWJZ0AxN5zGqNOc4sVgT7QdiMw3-5a5Se4VkrHzw@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="001a1140177ac820760550290847"
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: Tue, 23 May 2017 06:07:20 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Reduced signalling threshold activation of
 existing segwit deployment
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: Tue, 23 May 2017 04:00:57 -0000

--001a1140177ac820760550290847
Content-Type: text/plain; charset="UTF-8"

Seems like it would work fine.  But why would we expect 80pct to signal for
the exact same implementation - when we can't get 40pct.

It will be contingent on some HF code that allows him to continue using
asicboost,  or is too aggressive,  or some other unreasonable request.



On May 22, 2017 6:43 PM, "Matt Corallo via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

Given the overwhelming support for SegWit across the ecosystem of
businesses and users, this seems reasonable to me.

On May 22, 2017 6:40:13 PM EDT, James Hilliard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>I would like to propose an implementation that accomplishes the first
>part of the Barry Silbert proposal independently from the second:
>
>"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
>in a way that
>
>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.
>
>By activating segwit immediately and separately from any HF we can
>scale quickly without risking a rushed combined segwit+HF that would
>almost certainly cause widespread issues.
>
>Draft proposal:
>https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.
mediawiki
>
>Proposal text:
><pre>
>  BIP: segsignal
>  Layer: Consensus (soft fork)
>Title: Reduced signalling threshold activation of existing segwit
>deployment
>  Author: James Hilliard <james.hilliard1@gmail.com>
>  Status: Draft
>  Type: Standards Track
>  Created: 2017-05-22
>  License: BSD-3-Clause
>           CC0-1.0
></pre>
>
>==Abstract==
>
>This document specifies a method to activate the existing BIP9 segwit
>deployment with a majority hashpower less than 95%.
>
>==Definitions==
>
>"existing segwit deployment" refer to the BIP9 "segwit" deployment
>using bit 1, between November 15th 2016 and November 15th 2017 to
>activate BIP141, BIP143 and BIP147.
>
>==Motivation==
>
>Segwit increases the blocksize, fixes transaction malleability, and
>makes scripting easier to upgrade as well as bringing many other
>[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>
>This BIP provides a way for a simple majority of miners to coordinate
>activation of the existing segwit deployment with less than 95%
>hashpower. For a number of reasons a complete redeployment of segwit
>is difficulty to do until the existing deployment expires. This is due
>to 0.13.1+ having many segwit related features active already,
>including all the P2P components, the new network service flag, the
>witness-tx and block messages, compact blocks v2 and preferential
>peering. A redeployment of segwit will need to redefine all these
>things and doing so before expiry would greatly complicate testing.
>
>==Specification==
>
>While this BIP is active, all blocks must set the nVersion header top
>3 bits to 001 together with bit field (1<<1) (according to the
>existing segwit deployment). Blocks that do not signal as required
>will be rejected.
>
>==Deployment==
>
>This BIP will be deployed by a "version bits" with an 80%(this can be
>adjusted if desired) activation threshold BIP9 with the name
>"segsignal" and using bit 4.
>
>This BIP will have 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.
>
>=== Reference implementation ===
>
><pre>
>// Check if Segregated Witness is Locked In
>bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>Consensus::Params& params)
>{
>    LOCK(cs_main);
>    return (VersionBitsState(pindexPrev, params,
>Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>THRESHOLD_LOCKED_IN);
>}
>
>// SEGSIGNAL mandatory segwit signalling.
>if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
>&&
>     !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>// Segwit is not locked in
>     !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
>and is not active.
>{
>    bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>VERSIONBITS_TOP_BITS;
>    bool fSegbit = (pindex->nVersion &
>VersionBitsMask(chainparams.GetConsensus(),
>Consensus::DEPLOYMENT_SEGWIT)) != 0;
>    if (!(fVersionBits && fSegbit)) {
>        return state.DoS(0, error("ConnectBlock(): relayed block must
>signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>    }
>}
></pre>
>
>https://github.com/bitcoin/bitcoin/compare/0.14...
jameshilliard:segsignal-v0.14.1
>
>==Backwards Compatibility==
>
>This deployment is compatible with the existing "segwit" bit 1
>deployment scheduled between midnight November 15th, 2016 and midnight
>November 15th, 2017. Miners will need to upgrade their nodes to
>support segsignal otherwise they may build on top of an invalid block.
>While this bip is active users should either upgrade to segsignal or
>wait for additional confirmations when accepting payments.
>
>==Rationale==
>
>Historically we have used IsSuperMajority() to activate soft forks
>such as BIP66 which has a mandatory signalling requirement for miners
>once activated, this ensures that miners are aware of new rules being
>enforced. This technique can be leveraged to lower the signalling
>threshold of a soft fork while it is in the process of being deployed
>in a backwards compatible way.
>
>By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
>deployment, this BIP can cause the existing "segwit" deployment to
>activate without needing to release a new deployment.
>
>==References==
>
>*[https://lists.linuxfoundation.org/pipermail/
bitcoin-dev/2017-March/013714.html
>Mailing list discussion]
>*[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
>P2SH flag day activation]
>*[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
>*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
>*[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
>*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
>Version 0 Witness Program]]
>*[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element
>malleability]]
>*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit
>deployment]]
>*[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
>*[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit
>benefits]
>
>==Copyright==
>
>This document is dual licensed as BSD 3-clause, and Creative Commons
>CC0 1.0 Universal.
>_______________________________________________
>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

--001a1140177ac820760550290847
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"auto">Seems like it would work fine.=C2=A0 Bu=
t why would we expect 80pct to signal for the exact same implementation - w=
hen we can&#39;t get 40pct. =C2=A0</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">It will be contingent on some HF code that allows him to continu=
e using asicboost, =C2=A0or is too aggressive, =C2=A0or some other unreason=
able request.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On May 22, =
2017 6:43 PM, &quot;Matt Corallo via bitcoin-dev&quot; &lt;<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Given t=
he overwhelming support for SegWit across the ecosystem of businesses and u=
sers, this seems reasonable to me.<br>
<div class=3D"elided-text"><br>
On May 22, 2017 6:40:13 PM EDT, James Hilliard via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>li=
nuxfoundation.org</a>&gt; wrote:<br>
&gt;I would like to propose an implementation that accomplishes the first<b=
r>
&gt;part of the Barry Silbert proposal independently from the second:<br>
&gt;<br>
&gt;&quot;Activate Segregated Witness at an 80% threshold, signaling at bit=
 4&quot;<br>
&gt;in a way that<br>
&gt;<br>
&gt;The goal here is to minimize chain split risk and network disruption<br=
>
&gt;while maximizing backwards compatibility and still providing for rapid<=
br>
&gt;activation of segwit at the 80% threshold using bit 4.<br>
&gt;<br>
&gt;By activating segwit immediately and separately from any HF we can<br>
&gt;scale quickly without risking a rushed combined segwit+HF that would<br=
>
&gt;almost certainly cause widespread issues.<br>
&gt;<br>
&gt;Draft proposal:<br>
&gt;<a href=3D"https://github.com/jameshilliard/bips/blob/bip-segsignal/bip=
-segsignal.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.c=
om/<wbr>jameshilliard/bips/blob/bip-<wbr>segsignal/bip-segsignal.<wbr>media=
wiki</a><br>
&gt;<br>
&gt;Proposal text:<br>
&gt;&lt;pre&gt;<br>
&gt;=C2=A0 BIP: segsignal<br>
&gt;=C2=A0 Layer: Consensus (soft fork)<br>
&gt;Title: Reduced signalling threshold activation of existing segwit<br>
&gt;deployment<br>
&gt;=C2=A0 Author: James Hilliard &lt;<a href=3D"mailto:james.hilliard1@gma=
il.com">james.hilliard1@gmail.com</a>&gt;<br>
&gt;=C2=A0 Status: Draft<br>
&gt;=C2=A0 Type: Standards Track<br>
&gt;=C2=A0 Created: 2017-05-22<br>
&gt;=C2=A0 License: BSD-3-Clause<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CC0-1.0<br>
&gt;&lt;/pre&gt;<br>
&gt;<br>
&gt;=3D=3DAbstract=3D=3D<br>
&gt;<br>
&gt;This document specifies a method to activate the existing BIP9 segwit<b=
r>
&gt;deployment with a majority hashpower less than 95%.<br>
&gt;<br>
&gt;=3D=3DDefinitions=3D=3D<br>
&gt;<br>
&gt;&quot;existing segwit deployment&quot; refer to the BIP9 &quot;segwit&q=
uot; deployment<br>
&gt;using bit 1, between November 15th 2016 and November 15th 2017 to<br>
&gt;activate BIP141, BIP143 and BIP147.<br>
&gt;<br>
&gt;=3D=3DMotivation=3D=3D<br>
&gt;<br>
&gt;Segwit increases the blocksize, fixes transaction malleability, and<br>
&gt;makes scripting easier to upgrade as well as bringing many other<br>
&gt;[<a href=3D"https://bitcoincore.org/en/2016/01/26/segwit-benefits/" rel=
=3D"noreferrer" target=3D"_blank">https://bitcoincore.org/en/<wbr>2016/01/2=
6/segwit-benefits/</a> benefits].<br>
&gt;<br>
&gt;This BIP provides a way for a simple majority of miners to coordinate<b=
r>
&gt;activation of the existing segwit deployment with less than 95%<br>
&gt;hashpower. For a number of reasons a complete redeployment of segwit<br=
>
&gt;is difficulty to do until the existing deployment expires. This is due<=
br>
&gt;to 0.13.1+ having many segwit related features active already,<br>
&gt;including all the P2P components, the new network service flag, the<br>
&gt;witness-tx and block messages, compact blocks v2 and preferential<br>
&gt;peering. A redeployment of segwit will need to redefine all these<br>
&gt;things and doing so before expiry would greatly complicate testing.<br>
&gt;<br>
&gt;=3D=3DSpecification=3D=3D<br>
&gt;<br>
&gt;While this BIP is active, all blocks must set the nVersion header top<b=
r>
&gt;3 bits to 001 together with bit field (1&lt;&lt;1) (according to the<br=
>
&gt;existing segwit deployment). Blocks that do not signal as required<br>
&gt;will be rejected.<br>
&gt;<br>
&gt;=3D=3DDeployment=3D=3D<br>
&gt;<br>
&gt;This BIP will be deployed by a &quot;version bits&quot; with an 80%(thi=
s can be<br>
&gt;adjusted if desired) activation threshold BIP9 with the name<br>
&gt;&quot;segsignal&quot; and using bit 4.<br>
&gt;<br>
&gt;This BIP will have a start time of midnight June 1st, 2017 (epoch time<=
br>
&gt;1496275200) and timeout on midnight November 15th 2017 (epoch time<br>
&gt;1510704000). This BIP will cease to be active when segwit is<br>
&gt;locked-in.<br>
&gt;<br>
&gt;=3D=3D=3D Reference implementation =3D=3D=3D<br>
&gt;<br>
&gt;&lt;pre&gt;<br>
&gt;// Check if Segregated Witness is Locked In<br>
&gt;bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const<br>
&gt;Consensus::Params&amp; params)<br>
&gt;{<br>
&gt;=C2=A0 =C2=A0 LOCK(cs_main);<br>
&gt;=C2=A0 =C2=A0 return (VersionBitsState(pindexPrev, params,<br>
&gt;Consensus::DEPLOYMENT_SEGWIT, versionbitscache) =3D=3D<br>
&gt;THRESHOLD_LOCKED_IN);<br>
&gt;}<br>
&gt;<br>
&gt;// SEGSIGNAL mandatory segwit signalling.<br>
&gt;if ( VersionBitsState(pindex-&gt;<wbr>pprev, chainparams.GetConsensus()=
,<br>
&gt;Consensus::DEPLOYMENT_<wbr>SEGSIGNAL, versionbitscache) =3D=3D THRESHOL=
D_ACTIVE<br>
&gt;&amp;&amp;<br>
&gt;=C2=A0 =C2=A0 =C2=A0!IsWitnessLockedIn(pindex-&gt;<wbr>pprev, chainpara=
ms.GetConsensus()) &amp;&amp;<br>
&gt;// Segwit is not locked in<br>
&gt;=C2=A0 =C2=A0 =C2=A0!IsWitnessEnabled(pindex-&gt;<wbr>pprev, chainparam=
s.GetConsensus()) ) //<br>
&gt;and is not active.<br>
&gt;{<br>
&gt;=C2=A0 =C2=A0 bool fVersionBits =3D (pindex-&gt;nVersion &amp; VERSIONB=
ITS_TOP_MASK) =3D=3D<br>
&gt;VERSIONBITS_TOP_BITS;<br>
&gt;=C2=A0 =C2=A0 bool fSegbit =3D (pindex-&gt;nVersion &amp;<br>
&gt;VersionBitsMask(chainparams.<wbr>GetConsensus(),<br>
&gt;Consensus::DEPLOYMENT_SEGWIT)<wbr>) !=3D 0;<br>
&gt;=C2=A0 =C2=A0 if (!(fVersionBits &amp;&amp; fSegbit)) {<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 return state.DoS(0, error(&quot;ConnectBloc=
k(): relayed block must<br>
&gt;signal for segwit, please upgrade&quot;), REJECT_INVALID, &quot;bad-no-=
segwit&quot;);<br>
&gt;=C2=A0 =C2=A0 }<br>
&gt;}<br>
&gt;&lt;/pre&gt;<br>
&gt;<br>
&gt;<a href=3D"https://github.com/bitcoin/bitcoin/compare/0.14...jameshilli=
ard:segsignal-v0.14.1" rel=3D"noreferrer" target=3D"_blank">https://github.=
com/bitcoin/<wbr>bitcoin/compare/0.14...<wbr>jameshilliard:segsignal-v0.14.=
<wbr>1</a><br>
&gt;<br>
&gt;=3D=3DBackwards Compatibility=3D=3D<br>
&gt;<br>
&gt;This deployment is compatible with the existing &quot;segwit&quot; bit =
1<br>
&gt;deployment scheduled between midnight November 15th, 2016 and midnight<=
br>
&gt;November 15th, 2017. Miners will need to upgrade their nodes to<br>
&gt;support segsignal otherwise they may build on top of an invalid block.<=
br>
&gt;While this bip is active users should either upgrade to segsignal or<br=
>
&gt;wait for additional confirmations when accepting payments.<br>
&gt;<br>
&gt;=3D=3DRationale=3D=3D<br>
&gt;<br>
&gt;Historically we have used IsSuperMajority() to activate soft forks<br>
&gt;such as BIP66 which has a mandatory signalling requirement for miners<b=
r>
&gt;once activated, this ensures that miners are aware of new rules being<b=
r>
&gt;enforced. This technique can be leveraged to lower the signalling<br>
&gt;threshold of a soft fork while it is in the process of being deployed<b=
r>
&gt;in a backwards compatible way.<br>
&gt;<br>
&gt;By orphaning non-signalling blocks during the BIP9 bit 1 &quot;segwit&q=
uot;<br>
&gt;deployment, this BIP can cause the existing &quot;segwit&quot; deployme=
nt to<br>
&gt;activate without needing to release a new deployment.<br>
&gt;<br>
&gt;=3D=3DReferences=3D=3D<br>
&gt;<br>
&gt;*[<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
17-March/013714.html" rel=3D"noreferrer" target=3D"_blank">https://lists.<w=
br>linuxfoundation.org/pipermail/<wbr>bitcoin-dev/2017-March/013714.<wbr>ht=
ml</a><br>
&gt;Mailing list discussion]<br>
&gt;*[<a href=3D"https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cp=
p#L1281-L1283" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitc=
oin/<wbr>bitcoin/blob/v0.6.0/src/main.<wbr>cpp#L1281-L1283</a><br>
&gt;P2SH flag day activation]<br>
&gt;*[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]<br>
&gt;*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]<br>
&gt;*[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]<br>
&gt;*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for<br>
&gt;Version 0 Witness Program]]<br>
&gt;*[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element<br>
&gt;malleability]]<br>
&gt;*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit<br>
&gt;deployment]]<br>
&gt;*[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]<b=
r>
&gt;*[<a href=3D"https://bitcoincore.org/en/2016/01/26/segwit-benefits/" re=
l=3D"noreferrer" target=3D"_blank">https://bitcoincore.org/en/<wbr>2016/01/=
26/segwit-benefits/</a> Segwit<br>
&gt;benefits]<br>
&gt;<br>
&gt;=3D=3DCopyright=3D=3D<br>
&gt;<br>
&gt;This document is dual licensed as BSD 3-clause, and Creative Commons<br=
>
&gt;CC0 1.0 Universal.<br>
&gt;_____________________________<wbr>__________________<br>
&gt;bitcoin-dev mailing list<br>
&gt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a><br>
&gt;<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev" rel=3D"noreferrer" target=3D"_blank">https://lists.<wbr>linuxfoundation=
.org/mailman/<wbr>listinfo/bitcoin-dev</a><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>
</div></blockquote></div><br></div>

--001a1140177ac820760550290847--