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