public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: 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 14:22:26 +0100	[thread overview]
Message-ID: <CAE-z3OWjvR73jHrGhozxgqr_QUDu_hvDmHJWdiEGOcAGMB9oqA@mail.gmail.com> (raw)
In-Reply-To: <CAOG=w-unJ+xnWFgiBO3jmgj4Q72ZH6-LOn08TwUF58trc-_WWg@mail.gmail.com>

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

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.

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

  parent reply	other threads:[~2015-08-19 13:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-19  5:50 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 [this message]
2015-08-19 14:01     ` Jeff Garzik
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=CAE-z3OWjvR73jHrGhozxgqr_QUDu_hvDmHJWdiEGOcAGMB9oqA@mail.gmail.com \
    --to=tier.nolan@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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