path: root/bc/b6d8c9cf23992c0dabd3d8be93cbc2379d081e

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 C1452B35
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 May 2017 16:44:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com
	[209.85.220.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5BE4C1FC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 May 2017 16:44:57 +0000 (UTC)
Received: by mail-qk0-f175.google.com with SMTP id y201so158250840qka.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 May 2017 09:44:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=dP7XXfvXJGXX3Mqwk5L2hvrN8Mu5slWl+X2ZL93VdpY=;
	b=VhNkBGAY5r6IYbysx8vZsp3m88Gi8dpdrzC/uYmrHmcjxnxfcgiKNzqk9G88sfFOdO
	hYpPjhU8Fx0qWBbzcZb9QWPShh0tzFEAOgAYTDR/JR1jpBAKOlVRCYnSXEODRC4uaceV
	1tE4zq7A6jFWLpTeU5fXfq5R+JijzrLPRvQAkZVQBdVrcMEvhE+UgqkGnEMIR1SJ4cof
	lpKZHe8ETm/2wSG3rq9fmEIC0uekq1MHx5dpiHnh5dPvEEdel5hIGTHsIQ9gFSlr40ev
	K5YVs3W8cRU3PNtY/anqlg2xpatcLf7NnFti1ubEvrv4oLzZNZSGrQ/yBDo+uhBYeO4e
	DVyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=dP7XXfvXJGXX3Mqwk5L2hvrN8Mu5slWl+X2ZL93VdpY=;
	b=HO1LlnQFzWi9zqTZe1p66NP66ErvzKGLtXBTOnVw/Qd/iLbH9xBxNXEdSvZ8wE7YO2
	eQ1EYgxeEUXpNgjY/eKt2MPQwzAptxqXlZFthAmCE8FCdzGhoiXi6xvSXjG5otYD1kgv
	ylAUKrLmbEcKjnyT4dXwWykE3zJ8KGaM79w0+ekiPoB9p/uZMjV+BCYDLdsX5tD0kjlg
	887gyigJpwuckfv4WUerBNHBc8yYVRjODp/Y/RBiywS4J+8TYM7BXB4CMA2lwEU0UZVQ
	i6NkLAyhGp7dHzin2o8uShTVf+Gxbsend+/vpn1u6vhBLmii0TiEBZbofi/7y1EZKVG/
	6DvQ==
X-Gm-Message-State: AODbwcDv13g0DvPTXn+LZ2bnT7J/G9zeQIRYbvTGGgh64/P9LPDCOimF
	iQGWuwfphCKtB0hlYUWibzg/8je0p0T9
X-Received: by 10.233.220.71 with SMTP id q68mr30082489qkf.199.1495644296454; 
	Wed, 24 May 2017 09:44:56 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.237.48.102 with HTTP; Wed, 24 May 2017 09:44:55 -0700 (PDT)
In-Reply-To: <4C86CB4F-4ED2-4908-BF5D-6115891DA1D4@gmail.com>
References: <CADvTj4pQ8eJvzm9UOgC8bYm1ERGuTX7qq+a7etRe55S=KodrHQ@mail.gmail.com>
	<c14039f3-637e-e56d-786a-2354b0f354e0@achow101.com>
	<CADvTj4oQsHe3jR2Bm9n0H64ouJbAy0NiXbcmFPxD_C7PSy6L0g@mail.gmail.com>
	<cc20efe1-c5d4-0b79-48d9-65466834dbcf@achow101.com>
	<4C86CB4F-4ED2-4908-BF5D-6115891DA1D4@gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Wed, 24 May 2017 12:44:55 -0400
X-Google-Sender-Auth: 2DRL9euaol1RZVx-TST1L3hfXIY
Message-ID: <CAJowKg+bD675iC9FUAP82KVUZteox9MGnd-EXqKr2tuQsCC5nA@mail.gmail.com>
To: Wang Chun <1240902@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c0438e0002879055047d30c"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, 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: Wed, 24 May 2017 16:50:38 +0000
Cc: Bitcoin Dev <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: Wed, 24 May 2017 16:44:58 -0000

--94eb2c0438e0002879055047d30c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, 75% seems fine - given that there is a already a wide deployment of
segwit enforcing nodes

This implementation is 100% compatible with a "UASF movement" since, if
triggered, it essentially turns all supporting miners into equivalent
BIP148 enforcers.   This should allay any fears that this would subvert a
UASF.

The proposed "agreement" which was reached without input from the
development community also apparently requires that a hard fork be locked
in on the same bit (bit 4).

Ideally, such a 2MB increase should be scheduled using BIP103-esqe logic:
Gradually increasing from 1MB to 2MB over the course of at least a couple
years, beginning 6 months from lock-in.

This will give developers ample time to evaluate and react to network
impacts.


On Wed, May 24, 2017 at 12:02 PM, Wang Chun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I think we should go for 75%, same Litecoin. As I have said before, 95%
> threshold is too high even for unconventional soft forks.
>
> > =E5=9C=A8 2017=E5=B9=B45=E6=9C=8824=E6=97=A5=EF=BC=8C04:58=EF=BC=8CAndr=
ew Chow via bitcoin-dev <bitcoin-dev@lists.
> linuxfoundation.org> =E5=86=99=E9=81=93=EF=BC=9A
> >
> > Ah. I see now. It wasn't very clear to me that that is what will happen=
.
> >
> > Also, shouldn't the timeout date be set for before the BIP141 timeout?
> > Otherwise this could lock in but not have enough time for Segwit to be
> > locked in.
> >
> >
> >> On 5/23/2017 4:42 PM, James Hilliard wrote:
> >> That is incorrect, it is compatible with the current segwit
> >> implementation because it triggers a mandatory signalling period that
> >> will activate segwit on existing nodes.
> >>
> >> On Tue, May 23, 2017 at 4:39 PM, Andrew Chow via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>> Hi James,
> >>>
> >>> From what I understand, this proposal is incompatible with the curren=
t
> >>> segwit implementation with regards to the NODE_WITNESS service bit. I
> >>> believe it could cause network partitioning if the service bit is not
> >>> changed.
> >>>
> >>> Andrew
> >>>
> >>>
> >>>> On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wrote:
> >>>> I would like to propose an implementation that accomplishes the firs=
t
> >>>> 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 rap=
id
> >>>> 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>
> >>>>
> >>>> =3D=3DAbstract=3D=3D
> >>>>
> >>>> This document specifies a method to activate the existing BIP9 segwi=
t
> >>>> deployment with a majority hashpower less than 95%.
> >>>>
> >>>> =3D=3DDefinitions=3D=3D
> >>>>
> >>>> "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.
> >>>>
> >>>> =3D=3DMotivation=3D=3D
> >>>>
> >>>> 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 coordinat=
e
> >>>> 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 d=
ue
> >>>> 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.
> >>>>
> >>>> =3D=3DSpecification=3D=3D
> >>>>
> >>>> While this BIP is active, all blocks must set the nVersion header to=
p
> >>>> 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.
> >>>>
> >>>> =3D=3DDeployment=3D=3D
> >>>>
> >>>> This BIP will be deployed by a "version bits" with an 80%(this can b=
e
> >>>> 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 ti=
me
> >>>> 1496275200) and timeout on midnight November 15th 2017 (epoch time
> >>>> 1510704000). This BIP will cease to be active when segwit is
> >>>> locked-in.
> >>>>
> >>>> =3D=3D=3D Reference implementation =3D=3D=3D
> >>>>
> >>>> <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) =3D=3D
> >>>> THRESHOLD_LOCKED_IN);
> >>>> }
> >>>>
> >>>> // SEGSIGNAL mandatory segwit signalling.
> >>>> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
> >>>> Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) =3D=3D
> THRESHOLD_ACTIVE
> >>>> &&
> >>>>     !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> >>>> // Segwit is not locked in
> >>>>     !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) /=
/
> >>>> and is not active.
> >>>> {
> >>>>    bool fVersionBits =3D (pindex->nVersion & VERSIONBITS_TOP_MASK) =
=3D=3D
> >>>> VERSIONBITS_TOP_BITS;
> >>>>    bool fSegbit =3D (pindex->nVersion &
> >>>> VersionBitsMask(chainparams.GetConsensus(),
> >>>> Consensus::DEPLOYMENT_SEGWIT)) !=3D 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
> >>>>
> >>>> =3D=3DBackwards Compatibility=3D=3D
> >>>>
> >>>> This deployment is compatible with the existing "segwit" bit 1
> >>>> deployment scheduled between midnight November 15th, 2016 and midnig=
ht
> >>>> November 15th, 2017. Miners will need to upgrade their nodes to
> >>>> support segsignal otherwise they may build on top of an invalid bloc=
k.
> >>>> While this bip is active users should either upgrade to segsignal or
> >>>> wait for additional confirmations when accepting payments.
> >>>>
> >>>> =3D=3DRationale=3D=3D
> >>>>
> >>>> Historically we have used IsSuperMajority() to activate soft forks
> >>>> such as BIP66 which has a mandatory signalling requirement for miner=
s
> >>>> once activated, this ensures that miners are aware of new rules bein=
g
> >>>> enforced. This technique can be leveraged to lower the signalling
> >>>> threshold of a soft fork while it is in the process of being deploye=
d
> >>>> 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.
> >>>>
> >>>> =3D=3DReferences=3D=3D
> >>>>
> >>>> *[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]
> >>>>
> >>>> =3D=3DCopyright=3D=3D
> >>>>
> >>>> 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
> >
> > _______________________________________________
> > 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
>

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

<div dir=3D"ltr">Yes, 75% seems fine - given that there is a already a wide=
 deployment of segwit enforcing nodes<br><br>This implementation is 100% co=
mpatible with a &quot;UASF movement&quot; since, if triggered, it essential=
ly turns all supporting miners into equivalent BIP148 enforcers. =C2=A0 Thi=
s should allay any fears that this would subvert a UASF.<br><br>The propose=
d &quot;agreement&quot; which was reached without input from the developmen=
t community also apparently requires that a hard fork be locked in on the s=
ame bit (bit 4). =C2=A0 <br><br>Ideally, such a 2MB increase should be sche=
duled using BIP103-esqe logic: Gradually increasing from 1MB to 2MB over th=
e course of at least a couple years, beginning 6 months from lock-in.<br><b=
r>This will give developers ample time to evaluate and react to network imp=
acts.<div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Wed, May 24, 2017 at 12:02 PM, Wang Chun via bitcoin-dev <span =
dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">I think we should go for 75%, same Litec=
oin. As I have said before, 95% threshold is too high even for unconvention=
al soft forks.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; =E5=9C=A8 2017=E5=B9=B45=E6=9C=8824=E6=97=A5=EF=BC=8C04:58=EF=BC=8CAnd=
rew Chow via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt; =E5=86=99=E9=
=81=93=EF=BC=9A<br>
&gt;<br>
&gt; Ah. I see now. It wasn&#39;t very clear to me that that is what will h=
appen.<br>
&gt;<br>
&gt; Also, shouldn&#39;t the timeout date be set for before the BIP141 time=
out?<br>
&gt; Otherwise this could lock in but not have enough time for Segwit to be=
<br>
&gt; locked in.<br>
&gt;<br>
&gt;<br>
&gt;&gt; On 5/23/2017 4:42 PM, James Hilliard wrote:<br>
&gt;&gt; That is incorrect, it is compatible with the current segwit<br>
&gt;&gt; implementation because it triggers a mandatory signalling period t=
hat<br>
&gt;&gt; will activate segwit on existing nodes.<br>
&gt;&gt;<br>
&gt;&gt; On Tue, May 23, 2017 at 4:39 PM, Andrew Chow via bitcoin-dev<br>
&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt; Hi James,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; From what I understand, this proposal is incompatible with the=
 current<br>
&gt;&gt;&gt; segwit implementation with regards to the NODE_WITNESS service=
 bit. I<br>
&gt;&gt;&gt; believe it could cause network partitioning if the service bit=
 is not<br>
&gt;&gt;&gt; changed.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Andrew<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wrote=
:<br>
&gt;&gt;&gt;&gt; I would like to propose an implementation that accomplishe=
s the first<br>
&gt;&gt;&gt;&gt; part of the Barry Silbert proposal independently from the =
second:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &quot;Activate Segregated Witness at an 80% threshold, sig=
naling at bit 4&quot;<br>
&gt;&gt;&gt;&gt; in a way that<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; The goal here is to minimize chain split risk and network =
disruption<br>
&gt;&gt;&gt;&gt; while maximizing backwards compatibility and still providi=
ng for rapid<br>
&gt;&gt;&gt;&gt; activation of segwit at the 80% threshold using bit 4.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; By activating segwit immediately and separately from any H=
F we can<br>
&gt;&gt;&gt;&gt; scale quickly without risking a rushed combined segwit+HF =
that would<br>
&gt;&gt;&gt;&gt; almost certainly cause widespread issues.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Draft proposal:<br>
&gt;&gt;&gt;&gt; <a href=3D"https://github.com/jameshilliard/bips/blob/bip-=
segsignal/bip-segsignal.mediawiki" rel=3D"noreferrer" target=3D"_blank">htt=
ps://github.com/<wbr>jameshilliard/bips/blob/bip-<wbr>segsignal/bip-segsign=
al.<wbr>mediawiki</a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Proposal text:<br>
&gt;&gt;&gt;&gt; &lt;pre&gt;<br>
&gt;&gt;&gt;&gt;=C2=A0 BIP: segsignal<br>
&gt;&gt;&gt;&gt;=C2=A0 Layer: Consensus (soft fork)<br>
&gt;&gt;&gt;&gt;=C2=A0 Title: Reduced signalling threshold activation of ex=
isting segwit deployment<br>
&gt;&gt;&gt;&gt;=C2=A0 Author: James Hilliard &lt;<a href=3D"mailto:james.h=
illiard1@gmail.com">james.hilliard1@gmail.com</a>&gt;<br>
&gt;&gt;&gt;&gt;=C2=A0 Status: Draft<br>
&gt;&gt;&gt;&gt;=C2=A0 Type: Standards Track<br>
&gt;&gt;&gt;&gt;=C2=A0 Created: 2017-05-22<br>
&gt;&gt;&gt;&gt;=C2=A0 License: BSD-3-Clause<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CC0-1.0<br>
&gt;&gt;&gt;&gt; &lt;/pre&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; =3D=3DAbstract=3D=3D<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; This document specifies a method to activate the existing =
BIP9 segwit<br>
&gt;&gt;&gt;&gt; deployment with a majority hashpower less than 95%.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; =3D=3DDefinitions=3D=3D<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &quot;existing segwit deployment&quot; refer to the BIP9 &=
quot;segwit&quot; deployment<br>
&gt;&gt;&gt;&gt; using bit 1, between November 15th 2016 and November 15th =
2017 to<br>
&gt;&gt;&gt;&gt; activate BIP141, BIP143 and BIP147.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; =3D=3DMotivation=3D=3D<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Segwit increases the blocksize, fixes transaction malleabi=
lity, and<br>
&gt;&gt;&gt;&gt; makes scripting easier to upgrade as well as bringing many=
 other<br>
&gt;&gt;&gt;&gt; [<a href=3D"https://bitcoincore.org/en/2016/01/26/segwit-b=
enefits/" rel=3D"noreferrer" target=3D"_blank">https://bitcoincore.org/en/<=
wbr>2016/01/26/segwit-benefits/</a> benefits].<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; This BIP provides a way for a simple majority of miners to=
 coordinate<br>
&gt;&gt;&gt;&gt; activation of the existing segwit deployment with less tha=
n 95%<br>
&gt;&gt;&gt;&gt; hashpower. For a number of reasons a complete redeployment=
 of segwit<br>
&gt;&gt;&gt;&gt; is difficulty to do until the existing deployment expires.=
 This is due<br>
&gt;&gt;&gt;&gt; to 0.13.1+ having many segwit related features active alre=
ady,<br>
&gt;&gt;&gt;&gt; including all the P2P components, the new network service =
flag, the<br>
&gt;&gt;&gt;&gt; witness-tx and block messages, compact blocks v2 and prefe=
rential<br>
&gt;&gt;&gt;&gt; peering. A redeployment of segwit will need to redefine al=
l these<br>
&gt;&gt;&gt;&gt; things and doing so before expiry would greatly complicate=
 testing.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; =3D=3DSpecification=3D=3D<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; While this BIP is active, all blocks must set the nVersion=
 header top<br>
&gt;&gt;&gt;&gt; 3 bits to 001 together with bit field (1&lt;&lt;1) (accord=
ing to the<br>
&gt;&gt;&gt;&gt; existing segwit deployment). Blocks that do not signal as =
required<br>
&gt;&gt;&gt;&gt; will be rejected.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; =3D=3DDeployment=3D=3D<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; This BIP will be deployed by a &quot;version bits&quot; wi=
th an 80%(this can be<br>
&gt;&gt;&gt;&gt; adjusted if desired) activation threshold BIP9 with the na=
me<br>
&gt;&gt;&gt;&gt; &quot;segsignal&quot; and using bit 4.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; This BIP will have a start time of midnight June 1st, 2017=
 (epoch time<br>
&gt;&gt;&gt;&gt; 1496275200) and timeout on midnight November 15th 2017 (ep=
och time<br>
&gt;&gt;&gt;&gt; 1510704000). This BIP will cease to be active when segwit =
is<br>
&gt;&gt;&gt;&gt; locked-in.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; =3D=3D=3D Reference implementation =3D=3D=3D<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &lt;pre&gt;<br>
&gt;&gt;&gt;&gt; // Check if Segregated Witness is Locked In<br>
&gt;&gt;&gt;&gt; bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, cons=
t<br>
&gt;&gt;&gt;&gt; Consensus::Params&amp; params)<br>
&gt;&gt;&gt;&gt; {<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 LOCK(cs_main);<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 return (VersionBitsState(pindexPrev, params,<=
br>
&gt;&gt;&gt;&gt; Consensus::DEPLOYMENT_SEGWIT, versionbitscache) =3D=3D<br>
&gt;&gt;&gt;&gt; THRESHOLD_LOCKED_IN);<br>
&gt;&gt;&gt;&gt; }<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; // SEGSIGNAL mandatory segwit signalling.<br>
&gt;&gt;&gt;&gt; if ( VersionBitsState(pindex-&gt;<wbr>pprev, chainparams.G=
etConsensus(),<br>
&gt;&gt;&gt;&gt; Consensus::DEPLOYMENT_<wbr>SEGSIGNAL, versionbitscache) =
=3D=3D THRESHOLD_ACTIVE<br>
&gt;&gt;&gt;&gt; &amp;&amp;<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0!IsWitnessLockedIn(pindex-&gt;<wbr>ppre=
v, chainparams.GetConsensus()) &amp;&amp;<br>
&gt;&gt;&gt;&gt; // Segwit is not locked in<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0!IsWitnessEnabled(pindex-&gt;<wbr>pprev=
, chainparams.GetConsensus()) ) //<br>
&gt;&gt;&gt;&gt; and is not active.<br>
&gt;&gt;&gt;&gt; {<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 bool fVersionBits =3D (pindex-&gt;nVersion &a=
mp; VERSIONBITS_TOP_MASK) =3D=3D<br>
&gt;&gt;&gt;&gt; VERSIONBITS_TOP_BITS;<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 bool fSegbit =3D (pindex-&gt;nVersion &amp;<b=
r>
&gt;&gt;&gt;&gt; VersionBitsMask(chainparams.<wbr>GetConsensus(),<br>
&gt;&gt;&gt;&gt; Consensus::DEPLOYMENT_SEGWIT)) !=3D 0;<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 if (!(fVersionBits &amp;&amp; fSegbit)) {<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 return state.DoS(0, error(&quot=
;ConnectBlock(): relayed block must<br>
&gt;&gt;&gt;&gt; signal for segwit, please upgrade&quot;), REJECT_INVALID, =
&quot;bad-no-segwit&quot;);<br>
&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 }<br>
&gt;&gt;&gt;&gt; }<br>
&gt;&gt;&gt;&gt; &lt;/pre&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; <a href=3D"https://github.com/bitcoin/bitcoin/compare/0.14=
...jameshilliard:segsignal-v0.14.1" rel=3D"noreferrer" target=3D"_blank">ht=
tps://github.com/bitcoin/<wbr>bitcoin/compare/0.14...<wbr>jameshilliard:seg=
signal-v0.14.<wbr>1</a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; =3D=3DBackwards Compatibility=3D=3D<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; This deployment is compatible with the existing &quot;segw=
it&quot; bit 1<br>
&gt;&gt;&gt;&gt; deployment scheduled between midnight November 15th, 2016 =
and midnight<br>
&gt;&gt;&gt;&gt; November 15th, 2017. Miners will need to upgrade their nod=
es to<br>
&gt;&gt;&gt;&gt; support segsignal otherwise they may build on top of an in=
valid block.<br>
&gt;&gt;&gt;&gt; While this bip is active users should either upgrade to se=
gsignal or<br>
&gt;&gt;&gt;&gt; wait for additional confirmations when accepting payments.=
<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; =3D=3DRationale=3D=3D<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Historically we have used IsSuperMajority() to activate so=
ft forks<br>
&gt;&gt;&gt;&gt; such as BIP66 which has a mandatory signalling requirement=
 for miners<br>
