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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1YxXjz-00066g-2S
for bitcoin-development@lists.sourceforge.net;
Wed, 27 May 2015 09:35:11 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.181 as permitted sender)
client-ip=209.85.220.181; envelope-from=tier.nolan@gmail.com;
helo=mail-qk0-f181.google.com;
Received: from mail-qk0-f181.google.com ([209.85.220.181])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YxXjw-0003VZ-UL
for bitcoin-development@lists.sourceforge.net;
Wed, 27 May 2015 09:35:11 +0000
Received: by qkx62 with SMTP id 62so2041257qkx.3
for <bitcoin-development@lists.sourceforge.net>;
Wed, 27 May 2015 02:35:03 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.33.6 with SMTP id h6mr62609843qkh.99.1432719303566; Wed,
27 May 2015 02:35:03 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Wed, 27 May 2015 02:35:03 -0700 (PDT)
In-Reply-To: <CABm2gDoriDaQ1AjRDFxCT9zCNPQakJd9xRxfWkOJBf4v22hndQ@mail.gmail.com>
References: <CAPg+sBg5TqQ=zjyZ7dp-d1oBGp31Krnix3zyt9suP4-AGbxW=Q@mail.gmail.com>
<201505270346.17014.luke@dashjr.org>
<CABm2gDoriDaQ1AjRDFxCT9zCNPQakJd9xRxfWkOJBf4v22hndQ@mail.gmail.com>
Date: Wed, 27 May 2015 10:35:03 +0100
Message-ID: <CAE-z3OVAKyppLVEWR=qNX-_p5yVAj_0Y7Kw76o4qaywf2DKtVw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1144bc4226ea1c05170cf5e5
X-Spam-Score: 3.3 (+++)
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
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
2.7 MALFORMED_FREEMAIL Bad headers on message from free email service
X-Headers-End: 1YxXjw-0003VZ-UL
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: Wed, 27 May 2015 09:35:11 -0000
--001a1144bc4226ea1c05170cf5e5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I think it would be better to have the deadlines set as block counts. That
eliminates the need to use the median time mechanism.
The deadline could be matched to a "start-line". The definition would then
be something like
BIP 105
Start block: 325000
End block: 350000
Activation: 750 of 1000
Implication: 950 of 1000
Bit: 9
This would allow creation of a simple table of known BIPs. It also keeps
multiple users of the bit as strictly separate.
The alternative to the start time is that it is set equal to the deadline
or implication time of the previous user of the bit.
Was the intention to change the 95% rule. You need 750 of the last 1000 to
activate and then must wait at least 1000 for implication?
On Wed, May 27, 2015 at 4:51 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> It would also help to see the actual code changes required, which I'm sur=
e
> will be much shorter than the explanation itself.
> On May 27, 2015 5:47 AM, "Luke Dashjr" <luke@dashjr.org> wrote:
>
>> On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:
>> > Feel free to comment. As the gist does not support notifying
>> participants
>> > of new comments, I would suggest using the mailing list instead.
>>
>> I suggest adding a section describing how this interacts with and change=
s
>> GBT.
>>
>> Currently, the client tells the server what the highest block version it
>> supports is, and the server indicates a block version to use in its
>> template,
>> as well as optional instructions for the client to forcefully use this
>> version
>> despite its own maximum version number. Making the version a bitfield
>> contradicts the increment-only assumption of this design, and since GBT
>> clients are not aware of overall network consensus state, reused bits ca=
n
>> easily become confused. I suggest, therefore, that GBT clients should
>> indicate
>> (instead of a maximum supported version number) a list of softforks by
>> identifier keyword, and the GBT server respond with a template indicatin=
g:
>> - An object of softfork keywords to bit values, that the server will
>> accept.
>> - The version number, as presently conveyed, indicating the preferred
>> softfork
>> flags.
>>
>> Does this sound reasonable, and/or am I missing anything else?
>>
>> Luke
>>
>>
>> ------------------------------------------------------------------------=
------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> -------------------------------------------------------------------------=
-----
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a1144bc4226ea1c05170cf5e5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div><div>I think it would be bet=
ter to have the deadlines set as block counts.=C2=A0 That eliminates the ne=
ed to use the median time mechanism.<br></div><div><br></div>The deadline c=
ould be matched to a "start-line".=C2=A0 The definition would the=
n be something like<br><br></div>BIP 105<br></div>Start block: 325000<br></=
div>End block: 350000<br></div>Activation: 750 of 1000<br>Implication: 950 =
of 1000<br>Bit: 9<br><br></div>This would allow creation of a simple table =
of known BIPs.=C2=A0 It also keeps multiple users of the bit as strictly se=
parate.<br><br></div>The alternative to the start time is that it is set eq=
ual to the deadline or implication time of the previous user of the bit.<br=
><div><div><div><br></div><div>Was the intention to change the 95% rule.=C2=
=A0 You need 750 of the last 1000 to activate and then must wait at least 1=
000 for implication?<br></div><div><br></div></div></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, May 27, 2015 at 4:5=
1 AM, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a href=3D"mailto:jtimon@jtimo=
n.cc" target=3D"_blank">jtimon@jtimon.cc</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><p dir=3D"ltr">It would also help to see the actual c=
ode changes required, which I'm sure will be much shorter than the expl=
anation itself.</p><div class=3D"HOEnZb"><div class=3D"h5">
<div class=3D"gmail_quote">On May 27, 2015 5:47 AM, "Luke Dashjr"=
<<a href=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</=
a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed=
nesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:<br>
> Feel free to comment. As the gist does not support notifying participa=
nts<br>
> of new comments, I would suggest using the mailing list instead.<br>
<br>
I suggest adding a section describing how this interacts with and changes G=
BT.<br>
<br>
Currently, the client tells the server what the highest block version it<br=
>
supports is, and the server indicates a block version to use in its templat=
e,<br>
as well as optional instructions for the client to forcefully use this vers=
ion<br>
despite its own maximum version number. Making the version a bitfield<br>
contradicts the increment-only assumption of this design, and since GBT<br>
clients are not aware of overall network consensus state, reused bits can<b=
r>
easily become confused. I suggest, therefore, that GBT clients should indic=
ate<br>
(instead of a maximum supported version number) a list of softforks by<br>
identifier keyword, and the GBT server respond with a template indicating:<=
br>
- An object of softfork keywords to bit values, that the server will accept=
.<br>
- The version number, as presently conveyed, indicating the preferred softf=
ork<br>
flags.<br>
<br>
Does this sound reasonable, and/or am I missing anything else?<br>
<br>
Luke<br>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
--001a1144bc4226ea1c05170cf5e5--
|
