{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-25\n📝 Original message:You don't need to ask permission for testnet. Here is one with 100MB blocks:\n\nhttps://github.com/pstratem/bitcoin/tree/testnet4\nOn Jun 24, 2015 11:06 PM, \"Pindar Wong\" \u003cpindar.wong at gmail.com\u003e wrote:\n\n\u003e In the process of 'mining consensus', perhaps before voting there should\n\u003e be robust system testing and telemetry.\n\u003e\n\u003e May I ask a questions w.r.t. Process BIPs, what is the process for\n\u003e establishing a new testnet (e.g. for testing with 8MB blocks)?\n\u003e\n\u003e p.\n\u003e\n\u003e\n\u003e On Thu, Jun 25, 2015 at 1:41 PM, Milly Bitcoin \u003cmilly at bitcoins.info\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e  These are the kind of silly responses you often get when this subject\n\u003e\u003e comes up.  Mr. Garzik knows how to ignore messages he doesn't want so I see\n\u003e\u003e no need for him to use the list to attack people he doesn't agree with\n\u003e\u003e and/or try to interfere with discussions of others on the list.\n\u003e\u003e He turns it into a personality discussion rather than a discussion of\n\u003e\u003e Systems Engineering.  He also tries to intimate anyone who brings up the\n\u003e\u003e discussion and \"punish\" them as a lesson to anyone else who may raise the\n\u003e\u003e issue.\n\u003e\u003e\n\u003e\u003e It is interesting that people like that are attracted to a decentralized\n\u003e\u003e system.   The reply is simply an attempt at protecting turf which is why\n\u003e\u003e Mr. Garzik's vague replies are never taken seriously on the subject of\n\u003e\u003e decision-making process for the software.\n\u003e\u003e\n\u003e\u003e Russ\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On 6/25/2015 1:07 AM, Jeff Garzik wrote:\n\u003e\u003e\n\u003e\u003e Ladies \u0026 gents, please do not feed the troll.  This has been explained to\n\u003e\u003e Milly multiple times in the past, on previous mailing list \u0026 github with no\n\u003e\u003e impact.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin \u003cmilly at bitcoins.info\u003e\n\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e  I'm sorry but that is the kind of defensive, cultish response everyone\n\u003e\u003e\u003e gets when they ask that question.  If you had a well constructed documented\n\u003e\u003e\u003e process then you would be able to point to it ... but you can't.  While\n\u003e\u003e\u003e there are a few bits and pieces scattered  about in different places there\n\u003e\u003e\u003e is no coherent plan or process.\n\u003e\u003e\u003e\n\u003e\u003e\u003e It is easy to make statements like \"consensus must be unanimous\" but the\n\u003e\u003e\u003e issue is that you never have true 100% consensus yet you have to move\n\u003e\u003e\u003e forward in some fashion and everyone has to run software with the same\n\u003e\u003e\u003e consensus rules.  The issue is how you move forward is the question that\n\u003e\u003e\u003e nobody wants to answer because (a) it is a hard question to answer and (b)\n\u003e\u003e\u003e developers see it as a threat to their authority/position.  If people just\n\u003e\u003e\u003e keep shutting down the discussion with a bunch of cultish stock answers\n\u003e\u003e\u003e then you are never going to move forward with developing some kind of\n\u003e\u003e\u003e process.\n\u003e\u003e\u003e\n\u003e\u003e\u003e From what I can see much of the discussion is personality-driven and not\n\u003e\u003e\u003e based on Computer Science or and defined process.  The issue is that a\n\u003e\u003e\u003e personality has changed so the process is perceived to be different and\n\u003e\u003e\u003e some people want to hard fork.  Previously, the cultish answer is that\n\u003e\u003e\u003e Bitcoin development is decentralized because people can fork the code.  Now\n\u003e\u003e\u003e that some developers want to fork the code suddenly it is a big problem.\n\u003e\u003e\u003e Is forking the code part of the consensus process or is it the work of the\n\u003e\u003e\u003e devil?   The fact that there is so much diverse opinion on this shows a\n\u003e\u003e\u003e defined process has never been fully vetted or understood.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I have worked on these processes for many years for projects orders of\n\u003e\u003e\u003e magnitudes larger than Bitcoin.  I can absolutely assure you the current\n\u003e\u003e\u003e mishmash does not scale and huge amounts of time are wasted.  That should\n\u003e\u003e\u003e be readily apparent from the recent discussions and the recent concern it\n\u003e\u003e\u003e has caused from people outside the developer's inner circle.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Lack of defined process = high risk and wasted effort.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Russ\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e On 6/24/2015 9:50 PM, Mark Friedenbach wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e   I'm sorry but this is absolutely not the case, Milly. The reason that\n\u003e\u003e\u003e people get defensive is that we have a carefully constructed process that\n\u003e\u003e\u003e does work (thank you very much!) and is well documented. We talk about it\n\u003e\u003e\u003e quite often in fact as it is a defining characteristic of how bitcoin is\n\u003e\u003e\u003e developed which differs in some ways from how other open source software is\n\u003e\u003e\u003e developed -- although it remains the same in most other ways.\n\u003e\u003e\u003e\n\u003e\u003e\u003e  Changes to the non-consensus sections of Bitcoin Core tend to get\n\u003e\u003e\u003e merged when there are a few reviews, tests, and ACKs from recognized\n\u003e\u003e\u003e developers, there are no outstanding objections, and the maintainer doing\n\u003e\u003e\u003e the merge makes a subjective judgement that the code is ready.\n\u003e\u003e\u003e\n\u003e\u003e\u003e  Consensus-changes, on the other hand, get merged into Bitcoin Core only\n\u003e\u003e\u003e after the above criteria are met AND an extremely long discussion period\n\u003e\u003e\u003e that has given all the relevant stakeholders a chance to comment, and no\n\u003e\u003e\u003e significant objections remain. Consensus-code changes are unanimous. They\n\u003e\u003e\u003e must be.\n\u003e\u003e\u003e\n\u003e\u003e\u003e  The sort of process that exists in standards bodies for example, with\n\u003e\u003e\u003e working groups and formal voting procedures, has no place where changes\n\u003e\u003e\u003e define the nature and validity of other people's money. Who has the right\n\u003e\u003e\u003e to reach into your pocket and define how you can or cannot spend your\n\u003e\u003e\u003e coins? The premise of bitcoin is that no one has that right, yet that is\n\u003e\u003e\u003e very much what we do when consensus code changes are made. That is why when\n\u003e\u003e\u003e we make a change to the rules governing the nature of bitcoin, we must make\n\u003e\u003e\u003e sure that everyone is made aware of the change and consents to it.\n\u003e\u003e\u003e\n\u003e\u003e\u003e  Everyone. Does this work? Does this scale? So far, it does.\n\u003e\u003e\u003e Uncontroversial changes, such as BIP 66, are deployed without issue. Every\n\u003e\u003e\u003e indication is that BIP 66 will complete deployment in the very near future,\n\u003e\u003e\u003e and we intend to repeat this process for more interesting changes such as\n\u003e\u003e\u003e BIP65: CHECKLOCKTIMEVERIFY.\n\u003e\u003e\u003e\n\u003e\u003e\u003e  This isn't about no one stepping forward to be the \"decider.\" This is\n\u003e\u003e\u003e about no one having the right to decide these things on the behalf of\n\u003e\u003e\u003e others. If a contentious change is proposed and not accepted by the process\n\u003e\u003e\u003e of consensus, that is because the process is doing its job at rejecting\n\u003e\u003e\u003e controversial changes. It has nothing to do with personality, and\n\u003e\u003e\u003e everything to do with the nature of bitcoin itself.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin \u003c \u003cmilly at bitcoins.info\u003e\n\u003e\u003e\u003e milly at bitcoins.info\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e I have seen this question asked many times.  Most developers become\n\u003e\u003e\u003e\u003e defensive and they usually give a very vague 1-sentence answer when this\n\u003e\u003e\u003e\u003e question is asked.  It seems to be it is based on personalities rather than\n\u003e\u003e\u003e\u003e any kind of definable process.  To have that discussion the personalities\n\u003e\u003e\u003e\u003e must be separated out and answers like \"such-and-such wouldn't do that\"\n\u003e\u003e\u003e\u003e don't really do much to advance the discussion.  Also, the incentive for\n\u003e\u003e\u003e\u003e new developers to come in is that they will be paid by companies who want\n\u003e\u003e\u003e\u003e to influence the code and this should be considered (some developers take\n\u003e\u003e\u003e\u003e this statement as an insult when it is just a statement of the incentive\n\u003e\u003e\u003e\u003e process).\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e The other problem you are having is the lead developer does not want to\n\u003e\u003e\u003e\u003e be a \"decider\" when, in fact, he is a very significant decider.  While the\n\u003e\u003e\u003e\u003e users have the ultimate choice in a practical sense the chief developer is\n\u003e\u003e\u003e\u003e the \"decider.\"  Now people don't want to get him upset so nobody wants to\n\u003e\u003e\u003e\u003e push the issue or fully define the process.  Now you are left with a\n\u003e\u003e\u003e\u003e broken, unwritten/unspoken process.  While this type of thing may work with\n\u003e\u003e\u003e\u003e a small group of developers businesses/investors looking in from the\n\u003e\u003e\u003e\u003e outside will see this as a risk.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Until you get passed all the personality-based arguments you are going\n\u003e\u003e\u003e\u003e to have a tough time defining a real process.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Russ\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e On 6/24/2015 7:41 PM, Raystonn wrote:\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e I would like to start a civil discussion on an undefined, or at least\n\u003e\u003e\u003e\u003e\u003e unwritten, portion of the BIP process.  Who should get to vote on approval\n\u003e\u003e\u003e\u003e\u003e to commit a BIP implementation into Bitcoin Core?  Is a simple majority of\n\u003e\u003e\u003e\u003e\u003e these voters sufficient for approval?  If not, then what is?\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e Raystonn\n\u003e\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/1e70f0ed/attachment-0001.html\u003e"}