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
|
Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C95C0ABF
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 02:30:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com
[209.85.212.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 78AA019C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 02:30:55 +0000 (UTC)
Received: by wiwl6 with SMTP id l6so4766493wiw.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jun 2015 19:30:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=NeHx5aXQXRH7PFCS1FAJosR/2b/zshgdI9aRZaMhohw=;
b=EkoAaoRqDccz5gg+6Q4l2u33swRJYY/PDZUkV09/fSc/U/6AZW8Pk9x9yKsZjHLnv1
AyWx/xuRyclLdNOzvX46qa5wWSyNqzIQIWlPHvPS7DJQOPxS+5nICSY1MJm0i1hmm7fx
hK+eTpTHHZ/KOgTJ71wxGxGbZomgUuli+cpM5VjPqCVrgFPXjKA9aFOj3xjDB6AumV9s
E3Q5VB/JPQPh0JbkAvt4jYO41cZ8njX0f1utfPFd/M7jWNqP5bG6INi3zzEiQ/fWGA+q
HXZT2CqxltrtGE5OJ4sUb9IlhFhCFowlS8vJCEP4eh0LzYZaA9xjl2dOIl9axSErZOOo
dWJQ==
MIME-Version: 1.0
X-Received: by 10.194.192.166 with SMTP id hh6mr73998530wjc.127.1435199453933;
Wed, 24 Jun 2015 19:30:53 -0700 (PDT)
Received: by 10.180.168.34 with HTTP; Wed, 24 Jun 2015 19:30:53 -0700 (PDT)
In-Reply-To: <CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com>
References: <COL402-EAS109000AAC490BCF2DD69116CDAF0@phx.gbl>
<558B4632.8080504@bitcoins.info>
<CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com>
Date: Wed, 24 Jun 2015 22:30:53 -0400
Message-ID: <CAPWm=eWJ+uOWO+x8mAWuQMy4EKZetOJvq6TeCsZ8uypnXEMEBQ@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=047d7bb70950a2473505194e6963
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 02:30:57 -0000
--047d7bb70950a2473505194e6963
Content-Type: text/plain; charset=UTF-8
+1 Mark!
On Wed, Jun 24, 2015 at 9:50 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>
> 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
>
>
--047d7bb70950a2473505194e6963
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">+1 Mark!<div><br></div></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Wed, Jun 24, 2015 at 9:50 PM, Mark Friedenb=
ach <span dir=3D"ltr"><<a href=3D"mailto:mark@friedenbach.org" target=3D=
"_blank">mark@friedenbach.org</a>></span> wrote:<br><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><div><div>I'm sorry but this is absolu=
tely not the case, Milly. The reason that people get defensive is that we h=
ave a carefully constructed process that does work (thank you very much!) a=
nd is well documented. We talk about it quite often in fact as it is a defi=
ning 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 section=
s of Bitcoin Core tend to get merged when there are a few reviews, tests, a=
nd ACKs from recognized developers, there are no outstanding objections, an=
d 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 in=
to 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 proc=
edures, 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 o=
ne has that right, yet that is very much what we do when consensus code cha=
nges 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 ch=
ange and consents to it.<br><br></div><div>Everyone. Does this work? Does t=
his scale? So far, it does. Uncontroversial changes, such as BIP 66, are de=
ployed without issue. Every indication is that BIP 66 will complete deploym=
ent 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 "deci=
der." 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 a=
t rejecting controversial changes. It has nothing to do with personality, a=
nd everything to do with the nature of bitcoin itself.<br></div><div><div c=
lass=3D"h5"><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 Bitcoi=
n <span dir=3D"ltr"><<a href=3D"mailto:milly@bitcoins.info" target=3D"_b=
lank">milly@bitcoins.info</a>></span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">I have seen this question asked many times.=C2=A0 Most developers be=
come defensive and they usually give a very vague 1-sentence answer when th=
is question is asked.=C2=A0 It seems to be it is based on personalities rat=
her than any kind of definable process.=C2=A0 To have that discussion the p=
ersonalities must be separated out and answers like "such-and-such wou=
ldn't do that" don't really 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 cons=
idered (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 g=
et 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 Wh=
ile 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 h=
ave 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" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I would like to start a civil discussion on an undefined, or at least unwri=
tten, 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 majorit=
y 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@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>
<br>
<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>
</div></div></blockquote></div><br></div></div></div></div></div></div></di=
v></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><br></div>
--047d7bb70950a2473505194e6963--
|
