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 --]
next prev parent reply other threads:[~2015-08-19 14:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-19 5:50 [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners Peter Todd
2015-08-19 6:10 ` Mark Friedenbach
2015-08-19 9:34 ` Jorge Timón
2015-08-19 10:20 ` Btc Drak
2015-08-19 10:31 ` Jorge Timón
2015-08-19 13:15 ` Btc Drak
2015-08-19 13:24 ` Tier Nolan
2015-08-19 17:25 ` Btc Drak
2015-08-19 18:17 ` Tier Nolan
2015-08-19 12:36 ` Matt Corallo
2015-08-19 13:22 ` Tier Nolan
2015-08-19 14:01 ` Jeff Garzik [this message]
2015-08-19 16:32 ` Mark Friedenbach
2015-08-19 21:03 ` Peter Todd
2015-08-20 17:32 ` jl2012
2015-08-20 17:42 ` Mark Friedenbach
2015-08-27 22:11 ` Btc Drak
-- strict thread matches above, loose matches on Subject: below --
2015-08-18 1:22 [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations Thomas Kerin
2015-08-19 1:04 ` Peter Todd
2015-08-19 1:08 ` Mark Friedenbach
2015-08-21 11:13 ` Thomas Kerin
2015-08-22 0:57 ` Peter Todd
2015-08-27 22:08 ` Btc Drak
2015-08-27 23:19 ` Peter Todd
2015-08-28 15:27 ` jl2012
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADm_Wca+k3zd17jDLxkp4sbx1Mz8d4DmTG50jAzzAu4v7eU8hw@mail.gmail.com \
--to=jgarzik@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=tier.nolan@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox