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
|
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 3E4D326C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 17:43:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f176.google.com (mail-io0-f176.google.com
[209.85.223.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 67A6514E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 17:43:06 +0000 (UTC)
Received: by iods203 with SMTP id s203so54683549iod.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 10:43:05 -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:from:date
:message-id:subject:to:cc:content-type;
bh=Dgx/OpqU9mAnrzdFzkNr4QZ+iNZfSldV1jRqHyS5IAo=;
b=NB3lHNHftdmz8Z/wEdHwGJrVi+KDgwLVAe4t8Te7NkVKW9JMKvc1LJIhlsQe+Zz4JX
FUMjBWV0xkHULNYN7lKhEc2AYiZ0NiV90oa4ge+iMVMOgLupky1yLYmt7Ah+JHT+RnNq
fxmuHj92BsrVLFCNx+kyiuB/1eU+OU2ygiX/Bx+67Izk6fjYq7Rwd4LSpqLZijuHwwuo
spvbYacdZSgLZyzXdfbfjCxQ9JJgKlRGvMyBdQhIRxh7ckMk7quUarnt/O3IlCs9lhYO
UcEbqg7ZmOOeVhajLlRa4d0vTkhfR05WFo8x8cjgcsFt4eK/AA6zKhRC/sMYYBV9M5bx
2ErA==
X-Gm-Message-State: ALoCoQk5TkMe6cczL8UI5SjVb5MiUAc1zQdhSD+9eMkkAtTy+FHWZcLeAG4PBwvP5yfJ4BkvYZ8X
X-Received: by 10.107.130.28 with SMTP id e28mr4540154iod.77.1440092585704;
Thu, 20 Aug 2015 10:43:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.138.14 with HTTP; Thu, 20 Aug 2015 10:42:45 -0700 (PDT)
X-Originating-IP: [173.228.107.141]
In-Reply-To: <c20a83f511d7023f9cdd2df4713cddf9@xbt.hk>
References: <20150819055036.GA19595@muck>
<c20a83f511d7023f9cdd2df4713cddf9@xbt.hk>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Thu, 20 Aug 2015 10:42:45 -0700
Message-ID: <CAOG=w-tA0Rme_geadjaZCP4QRYb2T0y7PGCZ-QbjGVt2H+=z=w@mail.gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=001a113fb70003d64b051dc1af8c
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: Thu, 20 Aug 2015 17:43:07 -0000
--001a113fb70003d64b051dc1af8c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
No, the nVersion would be >=3D 4, so that we don't waste any version values=
.
On Thu, Aug 20, 2015 at 10:32 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Peter Todd via bitcoin-dev =E6=96=BC 2015-08-19 01:50 =E5=AF=AB=E5=88=B0:
>
>
>>
>> 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)
>>
>>
> If you are going to mask bits, would you consider to mask all bits except
> the 4th bit? So other fork proposals may use other bits for voting
> concurrently.
>
> And as I understand, the masking is applied only during the voting stage?
> After the softfork is fully enforced with 95% support, the nVersion will =
be
> simply >=3D8, without any masking?
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113fb70003d64b051dc1af8c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">No, the nVersion would be >=3D 4, so that we don't =
waste any version values.<br></div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Thu, Aug 20, 2015 at 10:32 AM, jl2012 via bitcoin-dev =
<span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">Peter Todd via bitcoin-dev =E6=96=
=BC 2015-08-19 01:50 =E5=AF=AB=E5=88=B0:<span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<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 & ~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'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>
</blockquote>
<br></span>
If you are going to mask bits, would you consider to mask all bits except t=
he 4th bit? So other fork proposals may use other bits for voting concurren=
tly.<br>
<br>
And as I understand, the masking is applied only during the voting stage? A=
fter the softfork is fully enforced with 95% support, the nVersion will be =
simply >=3D8, without any masking?<div class=3D"HOEnZb"><div class=3D"h5=
"><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
</div></div></blockquote></div><br></div>
--001a113fb70003d64b051dc1af8c--
|
