Return-Path: <mark@friedenbach.org> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3E4D326C for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 20 Aug 2015 17:43:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 67A6514E for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 20 Aug 2015 17:43:06 +0000 (UTC) Received: by iods203 with SMTP id s203so54683549iod.0 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 20 Aug 2015 10:43:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Dgx/OpqU9mAnrzdFzkNr4QZ+iNZfSldV1jRqHyS5IAo=; b=NB3lHNHftdmz8Z/wEdHwGJrVi+KDgwLVAe4t8Te7NkVKW9JMKvc1LJIhlsQe+Zz4JX FUMjBWV0xkHULNYN7lKhEc2AYiZ0NiV90oa4ge+iMVMOgLupky1yLYmt7Ah+JHT+RnNq fxmuHj92BsrVLFCNx+kyiuB/1eU+OU2ygiX/Bx+67Izk6fjYq7Rwd4LSpqLZijuHwwuo spvbYacdZSgLZyzXdfbfjCxQ9JJgKlRGvMyBdQhIRxh7ckMk7quUarnt/O3IlCs9lhYO UcEbqg7ZmOOeVhajLlRa4d0vTkhfR05WFo8x8cjgcsFt4eK/AA6zKhRC/sMYYBV9M5bx 2ErA== X-Gm-Message-State: ALoCoQk5TkMe6cczL8UI5SjVb5MiUAc1zQdhSD+9eMkkAtTy+FHWZcLeAG4PBwvP5yfJ4BkvYZ8X X-Received: by 10.107.130.28 with SMTP id e28mr4540154iod.77.1440092585704; Thu, 20 Aug 2015 10:43:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.138.14 with HTTP; Thu, 20 Aug 2015 10:42:45 -0700 (PDT) X-Originating-IP: [173.228.107.141] In-Reply-To: <c20a83f511d7023f9cdd2df4713cddf9@xbt.hk> References: <20150819055036.GA19595@muck> <c20a83f511d7023f9cdd2df4713cddf9@xbt.hk> From: Mark Friedenbach <mark@friedenbach.org> Date: Thu, 20 Aug 2015 10:42:45 -0700 Message-ID: <CAOG=w-tA0Rme_geadjaZCP4QRYb2T0y7PGCZ-QbjGVt2H+=z=w@mail.gmail.com> To: jl2012@xbt.hk Content-Type: multipart/alternative; boundary=001a113fb70003d64b051dc1af8c X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development 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: Thu, 20 Aug 2015 17:43:07 -0000 --001a113fb70003d64b051dc1af8c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No, the nVersion would be >=3D 4, so that we don't waste any version values= . On Thu, Aug 20, 2015 at 10:32 AM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Peter Todd via bitcoin-dev =E6=96=BC 2015-08-19 01:50 =E5=AF=AB=E5=88=B0: > > >> >> 2) nVersion mask, with IsSuperMajority() >> >> In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would >> be masked away, prior to applying standard IsSuperMajority() logic: >> >> block.nVersion & ~0x20000007 >> >> This means that CLTV/CSV/etc. miners running Bitcoin Core would create >> blocks with nVersion=3D8, 0b1000. From the perspective of the >> CLTV/CSV/etc. IsSuperMajority() test, XT/Not-Bitcoin-XT miners would be >> advertising blocks that do not trigger the soft-fork. >> >> For the perpose of soft-fork warnings, the highest known version can >> remain nVersion=3D8, which is triggered by both XT/Not-Bitcoin-XT blocks >> as well as a future nVersion bits implementation. Equally, >> XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an >> unknown bit set. >> >> When nVersion bits is implemented by the Bitcoin protocol, the plan of >> setting the high bits to 0b001 still works. The three lowest bits will >> be unusable for some time, but will be eventually recoverable as >> XT/Not-Bitcoin-XT mining ceases. >> >> Equally, further IsSuperMajority() softforks can be accomplished with >> the same masking technique. >> >> This option does complicate the XT-coin protocol implementation in the >> future. But that's their problem, and anyway, the maintainers >> (Hearn/Andresen) has strenuously argued(5) against the use of soft-forks >> and/or appear to be in favor of a more centralized mandatory update >> schedule.(6) >> >> > If you are going to mask bits, would you consider to mask all bits except > the 4th bit? So other fork proposals may use other bits for voting > concurrently. > > And as I understand, the masking is applied only during the voting stage? > After the softfork is fully enforced with 95% support, the nVersion will = be > simply >=3D8, without any masking? > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a113fb70003d64b051dc1af8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">No, the nVersion would be >=3D 4, so that we don't = waste any version values.<br></div><div class=3D"gmail_extra"><br><div clas= s=3D"gmail_quote">On Thu, Aug 20, 2015 at 10:32 AM, jl2012 via bitcoin-dev = <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o= rg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> = wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex">Peter Todd via bitcoin-dev =E6=96= =BC 2015-08-19 01:50 =E5=AF=AB=E5=88=B0:<span class=3D""><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> <br> 2) nVersion mask, with IsSuperMajority()<br> <br> In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would<br> be masked away, prior to applying standard IsSuperMajority() logic:<br> <br> =C2=A0 =C2=A0 block.nVersion & ~0x20000007<br> <br> This means that CLTV/CSV/etc. miners running Bitcoin Core would create<br> blocks with nVersion=3D8, 0b1000. From the perspective of the<br> CLTV/CSV/etc.=C2=A0 IsSuperMajority() test, XT/Not-Bitcoin-XT miners would = be<br> advertising blocks that do not trigger the soft-fork.<br> <br> For the perpose of soft-fork warnings, the highest known version can<br> remain nVersion=3D8, which is triggered by both XT/Not-Bitcoin-XT blocks<br= > as well as a future nVersion bits implementation. Equally,<br> XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an<br> unknown bit set.<br> <br> When nVersion bits is implemented by the Bitcoin protocol, the plan of<br> setting the high bits to 0b001 still works. The three lowest bits will<br> be unusable for some time, but will be eventually recoverable as<br> XT/Not-Bitcoin-XT mining ceases.<br> <br> Equally, further IsSuperMajority() softforks can be accomplished with<br> the same masking technique.<br> <br> This option does complicate the XT-coin protocol implementation in the<br> future. But that's their problem, and anyway, the maintainers<br> (Hearn/Andresen) has strenuously argued(5) against the use of soft-forks<br= > and/or appear to be in favor of a more centralized mandatory update<br> schedule.(6)<br> <br> </blockquote> <br></span> If you are going to mask bits, would you consider to mask all bits except t= he 4th bit? So other fork proposals may use other bits for voting concurren= tly.<br> <br> And as I understand, the masking is applied only during the voting stage? A= fter the softfork is fully enforced with 95% support, the nVersion will be = simply >=3D8, without any masking?<div class=3D"HOEnZb"><div class=3D"h5= "><br> _______________________________________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br> </div></div></blockquote></div><br></div> --001a113fb70003d64b051dc1af8c--