Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 80E6E40C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 May 2017 22:43:05 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B45171D6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 May 2017 22:43:04 +0000 (UTC)
Received: from [30.190.189.119] (66-87-117-119.pools.spcsdns.net
	[66.87.117.119])
	by mail.bluematt.me (Postfix) with ESMTPSA id 9958913B3C2;
	Thu,  8 Jan 1970 09:09:44 +0000 (UTC)
Date: Mon, 22 May 2017 22:43:00 +0000
In-Reply-To: <CADvTj4pQ8eJvzm9UOgC8bYm1ERGuTX7qq+a7etRe55S=KodrHQ@mail.gmail.com>
References: <CADvTj4pQ8eJvzm9UOgC8bYm1ERGuTX7qq+a7etRe55S=KodrHQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: James Hilliard <james.hilliard1@gmail.com>,
	James Hilliard via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <76B73DE9-82D7-4EFA-866A-6531B1F6B480@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.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: Mon, 22 May 2017 22:43:05 -0000

Given the overwhelming support for SegWit across the ecosystem of businesse=
s and users, this seems reasonable to me=2E

On May 22, 2017 6:40:13 PM EDT, James Hilliard via bitcoin-dev <bitcoin-de=
v@lists=2Elinuxfoundation=2Eorg> 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=2E
>
>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=2E
>
>Draft proposal:
>https://github=2Ecom/jameshilliard/bips/blob/bip-segsignal/bip-segsignal=
=2Emediawiki
>
>Proposal text:
><pre>
>  BIP: segsignal
>  Layer: Consensus (soft fork)
>Title: Reduced signalling threshold activation of existing segwit
>deployment
>  Author: James Hilliard <james=2Ehilliard1@gmail=2Ecom>
>  Status: Draft
>  Type: Standards Track
>  Created: 2017-05-22
>  License: BSD-3-Clause
>           CC0-1=2E0
></pre>
>
>=3D=3DAbstract=3D=3D
>
>This document specifies a method to activate the existing BIP9 segwit
>deployment with a majority hashpower less than 95%=2E
>
>=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=2E
>
>=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=2Eorg/en/2016/01/26/segwit-benefits/ benefits]=2E
>
>This BIP provides a way for a simple majority of miners to coordinate
>activation of the existing segwit deployment with less than 95%
>hashpower=2E For a number of reasons a complete redeployment of segwit
>is difficulty to do until the existing deployment expires=2E This is due
>to 0=2E13=2E1+ 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=2E A redeployment of segwit will need to redefine all these
>things and doing so before expiry would greatly complicate testing=2E
>
>=3D=3DSpecification=3D=3D
>
>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)=2E Blocks that do not signal as required
>will be rejected=2E
>
>=3D=3DDeployment=3D=3D
>
>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=2E
>
>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)=2E This BIP will cease to be active when segwit is
>locked-in=2E
>
>=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=2E
>if ( VersionBitsState(pindex->pprev, chainparams=2EGetConsensus(),
>Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) =3D=3D THRESHOLD_ACTIV=
E
>&&
>     !IsWitnessLockedIn(pindex->pprev, chainparams=2EGetConsensus()) &&
>// Segwit is not locked in
>     !IsWitnessEnabled(pindex->pprev, chainparams=2EGetConsensus()) ) //
>and is not active=2E
>{
>    bool fVersionBits =3D (pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=
=3D
>VERSIONBITS_TOP_BITS;
>    bool fSegbit =3D (pindex->nVersion &
>VersionBitsMask(chainparams=2EGetConsensus(),
>Consensus::DEPLOYMENT_SEGWIT)) !=3D 0;
>    if (!(fVersionBits && fSegbit)) {
>        return state=2EDoS(0, error("ConnectBlock(): relayed block must
>signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>    }
>}
></pre>
>
>https://github=2Ecom/bitcoin/bitcoin/compare/0=2E14=2E=2E=2Ejameshilliard=
:segsignal-v0=2E14=2E1
>
>=3D=3DBackwards Compatibility=3D=3D
>
>This deployment is compatible with the existing "segwit" bit 1
>deployment scheduled between midnight November 15th, 2016 and midnight
>November 15th, 2017=2E Miners will need to upgrade their nodes to
>support segsignal otherwise they may build on top of an invalid block=2E
>While this bip is active users should either upgrade to segsignal or
>wait for additional confirmations when accepting payments=2E
>
>=3D=3DRationale=3D=3D
>
>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=2E 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=2E
>
>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=2E
>
>=3D=3DReferences=3D=3D
>
>*[https://lists=2Elinuxfoundation=2Eorg/pipermail/bitcoin-dev/2017-March/=
013714=2Ehtml
>Mailing list discussion]
>*[https://github=2Ecom/bitcoin/bitcoin/blob/v0=2E6=2E0/src/main=2Ecpp#L12=
81-L1283
>P2SH flag day activation]
>*[[bip-0009=2Emediawiki|BIP9 Version bits with timeout and delay]]
>*[[bip-0016=2Emediawiki|BIP16 Pay to Script Hash]]
>*[[bip-0141=2Emediawiki|BIP141 Segregated Witness (Consensus layer)]]
>*[[bip-0143=2Emediawiki|BIP143 Transaction Signature Verification for
>Version 0 Witness Program]]
>*[[bip-0147=2Emediawiki|BIP147 Dealing with dummy stack element
>malleability]]
>*[[bip-0148=2Emediawiki|BIP148 Mandatory activation of segwit
>deployment]]
>*[[bip-0149=2Emediawiki|BIP149 Segregated Witness (second deployment)]]
>*[https://bitcoincore=2Eorg/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=2E0 Universal=2E
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists=2Elinuxfoundation=2Eorg
>https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev