rich1.0npub1gg0pysd236d4em7pts906ev9kf6f30j8werd40j2vwpes7fqdn4qtt7uvkhttps://nostr.ae/npub1gg0pysd236d4em7pts906ev9kf6f30j8werd40j2vwpes7fqdn4qtt7uvknjumphttps://nostr.ae📅 Original date posted:2015-06-25 📝 Original message: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 at gmail.com> 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 <pindar.wong at 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 at 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 at 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 at bitcoins.info> >>>> milly at 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 at lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>>> >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/51c533b1/attachment-0001.html>