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 6A72E9B9 for ; Wed, 19 Aug 2015 14:01:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A243E203 for ; Wed, 19 Aug 2015 14:01:26 +0000 (UTC) Received: by wicja10 with SMTP id ja10so121083355wic.1 for ; Wed, 19 Aug 2015 07:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X+7HThsa7itNiXXN4lMMq9b8G4sT8+k4JYBEEtEDAvo=; b=VNar2jhvJRNTEzfz7t5UeQrM7dr+r3yVq/CN6flZT80rneZzVxOMD4yoUOuECqDLZK Ew8EoLUr+kaTy9caJMIpenIVPT8D+q4iAu8omeIauBjpiGaEgy37P3Henjmd+tVOpAd+ wJzA7lh+HwklLmJDUPP9OOfgzetij3ApQ5GMvIZETkxuwRDtvLCEDGF8QsdePLvNRV+x t6ZTdNv9z5f3MKzSRPuG9VL4EpuJ/GS6Bcg5tMLveuGN8/EdvjjSCMn11wRLrAtLZiBq TgOp9thyfYqRQM/R0y/cyNYizIl4I3+HTvPF92Whx4F9AhOteat6jotVhdvRgPnJ+a2y OnZw== MIME-Version: 1.0 X-Received: by 10.195.18.5 with SMTP id gi5mr24955882wjd.0.1439992885510; Wed, 19 Aug 2015 07:01:25 -0700 (PDT) Received: by 10.28.52.84 with HTTP; Wed, 19 Aug 2015 07:01:25 -0700 (PDT) In-Reply-To: References: <20150819055036.GA19595@muck> Date: Wed, 19 Aug 2015 10:01:25 -0400 Message-ID: From: Jeff Garzik To: Tier Nolan Content-Type: multipart/alternative; boundary=001a11c282146b8a08051daa787c X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 14:01:28 -0000 --001a11c282146b8a08051daa787c Content-Type: text/plain; charset=UTF-8 A lot of this detail and worry is eliminated by simply asking BIP 102 maintainers to change to a different bit that works best for everyone. Existing nVersion garbage will get buried in sufficient time window to prevent anything from triggering. Just settle on a specific standard, reserve bits for feature upgrade forks, and move on. There is already a rough standard proposed in sipa's gist. On Wed, Aug 19, 2015 at 9: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 > > --001a11c282146b8a08051daa787c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A lot of this detail and worry is eliminated by simply ask= ing BIP 102 maintainers to change to a different bit that works best for ev= eryone.=C2=A0 Existing nVersion garbage will get buried in sufficient time = window to prevent anything from triggering.

Just settle = on a specific standard, reserve bits for feature upgrade forks, and move on= .=C2=A0 There is already a rough standard proposed in sipa's gist.





On Wed, Aug 19, 2015 at 9= :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 nVe= rsion & 0x8 to signal support, while keeping the consensus rule as nVer= sion >=3D 4, right? That way we don't waste a bit after this all cle= ars up.

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

By advertising= 0x7 for the last 3 bits, XT 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


--001a11c282146b8a08051daa787c--