1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 734569A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 05:50:52 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149101.authsmtp.com (outmail149101.authsmtp.com
[62.13.149.101])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 31835134
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 05:50:50 +0000 (UTC)
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7J5on60056338
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 06:50:49 +0100 (BST)
Received: from muck ([24.114.40.22]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7J5obJu058591
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 06:50:44 +0100 (BST)
Date: Tue, 18 Aug 2015 22:50:36 -0700
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20150819055036.GA19595@muck>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy"
Content-Disposition: inline
X-Server-Quench: 3dd8bf27-4636-11e5-9f75-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
P1hyKltILEZaQVBf Ri5dBBEKBAw1ADwr dVUTOktca1U/GlJ1
UkhIR0JSEg9tARYF DlAcVgdzdgFYfH5u Z0R9W3hcQ0U0MUEH
RxEGbygGYG9lYWFR VkBYd01XJFdCLElH bU17UnALfGQGM399
TgFsYnVpZW8CeXxc G1pQIQkEamI3IHkX fC5FECkkWwUJSj03
KA0jJ1gAVE0WNF4z PVY7UE4ZNBkJQgFD EglRB2dpGx4nQDZu
JwJGVkkfFg1hI29Z AxslOAQg
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 24.114.40.22/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
Subject: [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 05:50:52 -0000
--KsGdsel6WgEHnImy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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=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. 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=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:
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. 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",
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/3248c9f67bd7fcd1d05b8db7c5c56e478=
8deebfe
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
--=20
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
--KsGdsel6WgEHnImy
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJV1BkoXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNDAyZmU2ZmI5YWQ2MTNjOTNlMTJiZGRmYzZlYzAyYTJi
ZDkyZjAwMjA1MDU5NGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udze8wf/XBQP1HOKr1qecHxhGt16e/1G
RIckZlhgyZReYnor2yoAnemwRN7WVXEbEDwSKqAkfUQ/GQRRxZeHgNLAmi9vdivf
U4avuivy6zuDdgBpTkR1lwYIXymFnUklm+QcYy4YHJhuO1Pql9W3BIUKBvCgCKJF
ig2zAAYUPvhoqstER8MwNQh9u4AndLS6ZzCXd7ML76KXjOXmdCds+RbaLO78QmXf
WmueIxpW3slLM7ipxW5w5Jlyo9GkGDCxuCxnjZL7TRyGqVrq39KzJMcx33yHsPGc
xX1gvxyte3WuOGL13PhS9mmnm1fo/ntIBUHQMh6s/r8+vOI9yAaezSIEPiRJlQ==
=wLCH
-----END PGP SIGNATURE-----
--KsGdsel6WgEHnImy--
|
