You don't need to ask permission for testnet. Here is one with 100MB blocks:
https://github.com/pstratem/bitcoin/tree/testnet4 On Jun 24, 2015 11:06 PM, "Pindar Wong" <pindar.w...@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 <mi...@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 <mi...@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 < <mi...@bitcoins.info> >>> mi...@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 > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
