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 83F158F0 for ; Wed, 19 Aug 2015 16:33:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 43AC718D for ; Wed, 19 Aug 2015 16:33:09 +0000 (UTC) Received: by iodv127 with SMTP id v127so15276930iod.3 for ; Wed, 19 Aug 2015 09:33:08 -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=XQ4QLNRMaR4Yc7H8SYHQKwa+s1A6c32uzEgGbxswBvE=; b=clyGZB1Ftojm3LP30LR0EPqHK9HlS6NRGhEH3g2fFhgpm/26bh35C9UbP75VXJ6XFn pn3+PAx+IeIirIQl1xGdApC+Vm6VaYWu1GrU+E0KzqJtmk/VFofnE/Gf9OxOwqJEN8x4 3okHXIEyoKU+gIx/kZrCpm2axvQRPmwC+aJ4M41xGd2Dow6f38STfM2m/1L/yvKkWHHM G4ENMR3QH0Gh3u2lIswjSJIrFu5GkxWhOAJBILWQmVpib01iRu+pshv4bETycve/RgXr wwsjsDkY7yAkkOc2m5eY1puxzVJHq6x0PtThHKO7SbfViqMXDyV/kgTQll6lvo00C1my L+rg== X-Gm-Message-State: ALoCoQmITw/gIEj+cTieEcSL6f6EPkKDPXXyLmubEBH9Y2xwCQr5TccyFWjS67ZXU8RIVu+9E6nE X-Received: by 10.107.35.138 with SMTP id j132mr15267670ioj.159.1440001988681; Wed, 19 Aug 2015 09:33:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.138.14 with HTTP; Wed, 19 Aug 2015 09:32:49 -0700 (PDT) X-Originating-IP: [50.0.37.37] In-Reply-To: References: <20150819055036.GA19595@muck> From: Mark Friedenbach Date: Wed, 19 Aug 2015 09:32:49 -0700 Message-ID: To: Tier Nolan Content-Type: multipart/alternative; boundary=001a1140f4e602fbb5051dac9793 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 16:33:10 -0000 --001a1140f4e602fbb5051dac9793 Content-Type: text/plain; charset=UTF-8 I think you misunderstand my suggestion Tier. I am suggesting the same as BtcDrak, I think: Modify IsSuperMajority to take an (optional) mask field. Bits set in that mask are zero'd for the purpose of the IsSuperMajority calculation. For this vote we mask bits 0x20000007. Thus to signal support for CLTV/CSV/etc. (on Core, XT, or not-XT), you set bit 4. On Core this would mean a minimum version of 0x8, on XT/not-XT a minimum version of 0x20000008. However the vote is still over whether to enforce BIP 65, 68, etc. for blocks with nVersion>=4. So when this all clears up we haven't needlessly wasted an additional bit. On Wed, Aug 19, 2015 at 6:22 AM, Tier Nolan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Aug 19, 2015 at 7:10 AM, Mark Friedenbach via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> We can use nVersion & 0x8 to signal support, while keeping the consensus >> rule as nVersion >= 4, right? That way we don't waste a bit after this all >> clears up. >> > What happens if XT gets 40% and this BIP gets 55%? That gives 95% that > accept the upgrade. Version 3 and lower blocks need to be rejected after > that. > > By advertising 0x7 for the last 3 bits, XT is effectively claiming to > support the check locktime verify BIPs but they don't have the code. > > This sequence could be used, without a specific version-bits proposal. > > Until height = N + 5000, if 950 of the last 1000 blocks have the 0x8 bit > set, then reject blocks with version numbers less than 8. > > At height N, if the above rule is active, then the BIP is permanent. > > It applies to any block with bit 0x8 set, once the 75% threshold is met. > > From height N + 5000 to N + 10000, reject blocks which have bit 0x8 set. > > N could be set 1 year from now, or so. > > > This gives a period of time after lock that bit 8 is kept and then a > period where is is guaranteed to be zero. > > This gives software that is only watching the bit time to be upgraded and > similarly time where the bit is set to zero before it can be reused. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a1140f4e602fbb5051dac9793 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think you misunderstand my suggestion Tie= r. I am suggesting the same as BtcDrak, I think:

Modify IsSupe= rMajority to take an (optional) mask field. Bits set in that mask are zero&= #39;d for the purpose of the IsSuperMajority calculation. For this vote we = mask bits 0x20000007.

Thus to signal support for CLTV/CSV/etc.= (on Core, XT, or not-XT), you set bit 4. On Core this would mean a minimum= version of 0x8, on XT/not-XT a minimum version of 0x20000008.

However the vote is still over whether to enforce BIP 65, 68, etc. for blo= cks with nVersion>=3D4. So when this all clears up we haven't needle= ssly wasted an additional bit.

On Wed, Aug 19, 2015 at 6:22 AM, Tier Nolan via bitc= oin-dev <bitcoin-dev@lists.linuxfoundation.org>= wrote:
On Wed, Aug 1= 9, 2015 at 7:10 AM, Mark Friedenbach via bitcoin-dev <= = bitcoin-dev@lists.linuxfoundation.org> wrote:

We can use nVersion & 0x8 to signal s= upport, while keeping the consensus rule as nVersion >=3D 4, right? That= way we don't waste a bit after this all clears up.

What happens if XT gets 40% and this BIP gets 55%?=C2=A0 Tha= t gives 95% that accept the upgrade.=C2=A0 Version 3 and lower blocks need = to be rejected after that.

By advertising 0x7 for the last 3 bits, X= T is effectively claiming to=20 support the check locktime verify BIPs but they don't have the code.
This sequence could be used, without = a specific version-bits proposal.

<= /div>
Until height =3D N + 5000, if 95= 0 of the last 1000 blocks have the 0x8 bit set, then reject blocks with ver= sion numbers less than 8.

At height N, if the above rule = is active, then the BIP is permanent.=C2=A0

It applies to any block= with bit 0x8 set, once the 75% threshold is met.

From he= ight N + 5000 to N + 10000, reject blocks which have bit 0x8 set.
=

N could be set 1 year from now, or so.


This gives a period of time after lock that bit 8 is kept = and then a period where is is guaranteed to be zero.

This= gives software that is only watching the bit time to be upgraded and simil= arly time where the bit is set to zero before it can be reused.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a1140f4e602fbb5051dac9793--