summaryrefslogtreecommitdiff
path: root/96/ad9806b1684597f2e4b47c26d7d32dc1b60434
blob: b1ad629ec504db131e649fb3041dd67710a40966 (plain)
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
415
416
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 087F983D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 25 Jun 2015 02:34:53 +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 861D9180
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 25 Jun 2015 02:34:51 +0000 (UTC)
Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA
	; Wed, 24 Jun 2015 22:34:49 -0400
To: bitcoin-dev@lists.linuxfoundation.org
References: <COL402-EAS109000AAC490BCF2DD69116CDAF0@phx.gbl>
	<558B4632.8080504@bitcoins.info>
	<CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com>
From: Milly Bitcoin <milly@bitcoins.info>
Message-ID: <558B68C3.9050608@bitcoins.info>
Date: Wed, 24 Jun 2015 22:34:43 -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: <CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------060105070409060504020206"
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 02:34:53 -0000

This is a multi-part message in MIME format.
--------------060105070409060504020206
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

I'm sorry but that is the kind of defensive, cultish response everyone 
gets when they ask that question.  If you had a well constructed 
documented process then you would be able to point to it ... but you 
can't.  While there are a few bits and pieces scattered  about in 
different places there is no coherent plan or process.

It is easy to make statements like "consensus must be unanimous" but the 
issue is that you never have true 100% consensus yet you have to move 
forward in some fashion and everyone has to run software with the same 
consensus rules.  The issue is how you move forward is the question that 
nobody wants to answer because (a) it is a hard question to answer and 
(b) developers see it as a threat to their authority/position.  If 
people just keep shutting down the discussion with a bunch of cultish 
stock answers then you are never going to move forward with developing 
some kind of process.

 From what I can see much of the discussion is personality-driven and 
not based on Computer Science or and defined process.  The issue is that 
a personality has changed so the process is perceived to be different 
and some people want to hard fork. Previously, the cultish answer is 
that Bitcoin development is decentralized because people can fork the 
code.  Now that some developers want to fork the code suddenly it is a 
big problem. Is forking the code part of the consensus process or is it 
the work of the devil?   The fact that there is so much diverse opinion 
on this shows a defined process has never been fully vetted or understood.

I have worked on these processes for many years for projects orders of 
magnitudes larger than Bitcoin.  I can absolutely assure you the current 
mishmash does not scale and huge amounts of time are wasted.  That 
should be readily apparent from the recent discussions and the recent 
concern it has caused from people outside the developer's inner circle.

Lack of defined process = high risk and wasted effort.

Russ




On 6/24/2015 9:50 PM, Mark Friedenbach 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
>
>


--------------060105070409060504020206
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">I'm sorry but that is the kind of
      defensive, cultish response everyone gets when they ask that
      question.  If you had a well constructed documented process then
      you would be able to point to it ... but you can't.  While there
      are a few bits and pieces scattered  about in different places
      there is no coherent plan or process.<br>
      <br>
      It is easy to make statements like "consensus must be unanimous"
      but the issue is that you never have true 100% consensus yet you
      have to move forward in some fashion and everyone has to run
      software with the same consensus rules.  The issue is how you move
      forward is the question that nobody wants to answer because (a) it
      is a hard question to answer and (b) developers see it as a threat
      to their authority/position.  If people just keep shutting down
      the discussion with a bunch of cultish stock answers then you are
      never going to move forward with developing some kind of process. 
      <br>
      <br>
      From what I can see much of the discussion is personality-driven
      and not based on Computer Science or and defined process.  The
      issue is that a personality has changed so the process is
      perceived to be different and some people want to hard fork. 
      Previously, the cultish answer is that Bitcoin development is
      decentralized because people can fork the code.  Now that some
      developers want to fork the code suddenly it is a big problem.  
      Is forking the code part of the consensus process or is it the
      work of the devil?   The fact that there is so much diverse
      opinion on this shows a defined process has never been fully
      vetted or understood.<br>
      <br>
      I have worked on these processes for many years for projects
      orders of magnitudes larger than Bitcoin.  I can absolutely assure
      you the current mishmash does not scale and huge amounts of time
      are wasted.  That should be readily apparent from the recent
      discussions and the recent concern it has caused from people
      outside the developer's inner circle.  <br>
      <br>
      Lack of defined process = high risk and wasted effort.<br>
      <br>
      Russ<br>
      <br>
      <br>
      <br>
      <br>
      On 6/24/2015 9:50 PM, Mark Friedenbach wrote:<br>
    </div>
    <blockquote
cite="mid:CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com"
      type="cite">
      <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 class="gmail_extra"><br>
                  <div class="gmail_quote">On Wed, Jun 24, 2015 at 5:07
                    PM, Milly Bitcoin <span dir="ltr">&lt;<a
                        moz-do-not-send="true"
                        href="mailto:milly@bitcoins.info"
                        target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:milly@bitcoins.info">milly@bitcoins.info</a></a>&gt;</span>
                    wrote:<br>
                    <blockquote class="gmail_quote" style="margin: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 class="HOEnZb">
                        <div class="h5"><br>
                          <br>
                          <br>
                          <br>
                          <br>
                          <br>
                          On 6/24/2015 7:41 PM, Raystonn wrote:<br>
                          <blockquote class="gmail_quote"
                            style="margin: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"
                              target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
                            <a moz-do-not-send="true"
                              href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
                              rel="noreferrer" target="_blank">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"
                            target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
                          <a moz-do-not-send="true"
                            href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
                            rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
                        </div>
                      </div>
                    </blockquote>
                  </div>
                  <br>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------060105070409060504020206--