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
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 12E0AAB2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 06:15:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com
[209.85.213.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 97B80138
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 06:15:39 +0000 (UTC)
Received: by igblr2 with SMTP id lr2so90597022igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jun 2015 23:15:39 -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=5zo3J+nH19SC0/PdPJEdCWJxdpiodisY74imMf1Wvuk=;
b=ePdl/O087CArwrK8m6mcV4zkjsk8gi2fhpD0Wo26jqKbqV9Z5wYJetnZD+3JB9qmo2
jsc1hibFyXPnP0rtIRQsOJOfAl5Db7mcBx+9ikGINbQi9jVr+Nwtdvha2xXLK9znk8q1
ti4prxEh4MscKHtP/WoCAmqyLj29G0mbREUuaotozK2FelG3Qh4zk1n4DK0O8YkkVcOP
7j9OBOcRkMFEApMyrseBH/fJv1Cgvk3d2OWP8LrT4mVBpK+mt5HX5fwgRz0JXiG4JzM4
QTbASVqcnDjw5UGWxrBA/WUbmml3unZzuAGql0YCb5bE+bKXV2PWT7z/zMqjpJgFESQf
afKA==
X-Gm-Message-State: ALoCoQn9+NhMWQZjRC9g/QlT2HpZofsagroeJSQWXu9+GmTyCzoh/2rySYvJ06rLIhIotDNZMnmB
MIME-Version: 1.0
X-Received: by 10.107.37.69 with SMTP id l66mr57894329iol.76.1435212939057;
Wed, 24 Jun 2015 23:15:39 -0700 (PDT)
Received: by 10.107.149.20 with HTTP; Wed, 24 Jun 2015 23:15:38 -0700 (PDT)
X-Originating-IP: [172.56.16.98]
Received: by 10.107.149.20 with HTTP; Wed, 24 Jun 2015 23:15:38 -0700 (PDT)
In-Reply-To: <CAM7BtUqpmELVnQh9JycjxK0dOn4hqsg6Csz7za55BgYyw+FG7g@mail.gmail.com>
References: <COL402-EAS109000AAC490BCF2DD69116CDAF0@phx.gbl>
<558B4632.8080504@bitcoins.info>
<CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com>
<558B68C3.9050608@bitcoins.info>
<CADm_WcZ+5z-7KDsOaNunSWAROoJEsDSEAFZ-d2C6cZBrQTkBcw@mail.gmail.com>
<558B9484.1030803@bitcoins.info>
<CAM7BtUqpmELVnQh9JycjxK0dOn4hqsg6Csz7za55BgYyw+FG7g@mail.gmail.com>
Date: Wed, 24 Jun 2015 23:15:38 -0700
Message-ID: <CAOG=w-vRSkY_tDHQhwbcSC8P5EJZn4Xpj+dKqV9GL26v-p5DQw@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: Pindar Wong <pindar.wong@gmail.com>
Content-Type: multipart/alternative; boundary=001a1140ea0268f7a40519518d98
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@lists.linuxfoundation.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 06:15:42 -0000
--001a1140ea0268f7a40519518d98
Content-Type: text/plain; charset=UTF-8
You don't need to ask permission for testnet. Here is one with 100MB blocks:
https://github.com/pstratem/bitcoin/tree/testnet4
On Jun 24, 2015 11:06 PM, "Pindar Wong" <pindar.wong@gmail.com> wrote:
> In the process of 'mining consensus', perhaps before voting there should
> be robust system testing and telemetry.
>
> May I ask a questions w.r.t. Process BIPs, what is the process for
> establishing a new testnet (e.g. for testing with 8MB blocks)?
>
> p.
>
>
> On Thu, Jun 25, 2015 at 1:41 PM, Milly Bitcoin <milly@bitcoins.info>
> wrote:
>
>> These are the kind of silly responses you often get when this subject
>> comes up. Mr. Garzik knows how to ignore messages he doesn't want so I see
>> no need for him to use the list to attack people he doesn't agree with
>> and/or try to interfere with discussions of others on the list.
>> He turns it into a personality discussion rather than a discussion of
>> Systems Engineering. He also tries to intimate anyone who brings up the
>> discussion and "punish" them as a lesson to anyone else who may raise the
>> issue.
>>
>> It is interesting that people like that are attracted to a decentralized
>> system. The reply is simply an attempt at protecting turf which is why
>> Mr. Garzik's vague replies are never taken seriously on the subject of
>> decision-making process for the software.
>>
>> Russ
>>
>>
>>
>> On 6/25/2015 1:07 AM, Jeff Garzik wrote:
>>
>> Ladies & gents, please do not feed the troll. This has been explained to
>> Milly multiple times in the past, on previous mailing list & github with no
>> impact.
>>
>>
>> On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly@bitcoins.info>
>> wrote:
>>
>>> 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>
>>> 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
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a1140ea0268f7a40519518d98
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">You don't need to ask permission for testnet. Here is on=
e with 100MB blocks:</p>
<p dir=3D"ltr"><a href=3D"https://github.com/pstratem/bitcoin/tree/testnet4=
">https://github.com/pstratem/bitcoin/tree/testnet4</a></p>
<div class=3D"gmail_quote">On Jun 24, 2015 11:06 PM, "Pindar Wong"=
; <<a href=3D"mailto:pindar.wong@gmail.com">pindar.wong@gmail.com</a>>=
; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div>In the process of 'mining consensus', perhaps before vot=
ing there should be robust system testing and telemetry.<br><br>May I ask a=
questions w.r.t. Process BIPs, what is the process for establishing a new =
testnet (e.g. for testing with 8MB blocks)?<br><br></div>p.<br><br></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Jun 25, 201=
5 at 1:41 PM, Milly Bitcoin <span dir=3D"ltr"><<a href=3D"mailto:milly@b=
itcoins.info" target=3D"_blank">milly@bitcoins.info</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>These are the kind of silly responses
you often get when this subject comes up.=C2=A0 Mr. Garzik knows how =
to
ignore messages he doesn't want so I see no need for him to use
the list to attack people he doesn't agree with and/or try to
interfere with discussions of others on the list. <br>
He turns it into a personality discussion rather than a discussion
of Systems Engineering.=C2=A0 He also tries to intimate anyone who
brings up the discussion and "punish" them as a lesson to a=
nyone
else who may raise the issue.=C2=A0=C2=A0 <br>
<br>
It is interesting that people like that are attracted to a
decentralized system.=C2=A0=C2=A0 The reply is simply an attempt at
protecting turf which is why Mr. Garzik's vague replies are never
taken seriously on the subject of decision-making process for the
software. <br>
<br>
Russ<div><div><br>
<br>
<br>
On 6/25/2015 1:07 AM, Jeff Garzik wrote:<br>
</div></div></div><div><div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Ladies & gents, please do not feed the troll.=C2=
=A0
This has been explained to Milly multiple times in the past, on
previous mailing list & github with no impact.
<div><br>
</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Wed, Jun 24, 2015 at 7:34 PM, Milly
Bitcoin <span dir=3D"ltr"><<a href=3D"mailto:milly@bitcoins.in=
fo" target=3D"_blank">milly@bitcoins.info</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>I'm sorry but that is the kind of defensive, cultish
response everyone gets when they ask that question.=C2=A0 I=
f
you had a well constructed documented process then you
would be able to point to it ... but you can't.=C2=A0 W=
hile
there are a few bits and pieces scattered=C2=A0 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.=C2=A0 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.=C2=A0 If people ju=
st
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.=C2=A0 <br>
<br>
From what I can see much of the discussion is
personality-driven and not based on Computer Science or
and defined process.=C2=A0 The issue is that a personality
has changed so the process is perceived to be different
and some people want to hard fork.=C2=A0 Previously, the
cultish answer is that Bitcoin development is
decentralized because people can fork the code.=C2=A0 Now
that some developers want to fork the code suddenly it
is a big problem.=C2=A0=C2=A0 Is forking the code part of t=
he
consensus process or is it the work of the devil?=C2=A0=C2=
=A0 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.=C2=A0 I
can absolutely assure you the current mishmash does not
scale and huge amounts of time are wasted.=C2=A0 That shoul=
d
be readily apparent from the recent discussions and the
recent concern it has caused from people outside the
developer's inner circle.=C2=A0 <br>
<br>
Lack of defined process =3D high risk and wasted effort.<br=
>
<br>
Russ
<div>
<div><br>
<br>
<br>
<br>
<br>
On 6/24/2015 9:50 PM, Mark Friedenbach wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type=3D"cite">
<div dir=3D"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 ha=
ving
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=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Wed, Jun 24,
2015 at 5:07 PM, Milly Bitcoin <span dir=
=3D"ltr"><<a href=3D"mailto:milly@bitcoins.info" target=3D"_blank"></a><=
a href=3D"mailto:milly@bitcoins.info" target=3D"_blank">milly@bitcoins.info=
</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have s=
een
this question asked many times.=C2=A0
Most developers become defensive and
they usually give a very vague
1-sentence answer when this question
is asked.=C2=A0 It seems to be it is
based on personalities rather than
any kind of definable process.=C2=A0 To
have that discussion the
personalities must be separated out
and answers like "such-and-such
wouldn't do that" don't re=
ally do
much to advance the discussion.=C2=A0
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.=C2=A0 While
the users have the ultimate choice
in a practical sense the chief
developer is the "decider."=
=C2=A0 Now
people don't want to get him upset
so nobody wants to push the issue or
fully define the process.=C2=A0 Now you
are left with a broken,
unwritten/unspoken process.=C2=A0 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 class=3D"gmail_quote" s=
tyle=3D"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.=C2=A0 Who should
get to vote on approval to
commit a BIP implementation
into Bitcoin Core?=C2=A0 Is a
simple majority of these
voters sufficient for
approval?=C2=A0 If not, then what
is?<br>
<br>
Raystonn<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a><br>
<a href=3D"https://lists.linuxfou=
ndation.org/mailman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_bla=
nk">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
</blockquote>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.o=
rg</a><br>
<a href=3D"https://lists.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank=
">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/b=
itcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundat=
ion.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
bitcoin-dev mailing list
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
<br></blockquote></div><br></div>
<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>
<br></blockquote></div>
--001a1140ea0268f7a40519518d98--
|
