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 "UASF movement" 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 "agreement" 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"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></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>
> =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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>> =E5=86=99=E9=
=81=93=EF=BC=9A<br>
><br>
> Ah. I see now. It wasn't very clear to me that that is what will h=
appen.<br>
><br>
> Also, shouldn't the timeout date be set for before the BIP141 time=
out?<br>
> Otherwise this could lock in but not have enough time for Segwit to be=
<br>
> locked in.<br>
><br>
><br>
>> On 5/23/2017 4:42 PM, James Hilliard wrote:<br>
>> That is incorrect, it is compatible with the current segwit<br>
>> implementation because it triggers a mandatory signalling period t=
hat<br>
>> will activate segwit on existing nodes.<br>
>><br>
>> On Tue, May 23, 2017 at 4:39 PM, Andrew Chow via bitcoin-dev<br>
>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>>> Hi James,<br>
>>><br>
>>> From what I understand, this proposal is incompatible with the=
current<br>
>>> segwit implementation with regards to the NODE_WITNESS service=
bit. I<br>
>>> believe it could cause network partitioning if the service bit=
is not<br>
>>> changed.<br>
>>><br>
>>> Andrew<br>
>>><br>
>>><br>
>>>> On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wrote=
:<br>
>>>> I would like to propose an implementation that accomplishe=
s the first<br>
>>>> part of the Barry Silbert proposal independently from the =
second:<br>
>>>><br>
>>>> "Activate Segregated Witness at an 80% threshold, sig=
naling at bit 4"<br>
>>>> in a way that<br>
>>>><br>
>>>> The goal here is to minimize chain split risk and network =
disruption<br>
>>>> while maximizing backwards compatibility and still providi=
ng for rapid<br>
>>>> activation of segwit at the 80% threshold using bit 4.<br>
>>>><br>
>>>> By activating segwit immediately and separately from any H=
F we can<br>
>>>> scale quickly without risking a rushed combined segwit+HF =
that would<br>
>>>> almost certainly cause widespread issues.<br>
>>>><br>
>>>> Draft proposal:<br>
>>>> <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>
>>>><br>
>>>> Proposal text:<br>
>>>> <pre><br>
>>>>=C2=A0 BIP: segsignal<br>
>>>>=C2=A0 Layer: Consensus (soft fork)<br>
>>>>=C2=A0 Title: Reduced signalling threshold activation of ex=
isting segwit deployment<br>
>>>>=C2=A0 Author: James Hilliard <<a href=3D"mailto:james.h=
illiard1@gmail.com">james.hilliard1@gmail.com</a>><br>
>>>>=C2=A0 Status: Draft<br>
>>>>=C2=A0 Type: Standards Track<br>
>>>>=C2=A0 Created: 2017-05-22<br>
>>>>=C2=A0 License: BSD-3-Clause<br>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CC0-1.0<br>
>>>> </pre><br>
>>>><br>
>>>> =3D=3DAbstract=3D=3D<br>
>>>><br>
>>>> This document specifies a method to activate the existing =
BIP9 segwit<br>
>>>> deployment with a majority hashpower less than 95%.<br>
>>>><br>
>>>> =3D=3DDefinitions=3D=3D<br>
>>>><br>
>>>> "existing segwit deployment" refer to the BIP9 &=
quot;segwit" deployment<br>
>>>> using bit 1, between November 15th 2016 and November 15th =
2017 to<br>
>>>> activate BIP141, BIP143 and BIP147.<br>
>>>><br>
>>>> =3D=3DMotivation=3D=3D<br>
>>>><br>
>>>> Segwit increases the blocksize, fixes transaction malleabi=
lity, and<br>
>>>> makes scripting easier to upgrade as well as bringing many=
other<br>
>>>> [<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>
>>>><br>
>>>> This BIP provides a way for a simple majority of miners to=
coordinate<br>
>>>> activation of the existing segwit deployment with less tha=
n 95%<br>
>>>> hashpower. For a number of reasons a complete redeployment=
of segwit<br>
>>>> is difficulty to do until the existing deployment expires.=
This is due<br>
>>>> to 0.13.1+ having many segwit related features active alre=
ady,<br>
>>>> including all the P2P components, the new network service =
flag, the<br>
>>>> witness-tx and block messages, compact blocks v2 and prefe=
rential<br>
>>>> peering. A redeployment of segwit will need to redefine al=
l these<br>
>>>> things and doing so before expiry would greatly complicate=
testing.<br>
>>>><br>
>>>> =3D=3DSpecification=3D=3D<br>
>>>><br>
>>>> While this BIP is active, all blocks must set the nVersion=
header top<br>
>>>> 3 bits to 001 together with bit field (1<<1) (accord=
ing to the<br>
>>>> existing segwit deployment). Blocks that do not signal as =
required<br>
>>>> will be rejected.<br>
>>>><br>
>>>> =3D=3DDeployment=3D=3D<br>
>>>><br>
>>>> This BIP will be deployed by a "version bits" wi=
th an 80%(this can be<br>
>>>> adjusted if desired) activation threshold BIP9 with the na=
me<br>
>>>> "segsignal" and using bit 4.<br>
>>>><br>
>>>> This BIP will have a start time of midnight June 1st, 2017=
(epoch time<br>
>>>> 1496275200) and timeout on midnight November 15th 2017 (ep=
och time<br>
>>>> 1510704000). This BIP will cease to be active when segwit =
is<br>
>>>> locked-in.<br>
>>>><br>
>>>> =3D=3D=3D Reference implementation =3D=3D=3D<br>
>>>><br>
>>>> <pre><br>
>>>> // Check if Segregated Witness is Locked In<br>
>>>> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, cons=
t<br>
>>>> Consensus::Params& params)<br>
>>>> {<br>
>>>>=C2=A0 =C2=A0 LOCK(cs_main);<br>
>>>>=C2=A0 =C2=A0 return (VersionBitsState(pindexPrev, params,<=
br>
>>>> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) =3D=3D<br>
>>>> THRESHOLD_LOCKED_IN);<br>
>>>> }<br>
>>>><br>
>>>> // SEGSIGNAL mandatory segwit signalling.<br>
>>>> if ( VersionBitsState(pindex-><wbr>pprev, chainparams.G=
etConsensus(),<br>
>>>> Consensus::DEPLOYMENT_<wbr>SEGSIGNAL, versionbitscache) =
=3D=3D THRESHOLD_ACTIVE<br>
>>>> &&<br>
>>>>=C2=A0 =C2=A0 =C2=A0!IsWitnessLockedIn(pindex-><wbr>ppre=
v, chainparams.GetConsensus()) &&<br>
>>>> // Segwit is not locked in<br>
>>>>=C2=A0 =C2=A0 =C2=A0!IsWitnessEnabled(pindex-><wbr>pprev=
, chainparams.GetConsensus()) ) //<br>
>>>> and is not active.<br>
>>>> {<br>
>>>>=C2=A0 =C2=A0 bool fVersionBits =3D (pindex->nVersion &a=
mp; VERSIONBITS_TOP_MASK) =3D=3D<br>
>>>> VERSIONBITS_TOP_BITS;<br>
>>>>=C2=A0 =C2=A0 bool fSegbit =3D (pindex->nVersion &<b=
r>
>>>> VersionBitsMask(chainparams.<wbr>GetConsensus(),<br>
>>>> Consensus::DEPLOYMENT_SEGWIT)) !=3D 0;<br>
>>>>=C2=A0 =C2=A0 if (!(fVersionBits && fSegbit)) {<br>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return state.DoS(0, error("=
;ConnectBlock(): relayed block must<br>
>>>> signal for segwit, please upgrade"), REJECT_INVALID, =
"bad-no-segwit");<br>
>>>>=C2=A0 =C2=A0 }<br>
>>>> }<br>
>>>> </pre><br>
>>>><br>
>>>> <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>
>>>><br>
>>>> =3D=3DBackwards Compatibility=3D=3D<br>
>>>><br>
>>>> This deployment is compatible with the existing "segw=
it" bit 1<br>
>>>> deployment scheduled between midnight November 15th, 2016 =
and midnight<br>
>>>> November 15th, 2017. Miners will need to upgrade their nod=
es to<br>
>>>> support segsignal otherwise they may build on top of an in=
valid block.<br>
>>>> While this bip is active users should either upgrade to se=
gsignal or<br>
>>>> wait for additional confirmations when accepting payments.=
<br>
>>>><br>
>>>> =3D=3DRationale=3D=3D<br>
>>>><br>
>>>> Historically we have used IsSuperMajority() to activate so=
ft forks<br>
>>>> such as BIP66 which has a mandatory signalling requirement=
for miners<br>
>>>> once activated, this ensures that miners are aware of new =
rules being<br>
>>>> enforced. This technique can be leveraged to lower the sig=
nalling<br>
>>>> threshold of a soft fork while it is in the process of bei=
ng deployed<br>
>>>> in a backwards compatible way.<br>
>>>><br>
>>>> By orphaning non-signalling blocks during the BIP9 bit 1 &=
quot;segwit"<br>
>>>> deployment, this BIP can cause the existing "segwit&q=
uot; deployment to<br>
>>>> activate without needing to release a new deployment.<br>
>>>><br>
>>>> =3D=3DReferences=3D=3D<br>
>>>><br>
>>>> *[<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>
>>>> Mailing list discussion]<br>
>>>> *[<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>
>>>> P2SH flag day activation]<br>
>>>> *[[bip-0009.mediawiki|BIP9 Version bits with timeout and d=
elay]]<br>
>>>> *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]<br>
>>>> *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus=
layer)]]<br>
>>>> *[[bip-0143.mediawiki|BIP143 Transaction Signature Verific=
ation for<br>
>>>> Version 0 Witness Program]]<br>
>>>> *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack elem=
ent malleability]]<br>
>>>> *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwi=
t deployment]]<br>
>>>> *[[bip-0149.mediawiki|BIP149 Segregated Witness (second de=
ployment)]]<br>
>>>> *[<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>
>>>><br>
>>>> =3D=3DCopyright=3D=3D<br>
>>>><br>
>>>> This document is dual licensed as BSD 3-clause, and Creati=
ve Commons<br>
>>>> CC0 1.0 Universal.<br>
>>>> ______________________________<wbr>_________________<br>
>>>> bitcoin-dev mailing list<br>
>>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">b=
itcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
>>>> <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>
>>> ______________________________<wbr>_________________<br>
>>> bitcoin-dev mailing list<br>
>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-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.linuxfounda=
tion.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
><br>
> ______________________________<wbr>_________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
______________________________<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--