diff options
author | Warren Togami Jr. <wtogami@gmail.com> | 2015-06-24 23:16:52 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-25 06:16:54 +0000 |
commit | e1c01e29a13d0b3cb0824e36d1123801944ea8c2 (patch) | |
tree | 33301463ed8c117ee3d32e795796f995896fb07e /16 | |
parent | 8a754d4c8726128ad2b0319d9de4b78595a43dfb (diff) | |
download | pi-bitcoindev-e1c01e29a13d0b3cb0824e36d1123801944ea8c2.tar.gz pi-bitcoindev-e1c01e29a13d0b3cb0824e36d1123801944ea8c2.zip |
Re: [bitcoin-dev] BIP Process and Votes
Diffstat (limited to '16')
-rw-r--r-- | 16/16d9734b612c777de429bbb2102a6afd5f53db | 660 |
1 files changed, 660 insertions, 0 deletions
diff --git a/16/16d9734b612c777de429bbb2102a6afd5f53db b/16/16d9734b612c777de429bbb2102a6afd5f53db new file mode 100644 index 000000000..04730a289 --- /dev/null +++ b/16/16d9734b612c777de429bbb2102a6afd5f53db @@ -0,0 +1,660 @@ +Return-Path: <wtogami@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 5B609305 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 25 Jun 2015 06:16:54 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com + [209.85.220.50]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0867F124 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 25 Jun 2015 06:16:52 +0000 (UTC) +Received: by padev16 with SMTP id ev16so43642615pad.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 24 Jun 2015 23:16:52 -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=/WtvvfPrvq7IZnQEDnkLP8asO3o/m5MQPB75/s2uVdg=; + b=k3HuOuAjPaMfjwqb0X7/xddZuQXSs+goh90GO/yzpcvN1ga1xR3pXs8HDsUmbopsK/ + L7dZlNV3ep7u1V0Ea/YKl45+0s49q8MDtcsGVnWmLHNtQjgwb858KEAZRQlK1kP+PNKI + qrUflJHH1atARHjOeHDpST7uu4saBcpwup98qxVKJtFp32WUFWDNlP5frLrSyqQ7tyd3 + VF7iHzzNRwmPJREPCcSf6tIl7SXo5R437Ccc9hB5P+uj4AdelGrG5u5FcmurbFp8EMJg + DUsXwd6Sy9Of2on4UzpHh/WpzpHnpCWBTkspRnU0fH4bAATZVUIawBgZLa113uVn5JVG + 6P4g== +MIME-Version: 1.0 +X-Received: by 10.70.49.229 with SMTP id x5mr86456495pdn.81.1435213012656; + Wed, 24 Jun 2015 23:16:52 -0700 (PDT) +Received: by 10.70.93.72 with HTTP; Wed, 24 Jun 2015 23:16:52 -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:16:52 -0700 +Message-ID: <CAEz79Pqdxc6KUORD9ZBAzctbkLRPfVyQGDeF_dncCVYdJ67jiA@mail.gmail.com> +From: "Warren Togami Jr." <wtogami@gmail.com> +To: Pindar Wong <pindar.wong@gmail.com> +Content-Type: multipart/alternative; boundary=089e0160cfaecbefe20519519190 +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 06:16:54 -0000 + +--089e0160cfaecbefe20519519190 +Content-Type: text/plain; charset=UTF-8 + +https://github.com/pstratem/bitcoin/commits/testnet4 + +See these two commits for an example of changing all the testnet chain +parameters to create an entirely separate testnet network. This example +"testnet4" changed to different port numbers, pchMessageStart magic, and +with stupid large block sizes. + +http://rusty.ozlabs.org/?p=509 +Rusty used this to test block propagation latency. + +On Wed, Jun 24, 2015 at 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 +> +> + +--089e0160cfaecbefe20519519190 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><a href=3D"https://github.com/pstratem/bitcoin/commits/tes= +tnet4">https://github.com/pstratem/bitcoin/commits/testnet4</a><br><div><br= +></div><div>See these two commits for an example of changing all the testne= +t chain parameters to create an entirely separate testnet network.=C2=A0 Th= +is example "testnet4" changed to different port numbers,=C2=A0pch= +MessageStart magic, and with stupid large block sizes.</div><div><br></div>= +<div><a href=3D"http://rusty.ozlabs.org/?p=3D509">http://rusty.ozlabs.org/?= +p=3D509</a><br></div><div>Rusty used this to test block propagation latency= +.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On W= +ed, Jun 24, 2015 at 11:06 PM, Pindar Wong <span dir=3D"ltr"><<a href=3D"= +mailto:pindar.wong@gmail.com" target=3D"_blank">pindar.wong@gmail.com</a>&g= +t;</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>In= + the process of 'mining consensus', perhaps before voting there sho= +uld 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)?<span class=3D"HOEnZb"><font color=3D"#888888= +"><br><br></font></span></div><span class=3D"HOEnZb"><font color=3D"#888888= +">p.<br><br></font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><di= +v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Jun 25, 2015= + at 1:41 PM, Milly Bitcoin <span dir=3D"ltr"><<a href=3D"mailto:milly@bi= +tcoins.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:1= +px #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> +</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> + +--089e0160cfaecbefe20519519190-- + |