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 0F69797 for ; Wed, 19 Aug 2015 06:10:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 04DB989 for ; Wed, 19 Aug 2015 06:10:25 +0000 (UTC) Received: by igbjg10 with SMTP id jg10so97701762igb.0 for ; Tue, 18 Aug 2015 23:10:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8PIuj3Pg/I41NUz/eX0BfMlGNosHqcpOqoUpVOJRe6M=; b=MNUDFviKofhtWRot7z6EflW90t8TYuPURc8lmn+lZkKfEwzVYQL2GUiqM18dd+p0ob f40rWDabGfR+MAgWTRDyqNwBFarsAQVhf6gvcw9p4myWtEUkfuTTpADmvtfhLTWDRrdS qrkifft7zEz7vDQ2UkcxT5IWOXpRKPcbbYkPayCvckcm8azz4lbU2B07U1nvEaOzg+Y5 255qkooQBEFSm2oQiixOaXkR++4MGQxMBL9+CXrva4mwW6cnfTlvba+ejmpNtn65EEuo ZjXhkvm7rR3IXMYgFZNflvMjcraF7xgOloDNC9hdw62ZJAZUkXRAcLLgpiyy/LC0vZsh smnQ== X-Gm-Message-State: ALoCoQkaR583Lt8Qv38Yi8aOyNqemaGASV+vVRPKUAogM1aKq7VFsUEq1MxlhxnCiVqd15lb6XQk MIME-Version: 1.0 X-Received: by 10.50.112.229 with SMTP id it5mr28028645igb.46.1439964625415; Tue, 18 Aug 2015 23:10:25 -0700 (PDT) Received: by 10.107.138.14 with HTTP; Tue, 18 Aug 2015 23:10:25 -0700 (PDT) X-Originating-IP: [172.56.17.71] Received: by 10.107.138.14 with HTTP; Tue, 18 Aug 2015 23:10:25 -0700 (PDT) In-Reply-To: <20150819055036.GA19595@muck> References: <20150819055036.GA19595@muck> Date: Tue, 18 Aug 2015 23:10:25 -0700 Message-ID: From: Mark Friedenbach To: Peter Todd Content-Type: multipart/alternative; boundary=089e0118417efccf1b051da3e301 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 06:10:28 -0000 --089e0118417efccf1b051da3e301 Content-Type: text/plain; charset=UTF-8 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 > > --089e0118417efccf1b051da3e301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

We can use nVersion & 0x8 to signal support, while keepi= ng the consensus rule as nVersion >=3D 4, right? That way we don't w= aste a bit after this all clears up.

On Aug 18, 2015 10:50 PM, "Peter Todd via b= itcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
Deployment of the proposed CLTV, CSV, e= tc. soft-forks has been recently
complicated by the existence of XT(1) and Not-Bitcoin-XT(2) miners. Both mine blocks with nVersion=3D0x20000007, which would falsely trigger the
previously suggested implementation using the IsSuperMajority()
mechanism and nVersion=3D4 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=3D0x20000007,
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. Eq= ually
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=3D4

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:

=C2=A0 =C2=A0 block.nVersion & ~0x20000007

This means that CLTV/CSV/etc. miners running Bitcoin Core would create
blocks with nVersion=3D8, 0b1000. From the perspective of the
CLTV/CSV/etc.=C2=A0 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=3D8, 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",
=C2=A0 =C2=A0 Pieter Wuille, May 26th 2015, Bitcoin-development mailing lis= t,
=C2=A0 =C2=A0 http://list= s.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008282.html,
=C2=A0 =C2=A0 https://gist.github.com/sipa/bf69659f= 43e763540550

4) https://github.com= /bitcoin/bips/commit/3248c9f67bd7fcd1d05b8db7c5c56e4788deebfe

5) "On consensus and forks - What is the difference between a hard and= soft fork?",
=C2=A0 =C2=A0Mike Hearn, Aug 12th 2015,
=C2=A0 =C2=A0https://medium.com/@o= ctskyward/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/mail= man/listinfo/bitcoin-dev

--089e0118417efccf1b051da3e301--