Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1C8DF273 for ; Thu, 25 Jun 2015 06:27:41 +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 109C6118 for ; Thu, 25 Jun 2015 06:27:39 +0000 (UTC) Received: by wiga1 with SMTP id a1so154502710wig.0 for ; Wed, 24 Jun 2015 23:27:37 -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=DWZC4+rNrJdZIuQOfQzkdQFDVTWxUMo9JFEJp3KvR2g=; b=tY9yL9FLIfU4xxAHCw7tt/c3Fu2YNne1Z/2GZwldcF1VqpSqaY/4/Tsj4IjLguorfN PHr5ItKkFpYcYewMB+htkd+5/DNmpCJ+PS9dVspWYr3PITWU2WqC15hI/58XiDBVQUK6 MvnKB5+HniSka5gQm3Gt0sSALSQLOfWKrkIJWkMDg3cwQd0bjFgBO+/ybtiKMIe76VAm jaItpmKyOaVEKQo/AHliInLpCluvuyqPqxYGm/EVPelDpZ35KiPuO75zCVwzQ5imU1A9 PW9Cj/g8WXonOQsQT+kXidEG1JRj3/JBc0R4Rm5nC+Dwil4ykxLT4WCeaPkTQYsEC3GV 29iA== MIME-Version: 1.0 X-Received: by 10.180.89.234 with SMTP id br10mr2667177wib.86.1435213657549; Wed, 24 Jun 2015 23:27:37 -0700 (PDT) Received: by 10.194.2.237 with HTTP; Wed, 24 Jun 2015 23:27:37 -0700 (PDT) In-Reply-To: References: <558B4632.8080504@bitcoins.info> <558B68C3.9050608@bitcoins.info> <558B9484.1030803@bitcoins.info> Date: Thu, 25 Jun 2015 14:27:37 +0800 Message-ID: From: Pindar Wong To: "Warren Togami Jr." Content-Type: multipart/alternative; boundary=e89a8f3ba2d53c3131051951b874 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 06:27:41 -0000 --e89a8f3ba2d53c3131051951b874 Content-Type: text/plain; charset=UTF-8 Thank you very much Mark and Warren this is most helpful. Regards, p. On Thu, Jun 25, 2015 at 2:16 PM, Warren Togami Jr. wrote: > 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 > 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 >> 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 >>> 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> 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 >> >> > --e89a8f3ba2d53c3131051951b874 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you very much Mark and Warren this is most= helpful.

Regards,

p.


On Thu, Jun 25, 2015 at 2:16 PM= , Warren Togami Jr. <wtogami@gmail.com> wrote:
https://github.com/pstratem/b= itcoin/commits/testnet4

See these two commits fo= r an example of changing all the testnet chain parameters to create an enti= rely separate testnet network.=C2=A0 This example "testnet4" chan= ged to different port numbers,=C2=A0pchMessageStart magic, and with stupid = large block sizes.

http://rusty.ozlabs.org/?p=3D509
Rusty used this to test block propagation latency.

On Wed, Jun 24, 2015 at 11:06 PM, Pindar Wong <pin= dar.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 establis= hing 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:
=20 =20 =20
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.
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

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.

Russ



On 6/25/2015 1:07 AM, Jeff Garzik wrote:
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.


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.=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.

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

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.

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

Lack of defined process =3D 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 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.


On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin <<= a href=3D"mailto:milly@bitcoins.info" target=3D"_blank">milly@bitcoins.info= > wrote:
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).

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.
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.=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?

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.o= rg
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundat= ion.org/mailman/listinfo/bitcoin-dev




_______________________________________________
bitcoin-dev mailing list
=
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-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



--e89a8f3ba2d53c3131051951b874--