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
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <165318903@qq.com>) id 1YzR3P-0002d3-Nf
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 14:51:05 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of qq.com
designates 54.206.16.166 as permitted sender)
client-ip=54.206.16.166; envelope-from=165318903@qq.com;
helo=smtpbgau1.qq.com;
Received: from smtpbgau1.qq.com ([54.206.16.166])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1YzR3G-000267-5i
for bitcoin-development@lists.sourceforge.net;
Mon, 01 Jun 2015 14:51:03 +0000
X-QQ-mid: esmtp28t1433170228t645t19309
Received: from [10.28.176.243] (unknown [113.200.205.53])
by esmtp4.qq.com (ESMTP) with
id ; Mon, 01 Jun 2015 22:50:27 +0800 (CST)
X-QQ-SSF: 0000000000000060FG101F00000000Z
X-QQ-FEAT: c5qDthjzSWg+6X+f4OYij70ivP/CNG95jBDuzO7ERFAAWUTHjaYR63cSRbCcm
tCI4Kd69Qs9E2gu1VrFxUvWzJ9cpwBG4TwmGyUm2RO8IWN2BGrWkQvOscgWlMU8x2WWlWaW
watjOlyHJCrxwPKYAiPwdbvTm4yNwI1NnPintxCCdigyx9KGETSRux4VNiF/MP0gNNiGuvL
MjJRDvsMAZwjql1wihcDV8dLtsDOmOei/+abwQZmN3bf7O69eThBb
X-QQ-GoodBg: 0
Content-Type: multipart/alternative;
boundary=Apple-Mail-2892A5B5-5A05-4068-95D8-012A6D7DC0CA
Mime-Version: 1.0 (1.0)
From: Potter QQ <165318903@qq.com>
X-Mailer: iPhone Mail (12B436)
In-Reply-To: <CAE-z3OVskd1JAE5g-WW2eDiPcxysYhbv-NsOYu7yKZvzu88VSg@mail.gmail.com>
Date: Mon, 1 Jun 2015 22:50:28 +0800
Content-Transfer-Encoding: 7bit
Message-Id: <F60298F2-D5C8-4D25-911E-4CBBE33183F3@qq.com>
References: <CAPg+sBg5TqQ=zjyZ7dp-d1oBGp31Krnix3zyt9suP4-AGbxW=Q@mail.gmail.com>
<201505270346.17014.luke@dashjr.org>
<CABm2gDoriDaQ1AjRDFxCT9zCNPQakJd9xRxfWkOJBf4v22hndQ@mail.gmail.com>
<CAE-z3OVAKyppLVEWR=qNX-_p5yVAj_0Y7Kw76o4qaywf2DKtVw@mail.gmail.com>
<20150527101516.GB25814@savin.petertodd.org>
<CAE-z3OVskd1JAE5g-WW2eDiPcxysYhbv-NsOYu7yKZvzu88VSg@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
X-QQ-SENDSIZE: 520
X-QQ-Bgrelay: 1
X-Spam-Score: -0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(165318903[at]qq.com)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [54.206.16.166 listed in list.dnswl.org]
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (165318903[at]qq.com)
1.0 HTML_MESSAGE BODY: HTML included in message
0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-Headers-End: 1YzR3G-000267-5i
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Version bits proposal
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2015 14:51:05 -0000
--Apple-Mail-2892A5B5-5A05-4068-95D8-012A6D7DC0CA
Content-Type: text/plain;
charset=gb2312
Content-Transfer-Encoding: quoted-printable
oh my God ...
=B7=A2=D7=D4=CE=D2=B5=C4 iPhone
> =D4=DA 2015=C4=EA5=D4=C227=C8=D5=A3=AC19:26=A3=ACTier Nolan <tier.nolan@gm=
ail.com> =D0=B4=B5=C0=A3=BA
>=20
>=20
>=20
>> On Wed, May 27, 2015 at 11:15 AM, Peter Todd <pete@petertodd.org> wrote:
>> The median time mechanism is basically a way for hashing power to show
>> what time they think it is. Equally, the nVersion soft-fork mechanism is
>> a way for hashing power to show what features they want to support.
>=20
> Fair enough. It means slightly more processing, but the median time could=
be cached in the header index, so no big deal.
>=20
>> Block counts are inconvenient for planning, as there's no guarantee
>> they'll actually happen in any particular time frame, forward and back.
>=20
> I don't think the deadline needs to be set that accurately. A roughly 6 m=
onth deadline should be fine, but as you say a majority of miners is needed t=
o abuse the median time and it is already a miner poll.
>=20
> Perhaps the number of blocks used in the median could be increased to redu=
ce "noise".
>=20
> The median time could be median of the last 144 blocks plus 12 hours.
> =20
>> If you assume no large reorganizations, your table of known BIPs can
>> just as easily be a list of block heights even if the median time
>> mechanism is used.
>=20
> I think it makes it easier to write the code. It reduced the state that n=
eeds to be stored per BIP. You don't need to check if the previous bips wer=
e all accepted.
>=20
> Each bit is assigned to a particular BIP for a particular range of times (=
or blocks).
>=20
> If block numbers were used for the deadline, you just need to check the bl=
ock index for the deadline block.
>=20
> enum {
> BIP_INACTIVE =3D 0,
> BIP_ACTIVE,
> BIP_LOCKED
> BIP_INVALID_BLOCK,
> }
>=20
> int GetBIPState(block, bip)=20
> {
> if (block.height =3D=3D bip.deadline) // Bit must be set to match loc=
ked/unlocked at deadline
> {
> int bipState =3D check_supermajority(...);
> if (bipState =3D=3D BIP_LOCKED && (block.nVersion & bip.bit)
> return BIP_LOCKED;
>=20
> if (bipState !=3D BIP_LOCKED && (block.nVersion & (~bip.bit)))
> return BIP_INACTIVE;
>=20
> return BIP_INVALID_BLOCK;
> }
>=20
> if (block.height > deadline) // Look at the deadline block to determin=
e if the BIP is locked
> return (block_index[deadline].nVersion & bip_bit) !=3D 0 ? BIP_LOC=
KED : BIP_INACTIVE;
>=20
> if (block.height < startline + I) // BIP cannot activate/lock until st=
artline + implicit window size
> return INACTIVE;
>=20
> return check_supermajority(....) // Check supermajority of bit
> }
>=20
> The block at height deadline would indicate if the BIP was locked in.
>=20
> Block time could still be used as long as the block height was set after t=
hat. The deadline_time could be in six months. The startline height could b=
e the current block height and the deadline_height could be startline + 3500=
0. =20
>=20
> The gives roughly
>=20
> start time =3D now
> deadline time =3D now + six months
> deadline height =3D now + eight months
>=20
> The deadline height is the block height when the bit is returned to the po=
ol but the deadline time is when the BIP has to be accepted.
>=20
> It also helps with the warning system. For each block height, there is a s=
et of known BIP bits that are allowed. Once the final deadline is passed, t=
he expected mask is zeros.
>=20
>> On Wed, May 27, 2015 at 11:15 AM, Jorge Tim=A8=AEn <jtimon@jtimon.cc> wro=
te:
>> On May 27, 2015 11:35 AM, "Tier Nolan" <tier.nolan@gmail.com> wrote:
>>=20
>> > Was the intention to change the 95% rule. You need 750 of the last 100=
0 to activate and then must wait at least 1000 for implication?
>>=20
>> You need 75% to start applying it, 95% to start rejecting blocks that don=
't apply it.
>=20
> I think the phrasing is ambiguous. I was just asking for clarification.
>=20
> "Whenever I out of any W subsequent blocks (regardless of the block itself=
) have bit B set,"
>=20
> That suggests that the I of W blocks for the 95% rule must happen after ac=
tivation. This makes the rule checking harder. Easier to use the current s=
ystem, where blocks that were part of the 750 rule also count towards the 95=
% rule.
> --------------------------------------------------------------------------=
----
>=20
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
--Apple-Mail-2892A5B5-5A05-4068-95D8-012A6D7DC0CA
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><span></span></div><div><meta http-equ=
iv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><div><span></span=
></div><div><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"><div>oh my God ...<br><br>=E5=8F=91=E8=87=AA=E6=88=91=E7=9A=84 iPhone=
</div><div><br>=E5=9C=A8 2015=E5=B9=B45=E6=9C=8827=E6=97=A5=EF=BC=8C19:26=EF=
=BC=8CTier Nolan <<a href=3D"mailto:tier.nolan@gmail.com">tier.nolan@gmai=
l.com</a>> =E5=86=99=E9=81=93=EF=BC=9A<br><br></div><blockquote type=3D"c=
ite"><div><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On Wed, May 27, 2015 at 11:15 AM, Peter Todd <span dir=3D"ltr">=
<<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.o=
rg</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><span class=3D"">
</span>The median time mechanism is basically a way for hashing power to sho=
w<br>
what time they think it is. Equally, the nVersion soft-fork mechanism is<br>=
a way for hashing power to show what features they want to support.<br>
<br></blockquote><div><br></div><div>Fair enough. It means slightly mo=
re processing, but the median time could be cached in the header index, so n=
o big deal.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Block counts are inconvenient for planning, as there's no guarantee<br>
they'll actually happen in any particular time frame, forward and back.<br><=
/blockquote><div><br></div><div>I don't think the deadline needs to be set t=
hat accurately. A roughly 6 month deadline should be fine, but as you s=
ay a majority of miners is needed to abuse the median time and it is already=
a miner poll.<br><br></div><div>Perhaps the number of blocks used in the me=
dian could be increased to reduce "noise".<br></div><div><br></div><div>The m=
edian time could be median of the last 144 blocks plus 12 hours.<br></div><d=
iv> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span cl=
ass=3D"">
</span>If you assume no large reorganizations, your table of known BIPs can<=
br>
just as easily be a list of block heights even if the median time<br>
mechanism is used.<br></blockquote><div><br></div><div>I think it makes it e=
asier to write the code. It reduced the state that needs to be stored p=
er BIP. You don't need to check if the previous bips were all accepted=
.<br><br></div><div>Each bit is assigned to a particular BIP for a particula=
r range of times (or blocks).<br></div><div><br></div><div>If block numbers w=
ere used for the deadline, you just need to check the block index for the de=
adline block.<br><br></div><div>enum {<br></div><div> BIP_=
INACTIVE =3D 0,<br></div><div> BIP_ACTIVE,<br></div><div>&=
nbsp; BIP_LOCKED<br> BIP_INVALID_BLOCK,<br>}<b=
r></div><div><br>int GetBIPState(block, bip) <br>{<br> if (=
block.height =3D=3D bip.deadline) // Bit must be set to match locked/u=
nlocked at deadline<br></div><div> {<br></div><div> &=
nbsp; int bipState =3D check_supermajority(...=
);<br></div><div> if (bipState =3D=
=3D BIP_LOCKED && (block.nVersion & bip.bit)<br></div><div> =
; return BIP_LOC=
KED;<br><br></div><div> if (bipSta=
te !=3D BIP_LOCKED && (block.nVersion & (~bip.bit)))<br></div><d=
iv> return=
BIP_INACTIVE;<br><br></div><div> r=
eturn BIP_INVALID_BLOCK;<br> }<br></div><br><div> &nb=
sp; if (block.height > deadline) // Look at the deadline block to d=
etermine if the BIP is locked<br> r=
eturn (block_index[deadline].nVersion & bip_bit) !=3D 0 ? BIP_LOCKED : B=
IP_INACTIVE;<br><br></div><div> if (block.height < star=
tline + I) // BIP cannot activate/lock until startline + implicit window siz=
e<br></div><div> return INACTIVE;<=
br></div><div><br> return check_supermajority(....) // Che=
ck supermajority of bit<br>}<br><br></div><div>The block at height deadline w=
ould indicate if the BIP was locked in.<br><br></div><div>Block time could s=
till be used as long as the block height was set after that. The deadl=
ine_time could be in six months. The startline height could be the cur=
rent block height and the deadline_height could be startline + 35000. <=
br><br></div><div>The gives roughly<br><br></div><div>start time =3D now<br>=
</div><div>deadline time =3D now + six months<br></div><div>deadline height =3D=
now + eight months<br><br></div><div>The deadline height is the block heigh=
t when the bit is returned to the pool but the deadline time is when the BIP=
has to be accepted.<br></div><div><br></div><div>It also helps with the war=
ning system. For each block height, there is a set of known BIP bits t=
hat are allowed. Once the final deadline is passed, the expected mask i=
s zeros.<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed=
, May 27, 2015 at 11:15 AM, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a href=3D=
"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D""><=
p dir=3D"ltr">
On May 27, 2015 11:35 AM, "Tier Nolan" <<a href=3D"mailto:tier.nolan@gmai=
l.com" target=3D"_blank">tier.nolan@gmail.com</a>> wrote:</p>
<p dir=3D"ltr">> Was the intention to change the 95% rule. You need=
=20
750 of the last 1000 to activate and then must wait at least 1000 for=20
implication?</p>
</span><p dir=3D"ltr">You need 75% to start applying it, 95% to start reject=
ing blocks that don't apply it.<br>
</p>
</blockquote></div><br></div>I think the phrasing is ambiguous. I was j=
ust asking for clarification.<br><br>"Whenever I out of any W <b>subsequent<=
/b> blocks (regardless of the block itself) have bit B set,"<br><br></div><d=
iv>That suggests that the I of W blocks for the 95% rule must happen after a=
ctivation. This makes the rule checking harder. Easier to use th=
e current system, where blocks that were part of the 750 rule also count tow=
ards the 95% rule.<br></div></div></div></div>
</div></blockquote><blockquote type=3D"cite"><div><span>--------------------=
----------------------------------------------------------</span><br><span><=
/span><br></div></blockquote><blockquote type=3D"cite"><div><span>__________=
_____________________________________</span><br><span>Bitcoin-development ma=
iling list</span><br><span><a href=3D"mailto:Bitcoin-development@lists.sourc=
eforge.net">Bitcoin-development@lists.sourceforge.net</a></span><br><span><a=
href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development">h=
ttps://lists.sourceforge.net/lists/listinfo/bitcoin-development</a></span><b=
r><span></span><br></div></blockquote></div></div></body></html>=
--Apple-Mail-2892A5B5-5A05-4068-95D8-012A6D7DC0CA--
|
