Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

From: Jeff Garzik <jgarzik@gmail•com>
To: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners
Date: Wed, 19 Aug 2015 10:01:25 -0400	[thread overview]
Message-ID: <CADm_Wca+k3zd17jDLxkp4sbx1Mz8d4DmTG50jAzzAu4v7eU8hw@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OWjvR73jHrGhozxgqr_QUDu_hvDmHJWdiEGOcAGMB9oqA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 3181 bytes --]