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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E5F39259
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 09:34:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com
[209.85.217.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DDB64112
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 09:34:55 +0000 (UTC)
Received: by lbbpu9 with SMTP id pu9so120141894lbb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Aug 2015 02:34:54 -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=TE3gmKMS8TSuMErGCREcIJLJ40jjjFI2LhRb47t+Kpw=;
b=Mpa85Nccw98R19Lwplj/UzbZRFxo23fcvHLC1X1+FsqdUkdjfwZDVZ2BjyVzfVWq0o
tT4wdCYswD8mvRm7EYJiqFB2SBZnBY89o28gzXYKVeiT1GBmx95+6H14+cNaqBuyI9fb
o3BpjzArsCPUQaqQeJviA//QtXGN1ZM+kmkzjxNDlZ6uCthiLWH1Or5s4Yc7lzSxyGe4
Tl60rzTuW8p55ASy8a+9bJVg/HrMUEjnsHOQvFUA84IqsHnPI30KgUFRDnPYRxjFLKDr
904824NUuagOldfbMC8ir3g0RqbN8YWE+5E2ZDmlqBBsNcH3/MB2VilGQFXMuh8CNZyn
SEHw==
X-Gm-Message-State: ALoCoQkUI884I2uzwd5UYPGH2CyTK1WbVYY1E/rvCXq+hCdnSxY47SCwRPAMeYOFoMnMoVvdTNGN
MIME-Version: 1.0
X-Received: by 10.112.11.233 with SMTP id t9mr8755427lbb.104.1439976894286;
Wed, 19 Aug 2015 02:34:54 -0700 (PDT)
Received: by 10.25.15.22 with HTTP; Wed, 19 Aug 2015 02:34:54 -0700 (PDT)
In-Reply-To: <CAOG=w-unJ+xnWFgiBO3jmgj4Q72ZH6-LOn08TwUF58trc-_WWg@mail.gmail.com>
References: <20150819055036.GA19595@muck>
<CAOG=w-unJ+xnWFgiBO3jmgj4Q72ZH6-LOn08TwUF58trc-_WWg@mail.gmail.com>
Date: Wed, 19 Aug 2015 11:34:54 +0200
Message-ID: <CABm2gDpBLKxKbHyWocOuyfO1VZ45yM7U1t+zVL_13LP9veXmcA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: text/plain; charset=UTF-8
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
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 09:34:57 -0000
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
>
|
