Re: [bitcoin-dev] BIP Process and Votes

From: Milly Bitcoin <milly@bitcoins•info>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
Date: Thu, 25 Jun 2015 01:41:24 -0400	[thread overview]
Message-ID: <558B9484.1030803@bitcoins.info> (raw)
In-Reply-To: <CADm_WcZ+5z-7KDsOaNunSWAROoJEsDSEAFZ-d2C6cZBrQTkBcw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 9174 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 18162 bytes --]