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
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
|
Return-Path: <milly@bitcoins.info>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 18810AAE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 03:19:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.help.org (mail.help.org [70.90.2.18])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A780E1D1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 03:19:53 +0000 (UTC)
Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA
; Wed, 24 Jun 2015 23:19:51 -0400
References: <COL402-EAS127289185B11D0D58E1F5E6CDAE0@phx.gbl>
To: bitcoin-dev@lists.linuxfoundation.org
From: Milly Bitcoin <milly@bitcoins.info>
Message-ID: <558B7352.90708@bitcoins.info>
Date: Wed, 24 Jun 2015 23:19:46 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <COL402-EAS127289185B11D0D58E1F5E6CDAE0@phx.gbl>
Content-Type: multipart/alternative;
boundary="------------090602040403030906090309"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
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, 25 Jun 2015 03:19:55 -0000
This is a multi-part message in MIME format.
--------------090602040403030906090309
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
The more specific answer (from a user's perspective) is that there is
unanimous approval within the constraints of the Bitcoin system. The
constraint is that your software must be compatible with merchants and
exchanges for your coins to have value. Stating "unanimous approval"
without identifying the constraint is misstating the issue.
As for developers, the consensus on code changes are almost never 100%
and someone has to make the decision about what is an a acceptable
consensus. Most of the cultish answers completely overlook this issue
even though it is main point of the question.
Russ
On 6/24/2015 11:00 PM, Raystonn wrote:
>
> > Consensus-code changes are unanimous. They must be.
>
> Excellent. Now we are getting to some actual written rules. How about
> updating the BIP process documentation with this? Everyone should be
> able to read the rules of the coin they are buying.
>
> One moment though. Can you tell me how this particular rule came to
> be? The creator of Bitcoin violated this rule many times. So it must
> have been adopted after his departure. What process was followed to
> adopt this new rule? Was there consensus for it at the time? A huge
> portion of the user community is under the impression that Satoshi's
> written plans, some of which violate this new rule, will be
> implemented. So there certainly would not be consensus for this rule
> today.
>
> On 24 Jun 2015 6:51 pm, Mark Friedenbach <mark@friedenbach.org> wrote:
>
> I'm sorry but this is absolutely not the case, Milly. The reason
> that people get defensive is that we have a carefully constructed
> process that does work (thank you very much!) and is well
> documented. We talk about it quite often in fact as it is a
> defining characteristic of how bitcoin is developed which differs
> in some ways from how other open source software is developed --
> although it remains the same in most other ways.
>
> Changes to the non-consensus sections of Bitcoin Core tend to get
> merged when there are a few reviews, tests, and ACKs from
> recognized developers, there are no outstanding objections, and
> the maintainer doing the merge makes a subjective judgement that
> the code is ready.
>
> Consensus-changes, on the other hand, get merged into Bitcoin Core
> only after the above criteria are met AND an extremely long
> discussion period that has given all the relevant stakeholders a
> chance to comment, and no significant objections remain.
> Consensus-code changes are unanimous. They must be.
>
> The sort of process that exists in standards bodies for example,
> with working groups and formal voting procedures, has no place
> where changes define the nature and validity of other people's
> money. Who has the right to reach into your pocket and define how
> you can or cannot spend your coins? The premise of bitcoin is that
> no one has that right, yet that is very much what we do when
> consensus code changes are made. That is why when we make a change
> to the rules governing the nature of bitcoin, we must make sure
> that everyone is made aware of the change and consents to it.
>
> Everyone. Does this work? Does this scale? So far, it does.
> Uncontroversial changes, such as BIP 66, are deployed without
> issue. Every indication is that BIP 66 will complete deployment in
> the very near future, and we intend to repeat this process for
> more interesting changes such as BIP65: CHECKLOCKTIMEVERIFY.
>
> This isn't about no one stepping forward to be the "decider." This
> is about no one having the right to decide these things on the
> behalf of others. If a contentious change is proposed and not
> accepted by the process of consensus, that is because the process
> is doing its job at rejecting controversial changes. It has
> nothing to do with personality, and everything to do with the
> nature of bitcoin itself.
>
>
> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin
> <milly@bitcoins.info <mailto:milly@bitcoins.info>> wrote:
>
> I have seen this question asked many times. Most developers
> become defensive and they usually give a very vague 1-sentence
> answer when this question is asked. It seems to be it is
> based on personalities rather than any kind of definable
> process. To have that discussion the personalities must be
> separated out and answers like "such-and-such wouldn't do
> that" don't really do much to advance the discussion. Also,
> the incentive for new developers to come in is that they will
> be paid by companies who want to influence the code and this
> should be considered (some developers take this statement as
> an insult when it is just a statement of the incentive process).
>
> The other problem you are having is the lead developer does
> not want to be a "decider" when, in fact, he is a very
> significant decider. While the users have the ultimate choice
> in a practical sense the chief developer is the "decider."
> Now people don't want to get him upset so nobody wants to push
> the issue or fully define the process. Now you are left with
> a broken, unwritten/unspoken process. While this type of
> thing may work with a small group of developers
> businesses/investors looking in from the outside will see this
> as a risk.
>
> Until you get passed all the personality-based arguments you
> are going to have a tough time defining a real process.
>
> Russ
>
>
>
>
>
>
> On 6/24/2015 7:41 PM, Raystonn wrote:
>
> I would like to start a civil discussion on an undefined,
> or at least unwritten, portion of the BIP process. Who
> should get to vote on approval to commit a BIP
> implementation into Bitcoin Core? Is a simple majority of
> these voters sufficient for approval? If not, then what is?
>
> Raystonn
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--------------090602040403030906090309
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">The more specific answer (from a user's
perspective) is that there is unanimous approval within the
constraints of the Bitcoin system. The constraint is that your
software must be compatible with merchants and exchanges for your
coins to have value. Stating "unanimous approval" without
identifying the constraint is misstating the issue.<br>
<br>
As for developers, the consensus on code changes are almost never
100% and someone has to make the decision about what is an a
acceptable consensus. Most of the cultish answers completely
overlook this issue even though it is main point of the question.
<br>
<br>
Russ<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 6/24/2015 11:00 PM, Raystonn wrote:<br>
</div>
<blockquote
cite="mid:COL402-EAS127289185B11D0D58E1F5E6CDAE0@phx.gbl"
type="cite">
<p dir="ltr">> Consensus-code changes are unanimous. They must
be.</p>
<p dir="ltr">Excellent. Now we are getting to some actual written
rules. How about updating the BIP process documentation with
this? Everyone should be able to read the rules of the coin they
are buying.</p>
<p dir="ltr">One moment though. Can you tell me how this
particular rule came to be? The creator of Bitcoin violated this
rule many times. So it must have been adopted after his
departure. What process was followed to adopt this new rule? Was
there consensus for it at the time? A huge portion of the user
community is under the impression that Satoshi's written plans,
some of which violate this new rule, will be implemented. So
there certainly would not be consensus for this rule today.<br>
</p>
<div class="gmail_quote">On 24 Jun 2015 6:51 pm, Mark Friedenbach
<a class="moz-txt-link-rfc2396E" href="mailto:mark@friedenbach.org"><mark@friedenbach.org></a> wrote:<br type="attribution">
<blockquote class="quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>I'm sorry but this is absolutely not the case,
Milly. The reason that people get defensive is that we
have a carefully constructed process that does work
(thank you very much!) and is well documented. We talk
about it quite often in fact as it is a defining
characteristic of how bitcoin is developed which
differs in some ways from how other open source
software is developed -- although it remains the same
in most other ways.<br>
<br>
</div>
Changes to the non-consensus sections of Bitcoin Core
tend to get merged when there are a few reviews, tests,
and ACKs from recognized developers, there are no
outstanding objections, and the maintainer doing the
merge makes a subjective judgement that the code is
ready.<br>
<br>
</div>
Consensus-changes, on the other hand, get merged into
Bitcoin Core only after the above criteria are met AND an
extremely long discussion period that has given all the
relevant stakeholders a chance to comment, and no
significant objections remain. Consensus-code changes are
unanimous. They must be.<br>
<br>
</div>
<div>The sort of process that exists in standards bodies for
example, with working groups and formal voting procedures,
has no place where changes define the nature and validity
of other people's money. Who has the right to reach into
your pocket and define how you can or cannot spend your
coins? The premise of bitcoin is that no one has that
right, yet that is very much what we do when consensus
code changes are made. That is why when we make a change
to the rules governing the nature of bitcoin, we must make
sure that everyone is made aware of the change and
consents to it.<br>
<br>
</div>
<div>Everyone. Does this work? Does this scale? So far, it
does. Uncontroversial changes, such as BIP 66, are
deployed without issue. Every indication is that BIP 66
will complete deployment in the very near future, and we
intend to repeat this process for more interesting changes
such as BIP65: CHECKLOCKTIMEVERIFY.<br>
</div>
<div><br>
</div>
<div>This isn't about no one stepping forward to be the
"decider." This is about no one having the right to decide
these things on the behalf of others. If a contentious
change is proposed and not accepted by the process of
consensus, that is because the process is doing its job at
rejecting controversial changes. It has nothing to do with
personality, and everything to do with the nature of
bitcoin itself.<br>
</div>
<div><br>
</div>
<div>
<div>
<div>
<div>
<div><br>
<div class="elided-text">On Wed, Jun 24, 2015 at
5:07 PM, Milly Bitcoin <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:milly@bitcoins.info"><a class="moz-txt-link-abbreviated" href="mailto:milly@bitcoins.info">milly@bitcoins.info</a></a>></span>
wrote:<br>
<blockquote style="margin:0 0 0
0.8ex;border-left:1px #ccc
solid;padding-left:1ex">I have seen this
question asked many times. Most developers
become defensive and they usually give a very
vague 1-sentence answer when this question is
asked. It seems to be it is based on
personalities rather than any kind of
definable process. To have that discussion
the personalities must be separated out and
answers like "such-and-such wouldn't do that"
don't really do much to advance the
discussion. Also, the incentive for new
developers to come in is that they will be
paid by companies who want to influence the
code and this should be considered (some
developers take this statement as an insult
when it is just a statement of the incentive
process).<br>
<br>
The other problem you are having is the lead
developer does not want to be a "decider"
when, in fact, he is a very significant
decider. While the users have the ultimate
choice in a practical sense the chief
developer is the "decider." Now people don't
want to get him upset so nobody wants to push
the issue or fully define the process. Now
you are left with a broken, unwritten/unspoken
process. While this type of thing may work
with a small group of developers
businesses/investors looking in from the
outside will see this as a risk.<br>
<br>
Until you get passed all the personality-based
arguments you are going to have a tough time
defining a real process.<br>
<br>
Russ
<div>
<div><br>
<br>
<br>
<br>
<br>
<br>
On 6/24/2015 7:41 PM, Raystonn wrote:<br>
<blockquote style="margin:0 0 0
0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
I would like to start a civil discussion
on an undefined, or at least unwritten,
portion of the BIP process. Who should
get to vote on approval to commit a BIP
implementation into Bitcoin Core? Is a
simple majority of these voters
sufficient for approval? If not, then
what is?<br>
<br>
Raystonn<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
</blockquote>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>
--------------090602040403030906090309--
|
