From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C95C0ABF for ; 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 ; Thu, 25 Jun 2015 02:30:55 +0000 (UTC) Received: by wiwl6 with SMTP id l6so4766493wiw.0 for ; 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: References: <558B4632.8080504@bitcoins.info> Date: Wed, 24 Jun 2015 22:30:53 -0400 Message-ID: From: Alex Morcos To: Mark Friedenbach 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > 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
+1 Mark!

On Wed, Jun 24, 2015 at 9:50 PM, Mark Friedenb= ach <mark@friedenbach.org> wrote:
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.

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.

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.

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.

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.

<= /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>
On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoi= n <milly@bitcoins.info> wrote:
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).

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.

Until you get passed all the personality-based arguments you are going to h= ave 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 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?

Raystonn
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev



_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--047d7bb70950a2473505194e6963--