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
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
|
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 96F981434
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 20:27:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com
[209.85.212.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A7E7D1E6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 20:27:35 +0000 (UTC)
Received: by wiclk2 with SMTP id lk2so89816752wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 13:27:34 -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=AJrsAb6iI9T3xjgHmFKhhmONaeLmjALKOdmehFn8RIY=;
b=QtxJMm4IBU0UGoHKtY7hGTfl4xb+UwFKc86z+HVcui/T/wdojmWmkusz0xzFujlwfp
yjAkHN+GqBKc3aiLSo3ku2mzaiG5iL+Zvr4vccFZLaEoNjRHEvW/kHcF1ARslSyJrkyK
jMnJUqr866dapXLp6kiuG3NtMFxnC6wDCz/0+XvfBlAszhwxNOn3oNx5I3PcVLAT8TPA
IEzhmaoPqNDsQPVg4/sLxyjYqc9EfRD8/3Izfs8Go5/SlpWqLk7m5qwlXTVcH7Q1WHGY
uVDr/dBPrUSwNT3tD6zw/BqYZf/wXcSQvmTQ5T8+5OfD+x/0Y0UkDE2wYntAjQPDKogg
8Ztw==
X-Gm-Message-State: ALoCoQldbddrk2okTd0ZfHqVfpctcaWznEnDftaut9a//YI+cTAUEe0CjElXWKbvCZVI7pICmC6G
MIME-Version: 1.0
X-Received: by 10.194.120.198 with SMTP id le6mr55688845wjb.133.1442435254263;
Wed, 16 Sep 2015 13:27:34 -0700 (PDT)
Received: by 10.194.37.5 with HTTP; Wed, 16 Sep 2015 13:27:33 -0700 (PDT)
Received: by 10.194.37.5 with HTTP; Wed, 16 Sep 2015 13:27:33 -0700 (PDT)
In-Reply-To: <87r3lyjewl.fsf@rustcorp.com.au>
References: <87mvwqb132.fsf@rustcorp.com.au>
<CAE-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@mail.gmail.com>
<87r3lyjewl.fsf@rustcorp.com.au>
Date: Wed, 16 Sep 2015 22:27:33 +0200
Message-ID: <CABm2gDqh=Dv2Ygctg+jEt61N_nJDRBMqdZypSPtmfM2QrY4AYQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: multipart/alternative; boundary=089e01160002f15a0a051fe3205c
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] [BIP Proposal] Version bits with timeout and
delay.
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, 16 Sep 2015 20:27:36 -0000
--089e01160002f15a0a051fe3205c
Content-Type: text/plain; charset=UTF-8
For enforcing new restrictions on your own blocks (thus at the policy
level, not consensus) you don't need to wait for 75%. You can do it from
the start (this way all miners setting the bit will enforce the new
restrictions.
On Sep 16, 2015 4:20 PM, "Rusty Russell via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> writes:
> > On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> '''States'''
> >> With every softfork proposal we associate a state BState, which begins
> >> at ''defined'', and can be ''locked-in'', ''activated'',
> >> or ''failed''. Transitions are considered after each
> >> retarget period.
> >>
> >
> > I think the 75% rule should be maintained. It confirms that miners who
> are
> > setting the bit are actually creating blocks that meet the new rule
> (though
> > it doesn't check if they are enforcing it).
>
> I couldn't see a use for it, since partial enforcement of a soft fork is
> pretty useless.
>
> Your point about checking that miners are actually doing it is true,
> though all stuff being forked in in future will be nonstandard AFAICT.
>
> I bias towards simplicity for this.
>
> > What is the reason for aligning the updated to the difficulty window?
>
> Miners already have that date in their calendar, so prefer to anchor to
> that.
>
> > *defined*
> > Miners set bit
> > If 75% of blocks of last 2016 have bit set, goto tentative
> >
> >
> > *tentative*
> > Miners set bit
> > Reject blocks that have bit set that don't follow new rule
> > If 95% of blocks of last 2016 have bit set, goto locked-in
> >
> >
> > *locked-in*
> >
> > Point of no return
> > Miners still set bit
> > Reject blocks that have bit set that don't follow new rule
> > After 2016 blocks goto notice
>
> OK, *that* variant makes perfect sense, and is no more complex, AFAICT.
>
> So, there's two weeks to detect bad implementations, then you everyone
> stops setting the bit, for later reuse by another BIP.
>
> > I think counting in blocks is easier to be exact here.
>
> Easier for code, but harder for BIP authors.
>
> > If two bits were allocated per proposal, then miners could vote against
> > forks to recover the bits. If 25% of the miners vote against, then that
> > kills it.
>
> You need a timeout: an ancient (non-mining, thus undetectable) node
> should never fork itself off the network because someone reused a failed
> BIP bit.
>
> > In the rationale, it would be useful to discuss effects on SPV clients
> and
> > buggy miners.
> >
> > SPV clients should be recommended to actually monitor the version field.
>
> SPV clients don't experience a security change when a soft fork occurs?
> They're already trusting miners.
>
> Greg pointed out that soft forks tend to get accompanied by block forks
> across activation, but SPV clients should *definitely* be taking those
> into account whenever they happen, right?
>
> Thanks!
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--089e01160002f15a0a051fe3205c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">For enforcing new restrictions on your own blocks (thus at t=
he policy level, not consensus) you don't need to wait for 75%. You can=
do it from the start (this way all miners setting the bit will enforce the=
new restrictions.</p>
<div class=3D"gmail_quote">On Sep 16, 2015 4:20 PM, "Rusty Russell via=
bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attrib=
ution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">Tier Nolan via bitcoin-dev <<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxf=
oundation.org</a>><br>
writes:<br>
> On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev <<br=
>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a>> wrote:<br>
><br>
>> '''States'''<br>
>> With every softfork proposal we associate a state BState, which be=
gins<br>
>> at ''defined'', and can be ''locked-in'=
;', ''activated'',<br>
>> or ''failed''.=C2=A0 Transitions are considered af=
ter each<br>
>> retarget period.<br>
>><br>
><br>
> I think the 75% rule should be maintained.=C2=A0 It confirms that mine=
rs who are<br>
> setting the bit are actually creating blocks that meet the new rule (t=
hough<br>
> it doesn't check if they are enforcing it).<br>
<br>
I couldn't see a use for it, since partial enforcement of a soft fork i=
s<br>
pretty useless.<br>
<br>
Your point about checking that miners are actually doing it is true,<br>
though all stuff being forked in in future will be nonstandard AFAICT.<br>
<br>
I bias towards simplicity for this.<br>
<br>
> What is the reason for aligning the updated to the difficulty window?<=
br>
<br>
Miners already have that date in their calendar, so prefer to anchor to<br>
that.<br>
<br>
> *defined*<br>
> Miners set bit<br>
> If 75% of blocks of last 2016 have bit set, goto tentative<br>
><br>
><br>
> *tentative*<br>
> Miners set bit<br>
> Reject blocks that have bit set that don't follow new rule<br>
> If 95% of blocks of last 2016 have bit set, goto locked-in<br>
><br>
><br>
> *locked-in*<br>
><br>
> Point of no return<br>
> Miners still set bit<br>
> Reject blocks that have bit set that don't follow new rule<br>
> After 2016 blocks goto notice<br>
<br>
OK, *that* variant makes perfect sense, and is no more complex, AFAICT.<br>
<br>
So, there's two weeks to detect bad implementations, then you everyone<=
br>
stops setting the bit, for later reuse by another BIP.<br>
<br>
> I think counting in blocks is easier to be exact here.<br>
<br>
Easier for code, but harder for BIP authors.<br>
<br>
> If two bits were allocated per proposal, then miners could vote agains=
t<br>
> forks to recover the bits.=C2=A0 If 25% of the miners vote against, th=
en that<br>
> kills it.<br>
<br>
You need a timeout: an ancient (non-mining, thus undetectable) node<br>
should never fork itself off the network because someone reused a failed<br=
>
BIP bit.<br>
<br>
> In the rationale, it would be useful to discuss effects on SPV clients=
and<br>
> buggy miners.<br>
><br>
> SPV clients should be recommended to actually monitor the version fiel=
d.<br>
<br>
SPV clients don't experience a security change when a soft fork occurs?=
<br>
They're already trusting miners.<br>
<br>
Greg pointed out that soft forks tend to get accompanied by block forks<br>
across activation, but SPV clients should *definitely* be taking those<br>
into account whenever they happen, right?<br>
<br>
Thanks!<br>
Rusty.<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>
</blockquote></div>
--089e01160002f15a0a051fe3205c--
|
