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 F0B0F3EE for ; Mon, 29 May 2017 10:19:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 10101F3 for ; Mon, 29 May 2017 10:19:19 +0000 (UTC) Received: by mail-oi0-f45.google.com with SMTP id b204so73993201oii.1 for ; Mon, 29 May 2017 03:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xYKvZs09GU2VML1pR/jO7BfZOmeWZJ6pPLJa2Pl5F58=; b=CDtkVabHgocLD2YMjVoNV2Yx/QaIRfDASxxwCZgo1Lnpsy/aJyoRfuJknvEFD6G9TR h4uLrkmF0zED3unYYkAkOmcqq7RD5DqKPKI+r/VMMlk6pukCfYUnFnpNC1StxrRylBqd oSnPYfrXLVZwy8czlOs1OiS2LUrlczfN+rJD0z4BTqSBDAvq62qOP1XM9ZxR/bf1gfK5 6IdvKZi0802L2oG2LLvB29oEPq70yLI/LoT+3D2/ogK1mQaVyvKHrzFBxxtFxI9xuHnR SO/swqPSvKe+GZ/L9QNNOHQeMQ2l4KaaROM/Qn/8c3+f66uX6iPlS13hv7gTF3bwvrq6 ud1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xYKvZs09GU2VML1pR/jO7BfZOmeWZJ6pPLJa2Pl5F58=; b=hO+/91na3r1mSXxN/2hMl+Flvro8L3DthoTregMgT0LaH/I5Wce/i1FbPaWF8AAB8T O9WF5RoDd4JOusbygBzmCmkBDrQHMex60MpNi6uSotcAutJ4GHbdQ625PVULin5QhOZ3 GCts1qoHrURU/Jb7e4O1MesPl9PfDL0b3zRYzE2qjftK9N05hCAmeg+NbqDxAq9A90DV tdITjXr0BA7kOkFLBv7ebiAUAfsixzOMtIPLXxG3qEo69lcy8fgKOW98+8sI8Zj4bG+v B8ovLRMXTrBTWNMfaPdv6/lwkOZ6JfscL63go9sAugOYdGIuv2SNnKajBQIn3iKbtahb MZ1A== X-Gm-Message-State: AODbwcBvOGpt8Ne5bihXV52Uh9oVM3dyj4Hs+tdNZzH3vVbR3Uw8Vl73 ejxbth3+WPndkW3x4jIvU9KvVYjKzQ== X-Received: by 10.157.14.230 with SMTP id 93mr7912479otj.97.1496053159157; Mon, 29 May 2017 03:19:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.115.198 with HTTP; Mon, 29 May 2017 03:19:18 -0700 (PDT) In-Reply-To: References: From: James Hilliard Date: Mon, 29 May 2017 05:19:18 -0500 Message-ID: To: CalvinRechner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, 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 Cc: "bitcoin-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal 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, 29 May 2017 10:19:21 -0000 For the reasons listed here(https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki#Motivat= ion) you should have it so that the HF can not lock in unless the existing BIP141 segwit deployment is activated. The biggest issue is that a safe HF is very unlikely to be able to be coded and tested within 6 months. On Sun, May 28, 2017 at 8:18 PM, CalvinRechner via bitcoin-dev wrote: > This proposal is written under the assumption that the signatories to the > Consensus 2017 Scaling Agreement[1] are genuinely committed to the terms = of > the agreement, and intend to enact the updates described therein. As such= , > criticisms pertaining to the chosen deployment timeline or hard fork upgr= ade > path should be treated as out-of-scope during the initial discussion of t= his > proposal. > > Because it includes the activation of a hard fork for which community > consensus does not yet exist, this proposal is not likely to be merged in= to > Bitcoin Core in the immediate future, and must instead be maintained and > reviewed in a separate downstream repository. However, it is written with > the intent to remain cleanly compatible with future network updates and > changes, to allow for the option of a straightforward upstream merge if > community consensus for the proposal is successfully achieved in the > following months. > > > 
> BIP: ?
> Layer: Consensus
> Title: Compatibility-oriented omnibus proposal
> Author: Calvin Rechner 
> Comments-Summary: No comments yet.
> Comments-URI: ?
> Status: Draft
> Type: Standards Track
> Created: 2017-05-28
> License: PD
>
> > > =3D=3D=3DAbstract=3D=3D=3D > > This document describes a virtuous combination of James Hilliard=E2=80=99= s =E2=80=9CReduced > signalling threshold activation of existing segwit deployment=E2=80=9D[2]= , Shaolin > Fry=E2=80=99s =E2=80=9CMandatory activation of segwit deployment=E2=80=9D= [3], Sergio Demian Lerner=E2=80=99s > =E2=80=9CSegwit2Mb=E2=80=9D[4] proposal, Luke Dashjr=E2=80=99s =E2=80=9CP= ost-segwit 2 MB block size > hardfork=E2=80=9D[5], and hard fork safety mechanisms from Johnson Lau=E2= =80=99s > =E2=80=9CSpoonnet=E2=80=9D[6][7] into a single omnibus proposal and patch= set. > > > =3D=3D=3DMotivation=3D=3D=3D > > The Consensus 2017 Scaling Agreement[1] stipulated the following > commitments: > > =E2=80=A2 Activate Segregated Witness at an 80% threshold, signaling at b= it 4 > =E2=80=A2 Activate a 2 MB hard fork within six months > > This proposal seeks to fulfill these criteria while retaining maximum > compatibility with existing deployment approaches, thereby minimizing the > risks of a destructive chain split. Additionally, subsequent indications = of > implied criteria and expectations of the Agreement[8][9] are satisfied. > > The proposed hard fork incorporates a legacy witness discount and 2MB > blocksize limit along with the enactment of Spoonnet-derived protectionar= y > measures, to ensure the safest possible fork activation within the > constraints of the requirements outlined in the Scaling Agreement. > > > =3D=3D=3DRationale=3D=3D=3D > > To the extent possible, this represents an effort at a best-of-all-worlds > proposal, intended to provide a common foundation from which all > mutually-inclusive goals can be achieved while risks are minimized. > > The individual constituent proposals include the following respective > rationales: > > James Hilliard=E2=80=99s =E2=80=9CReduced signalling threshold activation= of existing segwit > deployment=E2=80=9D[2] explains: > >> The goal here is to minimize chain split risk and network disruption whi= le >> maximizing backwards compatibility and still providing for rapid activat= ion >> of segwit at the 80% threshold using bit 4. > > Shaolin Fry=E2=80=99s =E2=80=9CMandatory activation of segwit deployment= =E2=80=9D[3] is included to: > >> cause the existing "segwit" deployment to activate without needing to >> release a new deployment. > > Both of the aforementioned activation options (=E2=80=9Cfast-activation= =E2=80=9D and > =E2=80=9Cflag-day activation=E2=80=9D) serve to prevent unnecessary delay= s in the network > upgrade process, addressing a common criticism of the Scaling Agreement a= nd > providing an opportunity for cooperation and unity instead. > > Sergio Demian Lerner=E2=80=99s =E2=80=9CSegwit2Mb=E2=80=9D[4] proposal ex= plains the reasoning behind > linking SegWit=E2=80=99s activation with that of a later hard fork block = size > increase: > >> Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB blo= ck >> size hard-fork activated ONLY if segwit activates (95% of miners signali= ng >> ... to re-unite the Bitcoin community and avoid a cryptocurrency split. > > Luke Dashjr=E2=80=99s =E2=80=9CPost-segwit 2 MB block size hardfork=E2=80= =9D[5] suggestions are > included to reduce the marginal risks that such an increase in the block > size might introduce: > >> if the community wishes to adopt (by unanimous consensus) a 2 MB block >> size hardfork, this is probably the best way to do it right now... Legac= y >> Bitcoin transactions are given the witness discount, and a block size li= mit >> of 2 MB is imposed. > > Johnson Lau=E2=80=99s anti-replay and network version updates[6][7] are i= ncluded as > general hard fork safety measures: > >> In a blockchain split, however, since both forks share the same historic= al >> ledger, replay attack would be possible, unless some precautions are tak= en. > > > =3D=3D=3DCopyright=3D=3D=3D > > This document is placed in the public domain. > > > =3D=3D=3DSpecification=3D=3D=3D > > ###Proposal Signaling### > > The string =E2=80=9CCOOP=E2=80=9D is included anywhere in the txn-input (= scriptSig) of the > coinbase-txn to signal compatibility and support. > > ###Soft Fork### > > Fast-activation (segsignal): deployed by a "version bits" with an 80% > activation threshold BIP9 with the name "segsignal" and using bit 4... [w= ith > a] start time of midnight June 1st, 2017 (epoch time 1496275200) and time= out > on midnight November 15th 2017 (epoch time 1510704000). This BIP will cea= se > to be active when segwit is locked-in.[2] > > Flag-day activation (BIP148): While this BIP is active, all blocks must s= et > 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... This BIP will be active between midnight Aug= ust > 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoch t= ime > 1510704000) if the existing segwit deployment is not locked-in or activat= ed > before epoch time 1501545600. This BIP will cease to be active when segwi= t > is locked-in. 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 b= e > rejected.[3] > > ###Hard Fork### > > The hard fork deployment is scheduled to occur 6 months after SegWit > activates: > > (HardForkHeight =3D SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280) > > For blocks equal to or higher than HardForkHeight, Luke-Jr=E2=80=99s lega= cy witness > discount and 2MB limit are enacted, along with the following Spoonnet-bas= ed > improvements[6][7]: > > * A "hardfork signalling block" is a block with the sign bit of header > nVersion is set [Clearly invalid for old nodes; easy opt-out for light > wallets] > > * If the median-time-past of the past 11 blocks is smaller than the > HardForkHeight... a hardfork signalling block is invalid. > > * Child of a hardfork signalling block MUST also be a hardfork signalling > block > > * Hardfork network version bit is 0x02000000. A tx is invalid if the high= est > nVersion byte is not zero, and the network version bit is not set. > > > =3D=3D=3DDeployment=3D=3D=3D > > Deployment of the =E2=80=9Cfast-activation=E2=80=9D soft fork is exactly = identical to > Hilliard=E2=80=99s segsignal proposal[2]. Deployment of the =E2=80=9Cflag= -day=E2=80=9D soft fork is > exactly identical to Fry=E2=80=99s BIP148 proposal[3]. HardForkHeight is = defined as > 26280 blocks after SegWit is set to ACTIVE. All blocks with height greate= r > than or equal to this value must adhere to the consensus rules of the 2MB > hard fork. > > > =3D=3D=3DBackwards compatibility=3D=3D=3D > > This deployment is compatible with the existing "segwit" bit 1 deployment > scheduled between midnight November 15th, 2016 and midnight November 15th= , > 2017. > > To prevent the risk of building on top of invalid blocks, miners should > upgrade their nodes to support segsignal as well as BIP148. > > The intent of this proposal is to maintain full legacy consensus > compatibility for users up until the HardForkHeight block height, after > which backwards compatibility is waived as enforcement of the hard fork > consensus ruleset begins. > > > =3D=3D=3DReferences=3D=3D=3D > > [1] > https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133= 521fe9a77 > [2] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014380.h= tml > [3] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki > [4] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013921= .html > [5] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014399.h= tml > [6] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013= 542.html > [7] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/0134= 73.html > [8] https://twitter.com/sysmannet/status/867124645279006720 > [9] https://twitter.com/JihanWu/status/867139046786465792 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >