diff options
| author | Jeff Garzik <jgarzik@gmail.com> | 2015-06-24 22:07:26 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-25 05:07:30 +0000 |
| commit | 84ccd910fffd69ebdbfba466a654bdd3ff7ea5df (patch) | |
| tree | bdddbdc2c3e4f9141ef048ff9769e1f106c81685 | |
| parent | 73f3fb16adb2c78f42d8b5991b2c2b2ae761f16b (diff) | |
| download | pi-bitcoindev-84ccd910fffd69ebdbfba466a654bdd3ff7ea5df.tar.gz pi-bitcoindev-84ccd910fffd69ebdbfba466a654bdd3ff7ea5df.zip | |
Re: [bitcoin-dev] BIP Process and Votes
| -rw-r--r-- | c6/caef50869ce0cf064f744825a1ac212020cb0d | 458 |
1 files changed, 458 insertions, 0 deletions
diff --git a/c6/caef50869ce0cf064f744825a1ac212020cb0d b/c6/caef50869ce0cf064f744825a1ac212020cb0d new file mode 100644 index 000000000..bfd52f0bc --- /dev/null +++ b/c6/caef50869ce0cf064f744825a1ac212020cb0d @@ -0,0 +1,458 @@ +Return-Path: <jgarzik@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 4628A9F2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 25 Jun 2015 05:07:30 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AA1F1126 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 25 Jun 2015 05:07:28 +0000 (UTC) +Received: by wgbhy7 with SMTP id hy7so52332066wgb.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 24 Jun 2015 22:07:27 -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 + :content-type; bh=uRx6627/JMqXnaJEzHI0fqzzWqg9AjOD1hW67yuS6nY=; + b=yNyPIN2OtNofeK4k5jGSv9xvyW0ET7ZeymC2X/jwUrYiyfFDT/ZdEfSoRlkFbBQbCk + PA3YxlO/OnRxJZqaMrxY8J9shb5KOv5bOy1f/RaBlIqPb4fk2vZCHkUiS6YZamyTrX5V + ys078FdM2hQRyqUeOw2mCmo8TVRSvPSlJR5MRVLh55PrDm+weO8vVsZDhNA5kPnf3Emy + gT/BiS7TUi4JoO468tIoFc1eCbja3nl+/oGzZlMDDG3qFjkJ9DHzhK4DEVZ04C6haaX/ + 6XptzPoahmw5p11ExlCww6sJOXDGlu83mOjmSZiLQJHiw7nWVfRnTPPJdliIA222ND4z + j7qw== +MIME-Version: 1.0 +X-Received: by 10.194.58.7 with SMTP id m7mr73972626wjq.109.1435208846982; + Wed, 24 Jun 2015 22:07:26 -0700 (PDT) +Received: by 10.28.176.2 with HTTP; Wed, 24 Jun 2015 22:07:26 -0700 (PDT) +In-Reply-To: <558B68C3.9050608@bitcoins.info> +References: <COL402-EAS109000AAC490BCF2DD69116CDAF0@phx.gbl> + <558B4632.8080504@bitcoins.info> + <CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com> + <558B68C3.9050608@bitcoins.info> +Date: Wed, 24 Jun 2015 22:07:26 -0700 +Message-ID: <CADm_WcZ+5z-7KDsOaNunSWAROoJEsDSEAFZ-d2C6cZBrQTkBcw@mail.gmail.com> +From: Jeff Garzik <jgarzik@gmail.com> +To: bitcoin-dev@lists.linuxfoundation.org +Content-Type: multipart/alternative; boundary=047d7b86cf3e80c1e005195099ff +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 +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 05:07:30 -0000 + +--047d7b86cf3e80c1e005195099ff +Content-Type: text/plain; charset=UTF-8 + +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 +> +> + +--047d7b86cf3e80c1e005195099ff +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Ladies & gents, please do not feed the troll.=C2=A0 Th= +is has been explained to Milly multiple times in the past, on previous mail= +ing list & github with no impact.<div><br></div></div><div class=3D"gma= +il_extra"><br><div class=3D"gmail_quote">On Wed, Jun 24, 2015 at 7:34 PM, M= +illy Bitcoin <span dir=3D"ltr"><<a href=3D"mailto:milly@bitcoins.info" t= +arget=3D"_blank">milly@bitcoins.info</a>></span> wrote:<br><blockquote c= +lass=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>I'm sorry but that is the kind of + defensive, cultish response everyone gets when they ask that + question.=C2=A0 If you had a well constructed documented process then + you would be able to point to it ... but you can't.=C2=A0 While t= +here + 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&= +quot; + 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 mo= +ve + 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 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.=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 the 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 assu= +re + you the current mishmash does not scale and huge amounts of time + are wasted.=C2=A0 That should 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 class=3D"h5"><br> + <br> + <br> + <br> + <br> + On 6/24/2015 9:50 PM, Mark Friedenbach wrote:<br> + </div></div></div><div><div class=3D"h5"> + <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 having the right to dec= +ide + 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"mail= +to:milly@bitcoins.info" target=3D"_blank"></a><a href=3D"mailto:milly@bitco= +ins.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 seen 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" d= +on'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 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" w= +hen, in + fact, he is a very significant decider.=C2=A0 While t= +he + 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 want= +s + 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" style=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 vot= +e + on approval to commit a BIP implementation + into Bitcoin Core?=C2=A0 Is a simple majority o= +f + 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.linuxfounda= +tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> + <a href=3D"https://lists.linuxfoundation.org/ma= +ilman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://li= +sts.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.linuxfoundati= +on.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> + <a href=3D"https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://list= +s.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">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> + +--047d7b86cf3e80c1e005195099ff-- + |