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
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5D60D94D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 12:36:41 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 699271CF
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 12:36:40 +0000 (UTC)
Received: from [162.186.187.200] (unknown [172.56.7.92])
by mail.bluematt.me (Postfix) with ESMTPSA id C854D56654;
Wed, 19 Aug 2015 12:36:37 +0000 (UTC)
In-Reply-To: <CABm2gDpBLKxKbHyWocOuyfO1VZ45yM7U1t+zVL_13LP9veXmcA@mail.gmail.com>
References: <20150819055036.GA19595@muck>
<CAOG=w-unJ+xnWFgiBO3jmgj4Q72ZH6-LOn08TwUF58trc-_WWg@mail.gmail.com>
<CABm2gDpBLKxKbHyWocOuyfO1VZ45yM7U1t+zVL_13LP9veXmcA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
From: Matt Corallo <lf-lists@mattcorallo.com>
Date: Wed, 19 Aug 2015 12:36:33 +0000
To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@jtimon.cc>,
=?ISO-8859-1?Q?Jorge_Tim=F3n_via_bitcoin-dev?=
<bitcoin-dev@lists.linuxfoundation.org>,
Mark Friedenbach <mark@friedenbach.org>
Message-ID: <7E94D4CF-3129-4DEA-A30B-CC7B4207D3EE@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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>,
Pieter Wuille <pieter.wuille@gmail.com>
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 12:36:41 -0000
Wait, why did Bitcoin-XT use that nVersion???
Definitely option 3 is much cleaner technically, and it would be nice to have that code implemented, but I'd be rather concerned about the size of the fork ballooning. It's already four separate features in one fork, which seems pretty big, even if the code isn't too huge. I'd probably prefer slightly to waste another two version bits than add a bunch of code to the fork now (maybe we can take just a part of the bit-based approach and allow lower version numbers again after the fork reaches 95%?). Either way, a proper version of the bit-based soft forking mechanism should be implemented sooner rather than later (maybe merged unused, even).
Still, it is entirely possible that there is relatively little uptake on XT and a competing proposal has a lot of support before we want to ship a LTV fork, so it may all be moot (or we could choose option 1 to fix the XT fork for them - easily forking off XT miners when either fork happens so XT isn't vulnerable to the 25% attack without needing to mine a massive transaction on Bitcoin first :p).
Matt
On August 19, 2015 11:34:54 AM GMT+02:00, "Jorge Timón via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
>Seems like 3 is something we want to do no matter what and therefore
>is the "most future-proof" solution.
>I wonder if I can help with that (and I know there's more people that
>would be interested).
>Where's the current "non-full" nVersion bits implementation?
>Why implement a "non-full" version instead of going with the full
>implementation directly?
>
>
>On Wed, Aug 19, 2015 at 8: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.
>>
>> 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
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
