summaryrefslogtreecommitdiff
path: root/16
diff options
context:
space:
mode:
authorWarren Togami Jr. <wtogami@gmail.com>2015-06-24 23:16:52 -0700
committerbitcoindev <bitcoindev@gnusha.org>2015-06-25 06:16:54 +0000
commite1c01e29a13d0b3cb0824e36d1123801944ea8c2 (patch)
tree33301463ed8c117ee3d32e795796f995896fb07e /16
parent8a754d4c8726128ad2b0319d9de4b78595a43dfb (diff)
downloadpi-bitcoindev-e1c01e29a13d0b3cb0824e36d1123801944ea8c2.tar.gz
pi-bitcoindev-e1c01e29a13d0b3cb0824e36d1123801944ea8c2.zip
Re: [bitcoin-dev] BIP Process and Votes
Diffstat (limited to '16')
-rw-r--r--16/16d9734b612c777de429bbb2102a6afd5f53db660
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 &quot;testnet4&quot; 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">&lt;<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 &#39;mining consensus&#39;, 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">&lt;<a href=3D"mailto:milly@bi=
+tcoins.info" target=3D"_blank">milly@bitcoins.info</a>&gt;</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&#39;t want so I see no need for him to use
+ the list to attack people he doesn&#39;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 &quot;punish&quot; 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&#39;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 &amp; gents, please do not feed the troll.=C2=
+=A0
+ This has been explained to Milly multiple times in the past, on
+ previous mailing list &amp; 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">&lt;<a href=3D"mailto:milly@bitcoins.in=
+fo" target=3D"_blank">milly@bitcoins.info</a>&gt;</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&#39;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&#39;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 &quot;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 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&#39;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&#39;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&#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 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&#39;t about no one stepping forward to
+ be the &quot;decider.&quot; 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">&lt;<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>&gt;</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 &quot;such-and-such
+ wouldn&#39;t do that&quot; don&#39;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 &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 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--
+