&gt;&gt;&gt;&gt; once activated, this ensures that miners are aware of new =
rules being<br>
&gt;&gt;&gt;&gt; enforced. This technique can be leveraged to lower the sig=
nalling<br>
&gt;&gt;&gt;&gt; threshold of a soft fork while it is in the process of bei=
ng deployed<br>
&gt;&gt;&gt;&gt; in a backwards compatible way.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; By orphaning non-signalling blocks during the BIP9 bit 1 &=
quot;segwit&quot;<br>
&gt;&gt;&gt;&gt; deployment, this BIP can cause the existing &quot;segwit&q=
uot; deployment to<br>
&gt;&gt;&gt;&gt; activate without needing to release a new deployment.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; =3D=3DReferences=3D=3D<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; *[<a href=3D"https://lists.linuxfoundation.org/pipermail/b=
itcoin-dev/2017-March/013714.html" rel=3D"noreferrer" target=3D"_blank">htt=
ps://lists.<wbr>linuxfoundation.org/pipermail/<wbr>bitcoin-dev/2017-March/0=
13714.<wbr>html</a><br>
&gt;&gt;&gt;&gt; Mailing list discussion]<br>
&gt;&gt;&gt;&gt; *[<a href=3D"https://github.com/bitcoin/bitcoin/blob/v0.6.=
0/src/main.cpp#L1281-L1283" rel=3D"noreferrer" target=3D"_blank">https://gi=
thub.com/bitcoin/<wbr>bitcoin/blob/v0.6.0/src/main.<wbr>cpp#L1281-L1283</a>=
<br>
&gt;&gt;&gt;&gt; P2SH flag day activation]<br>
&gt;&gt;&gt;&gt; *[[bip-0009.mediawiki|BIP9 Version bits with timeout and d=
elay]]<br>
&gt;&gt;&gt;&gt; *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]<br>
&gt;&gt;&gt;&gt; *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus=
 layer)]]<br>
&gt;&gt;&gt;&gt; *[[bip-0143.mediawiki|BIP143 Transaction Signature Verific=
ation for<br>
&gt;&gt;&gt;&gt; Version 0 Witness Program]]<br>
&gt;&gt;&gt;&gt; *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack elem=
ent malleability]]<br>
&gt;&gt;&gt;&gt; *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwi=
t deployment]]<br>
&gt;&gt;&gt;&gt; *[[bip-0149.mediawiki|BIP149 Segregated Witness (second de=
ployment)]]<br>
&gt;&gt;&gt;&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/26/segwit-benefits/</a> Segwit benefits]<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; =3D=3DCopyright=3D=3D<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; This document is dual licensed as BSD 3-clause, and Creati=
ve Commons<br>
&gt;&gt;&gt;&gt; CC0 1.0 Universal.<br>
&gt;&gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">b=
itcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listi=
nfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfo=
undation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/=
bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfounda=
tion.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><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>
______________________________<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></div></blockquote></div><br></div>

--94eb2c0438e0002879055047d30c--