path: root/da/33e7c44f2bd4511f68a9647df3c5f343f7ea52

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 43A5EB19
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 25 Jun 2015 01:51:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com
	[209.85.213.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1A99C121
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 25 Jun 2015 01:51:19 +0000 (UTC)
Received: by igboe5 with SMTP id oe5so4222498igb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jun 2015 18:51:18 -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:from:date
	:message-id:subject:to:cc:content-type;
	bh=MFFEBrQhlbSdNGG5PcqTRR5uV/O/SK/kMeZirT+5gfw=;
	b=BbgVVavITMpuuF8i0YzuQIa0nQUAxaxCV3Dk3PSZfb3KjhCZgX8cSXhwyQjKuZwKXj
	ev7MnR/FzkgWsx+D5gf1K+WxcKzTzv6bqbB9VPe6NzNDxd43ed7l+wk/UeRrfgnifc22
	Lsia0nxcfAx6TI1ZZiXfuxSa8WNw1y+EEAs8OKmuNDH6DYwWOIlQ4DkYiFicfwHB6SMc
	hyFB7InKYlAxyYaE95mREoK+8wwThtU3I+COjJrL68fhAmpwM1ArGsI+6llRvBWfLkoF
	wVETqVCuJ70AgwqBGv0bmBb4BJjT6YHDuXAwtiHqgj4BmRGH5qltzACiMGUjqXkR7V/R
	4Z6g==
X-Gm-Message-State: ALoCoQnO1BHoVgi0Y+VHsSrNc2GhpwkDAtd0H/2+8z4leiqGB1JVVEVQjbxpukQSh56+TNMnx+Rx
X-Received: by 10.50.142.9 with SMTP id rs9mr861267igb.17.1435197078415; Wed,
	24 Jun 2015 18:51:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.149.20 with HTTP; Wed, 24 Jun 2015 18:50:59 -0700 (PDT)
X-Originating-IP: [172.56.16.98]
In-Reply-To: <558B4632.8080504@bitcoins.info>
References: <COL402-EAS109000AAC490BCF2DD69116CDAF0@phx.gbl>
	<558B4632.8080504@bitcoins.info>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Wed, 24 Jun 2015 18:50:59 -0700
Message-ID: <CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com>
To: Milly Bitcoin <milly@bitcoins.info>
Content-Type: multipart/alternative; boundary=001a11c2ff1c0adaea05194ddc63
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 01:51:20 -0000

--001a11c2ff1c0adaea05194ddc63
Content-Type: text/plain; charset=UTF-8

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
>

--001a11c2ff1c0adaea05194ddc63
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>I&#39;m sorry but this is absolutely not th=
e case, Milly. The reason that people get defensive is that we have a caref=
ully 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 charac=
teristic of how bitcoin is developed which differs in some ways from how ot=
her open source software is developed -- although it remains the same in mo=
st other ways.<br><br></div>Changes to the non-consensus sections of Bitcoi=
n Core tend to get merged when there are a few reviews, tests, and ACKs fro=
m recognized developers, there are no outstanding objections, and the maint=
ainer 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, a=
nd no significant objections remain. Consensus-code changes are unanimous. =
They must be.<br><br></div><div>The sort of process that exists in standard=
s bodies for example, with working groups and formal voting procedures, has=
 no place where changes define the nature and validity of other people&#39;=
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 ma=
de. 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 co=
nsents 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 with=
out 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>T=
his isn&#39;t about no one stepping forward to be the &quot;decider.&quot; =
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 proc=
ess of consensus, that is because the process is doing its job at rejecting=
 controversial changes. It has nothing to do with personality, and everythi=
ng to do with the nature of bitcoin itself.<br></div><div><br></div><div><d=
iv><div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On W=
ed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin <span dir=3D"ltr">&lt;<a href=3D=
"mailto:milly@bitcoins.info" target=3D"_blank">milly@bitcoins.info</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">I have seen this question a=
sked many times.=C2=A0 Most developers become defensive and they usually gi=
ve a very vague 1-sentence answer when this question is asked.=C2=A0 It see=
ms to be it is based on personalities rather than any kind of definable pro=
cess.=C2=A0 To have that discussion the personalities must be separated out=
 and answers like &quot;such-and-such wouldn&#39;t do that&quot; don&#39;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 i=
nfluence 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 &quot;decider&quot; 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 &quot;decider.&quot;=C2=A0 Now people don&#39;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 class=3D"HOEnZb"><div class=3D"h5"><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>

--001a11c2ff1c0adaea05194ddc63--