{"type":"rich","version":"1.0","author_name":"npub1rv5ajnhgrc0wq3ulrk6tcjkgsaq8h4rs5rtsvrnklz4j0lw40egqphc5wt","author_url":"https://nostr.ae/npub1rv5ajnhgrc0wq3ulrk6tcjkgsaq8h4rs5rtsvrnklz4j0lw40egqphc5wt","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-24\n📝 Original message:I'm sorry but that is the kind of defensive, cultish response everyone \ngets when they ask that question.  If you had a well constructed \ndocumented process then you would be able to point to it ... but you \ncan't.  While there are a few bits and pieces scattered  about in \ndifferent places there is no coherent plan or process.\n\nIt is easy to make statements like \"consensus must be unanimous\" but the \nissue is that you never have true 100% consensus yet you have to move \nforward in some fashion and everyone has to run software with the same \nconsensus rules.  The issue is how you move forward is the question that \nnobody wants to answer because (a) it is a hard question to answer and \n(b) developers see it as a threat to their authority/position.  If \npeople just keep shutting down the discussion with a bunch of cultish \nstock answers then you are never going to move forward with developing \nsome kind of process.\n\n From what I can see much of the discussion is personality-driven and \nnot based on Computer Science or and defined process.  The issue is that \na personality has changed so the process is perceived to be different \nand some people want to hard fork. Previously, the cultish answer is \nthat Bitcoin development is decentralized because people can fork the \ncode.  Now that some developers want to fork the code suddenly it is a \nbig problem. Is forking the code part of the consensus process or is it \nthe work of the devil?   The fact that there is so much diverse opinion \non this shows a defined process has never been fully vetted or understood.\n\nI have worked on these processes for many years for projects orders of \nmagnitudes larger than Bitcoin.  I can absolutely assure you the current \nmishmash does not scale and huge amounts of time are wasted.  That \nshould be readily apparent from the recent discussions and the recent \nconcern it has caused from people outside the developer's inner circle.\n\nLack of defined process = high risk and wasted effort.\n\nRuss\n\n\n\n\nOn 6/24/2015 9:50 PM, Mark Friedenbach wrote:\n\u003e I'm sorry but this is absolutely not the case, Milly. The reason that \n\u003e people get defensive is that we have a carefully constructed process \n\u003e that does work (thank you very much!) and is well documented. We talk \n\u003e about it quite often in fact as it is a defining characteristic of how \n\u003e bitcoin is developed which differs in some ways from how other open \n\u003e source software is developed -- although it remains the same in most \n\u003e other ways.\n\u003e\n\u003e Changes to the non-consensus sections of Bitcoin Core tend to get \n\u003e merged when there are a few reviews, tests, and ACKs from recognized \n\u003e developers, there are no outstanding objections, and the maintainer \n\u003e doing the merge makes a subjective judgement that the code is ready.\n\u003e\n\u003e Consensus-changes, on the other hand, get merged into Bitcoin Core \n\u003e only after the above criteria are met AND an extremely long discussion \n\u003e period that has given all the relevant stakeholders a chance to \n\u003e comment, and no significant objections remain. Consensus-code changes \n\u003e are unanimous. They must be.\n\u003e\n\u003e The sort of process that exists in standards bodies for example, with \n\u003e working groups and formal voting procedures, has no place where \n\u003e changes define the nature and validity of other people's money. Who \n\u003e has the right to reach into your pocket and define how you can or \n\u003e cannot spend your coins? The premise of bitcoin is that no one has \n\u003e that right, yet that is very much what we do when consensus code \n\u003e changes are made. That is why when we make a change to the rules \n\u003e governing the nature of bitcoin, we must make sure that everyone is \n\u003e made aware of the change and consents to it.\n\u003e\n\u003e Everyone. Does this work? Does this scale? So far, it does. \n\u003e Uncontroversial changes, such as BIP 66, are deployed without issue. \n\u003e Every indication is that BIP 66 will complete deployment in the very \n\u003e near future, and we intend to repeat this process for more interesting \n\u003e changes such as BIP65: CHECKLOCKTIMEVERIFY.\n\u003e\n\u003e This isn't about no one stepping forward to be the \"decider.\" This is \n\u003e about no one having the right to decide these things on the behalf of \n\u003e others. If a contentious change is proposed and not accepted by the \n\u003e process of consensus, that is because the process is doing its job at \n\u003e rejecting controversial changes. It has nothing to do with \n\u003e personality, and everything to do with the nature of bitcoin itself.\n\u003e\n\u003e\n\u003e On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin \u003cmilly at bitcoins.info \n\u003e \u003cmailto:milly at bitcoins.info\u003e\u003e wrote:\n\u003e\n\u003e     I have seen this question asked many times.  Most developers\n\u003e     become defensive and they usually give a very vague 1-sentence\n\u003e     answer when this question is asked.  It seems to be it is based on\n\u003e     personalities rather than any kind of definable process.  To have\n\u003e     that discussion the personalities must be separated out and\n\u003e     answers like \"such-and-such wouldn't do that\" don't really do much\n\u003e     to advance the discussion.  Also, the incentive for new developers\n\u003e     to come in is that they will be paid by companies who want to\n\u003e     influence the code and this should be considered (some developers\n\u003e     take this statement as an insult when it is just a statement of\n\u003e     the incentive process).\n\u003e\n\u003e     The other problem you are having is the lead developer does not\n\u003e     want to be a \"decider\" when, in fact, he is a very significant\n\u003e     decider.  While the users have the ultimate choice in a practical\n\u003e     sense the chief developer is the \"decider.\"  Now people don't want\n\u003e     to get him upset so nobody wants to push the issue or fully define\n\u003e     the process. Now you are left with a broken, unwritten/unspoken\n\u003e     process.  While this type of thing may work with a small group of\n\u003e     developers businesses/investors looking in from the outside will\n\u003e     see this as a risk.\n\u003e\n\u003e     Until you get passed all the personality-based arguments you are\n\u003e     going to have a tough time defining a real process.\n\u003e\n\u003e     Russ\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e     On 6/24/2015 7:41 PM, Raystonn wrote:\n\u003e\n\u003e         I would like to start a civil discussion on an undefined, or\n\u003e         at least unwritten, portion of the BIP process.  Who should\n\u003e         get to vote on approval to commit a BIP implementation into\n\u003e         Bitcoin Core?  Is a simple majority of these voters sufficient\n\u003e         for approval?  If not, then what is?\n\u003e\n\u003e         Raystonn\n\u003e         _______________________________________________\n\u003e         bitcoin-dev mailing list\n\u003e         bitcoin-dev at lists.linuxfoundation.org\n\u003e         \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e\n\u003e     _______________________________________________\n\u003e     bitcoin-dev mailing list\n\u003e     bitcoin-dev at lists.linuxfoundation.org\n\u003e     \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/a0c7ba21/attachment-0001.html\u003e"}