From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 80E6E40C for ; 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 ; 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: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: James Hilliard , James Hilliard via bitcoin-dev , Bitcoin Dev From: Matt Corallo 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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: >
>  BIP: segsignal
>  Layer: Consensus (soft fork)
>Title: Reduced signalling threshold activation of existing segwit
>deployment
>  Author: James Hilliard 
>  Status: Draft
>  Type: Standards Track
>  Created: 2017-05-22
>  License: BSD-3-Clause
>           CC0-1=2E0
>
> >=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 > >
>// 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");
>    }
>}
>
> >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