public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mark Friedenbach <mark@friedenbach.org>
To: Peter Todd <pete@petertodd.org>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners
Date: Tue, 18 Aug 2015 23:10:25 -0700	[thread overview]
Message-ID: <CAOG=w-unJ+xnWFgiBO3jmgj4Q72ZH6-LOn08TwUF58trc-_WWg@mail.gmail.com> (raw)
In-Reply-To: <20150819055036.GA19595@muck>

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

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.
On Aug 18, 2015 10:50 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Deployment of the proposed CLTV, CSV, etc. soft-forks has been recently
> complicated by the existence of XT(1) and Not-Bitcoin-XT(2) miners. Both
> mine blocks with nVersion=0x20000007, which would falsely trigger the
> previously suggested implementation using the IsSuperMajority()
> mechanism and nVersion=4 blocks. Additionally while the
> XT/Not-Bitcoin-XT software claims to support Wuille/Todd/Maxwell's
> nVersion soft-fork mechanism(3) a key component of it - fork
> deadlines(3) - is not implemented.
>
>
> XT/Not-Bitcoin-XT behavior
> --------------------------
>
> Both implementations produce blocks with nVersion=0x20000007,
> or in binary: 0b001...111
>
> Neither implementation supports a fork deadline; both Not-Bitcoin-XT and
> XT will produce blocks with those bits set indefinitely under any
> circumstance, with the proviso that while XT has a hashing power
> majority, blocks it produces might not be part of the Bitcoin blockchain
> after Jan 11th 2016. (though this can flap back and forth if reorgs
> happen)
>
> Curiously the BIP101 draft was changed(4) at the last minute from using
> the nVersion bits compliant 0x20000004 block nVersion, to using two more
> bits unnecessarily. The rational for doing this is unknown; the git
> commit message associated with the change suggested "compatibility
> concerns", but what the concerns actually were isn't specified. Equally
> even though implementing the fork deadline would be very each in the XT
> implementation, this was not done. (the XT codebase has had almost no
> peer review)
>
>
> Options for CLTV/CSV/etc. deployment
> ------------------------------------
>
> 1) Plain IsSuperMajority() with nVersion=4
>
> This option can be ruled out immediately due to the high risk of
> premature triggering, without genuine 95% miner support.
>
>
> 2) nVersion mask, with IsSuperMajority()
>
> In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would
> be masked away, prior to applying standard IsSuperMajority() logic:
>
>     block.nVersion & ~0x20000007
>
> This means that CLTV/CSV/etc. miners running Bitcoin Core would create
> blocks with nVersion=8, 0b1000. From the perspective of the
> CLTV/CSV/etc.  IsSuperMajority() test, XT/Not-Bitcoin-XT miners would be
> advertising blocks that do not trigger the soft-fork.
>
> For the perpose of soft-fork warnings, the highest known version can
> remain nVersion=8, which is triggered by both XT/Not-Bitcoin-XT blocks
> as well as a future nVersion bits implementation. Equally,
> XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an
> unknown bit set.
>
> When nVersion bits is implemented by the Bitcoin protocol, the plan of
> setting the high bits to 0b001 still works. The three lowest bits will
> be unusable for some time, but will be eventually recoverable as
> XT/Not-Bitcoin-XT mining ceases.
>
> Equally, further IsSuperMajority() softforks can be accomplished with
> the same masking technique.
>
> This option does complicate the XT-coin protocol implementation in the
> future. But that's their problem, and anyway, the maintainers
> (Hearn/Andresen) has strenuously argued(5) against the use of soft-forks
> and/or appear to be in favor of a more centralized mandatory update
> schedule.(6)
>
>
> 3) Full nVersion bits implementation
>
> The most complex option would be to deploy via full nVersion bits
> implementation using flag bit #4 to trigger the fork. Compliant miners
> would advertise 0x20000008 initially, followed by 0x20000000 once the
> fork had triggered. The lowest three bits would be unusable for forks
> for some time, although they could be eventually recovered as
> XT/Not-Bitcoin-XT mining ceases.
>
> The main disadvantage of this option is high initial complexity - the
> reason why IsSuperMajority() was suggested for CLTV/CSV in the first
> place. That said, much of the code required has been implemented in XT
> for the BIP101 hard-fork logic, although as mentioned above, the code
> has had very little peer review.
>
>
> References
> ----------
>
> 1) https://github.com/bitcoinxt/bitcoinxt
>
> 2) https://github.com/xtbit/notbitcoinxt
>
> 3) "Version bits proposal",
>     Pieter Wuille, May 26th 2015, Bitcoin-development mailing list,
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008282.html
> ,
>     https://gist.github.com/sipa/bf69659f43e763540550
>
> 4)
> https://github.com/bitcoin/bips/commit/3248c9f67bd7fcd1d05b8db7c5c56e4788deebfe
>
> 5) "On consensus and forks - What is the difference between a hard and
> soft fork?",
>    Mike Hearn, Aug 12th 2015,
>    https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7
>
> 6) 2013 San Jose Bitcoin conference developer round-table
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

  reply	other threads:[~2015-08-19  6:10 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 [this message]
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
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='CAOG=w-unJ+xnWFgiBO3jmgj4Q72ZH6-LOn08TwUF58trc-_WWg@mail.gmail.com' \
    --to=mark@friedenbach.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pete@petertodd.org \
    /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