path: root/3b/b42b30cf46e1ed468ddf593cc5d3af330c00df

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0F69797
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 06:10:25 +0000 (UTC)
Received: by igbjg10 with SMTP id jg10so97701762igb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAOG=w-unJ+xnWFgiBO3jmgj4Q72ZH6-LOn08TwUF58trc-_WWg@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: Peter Todd <pete@petertodd.org>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

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

--089e0118417efccf1b051da3e301--