{"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-25\n📝 Original message:\"Cultish\" means making claims without any supporting facts.  Labeling \nOpen Source software as being \"decentralized\" just because people can \nchoose which version to run is a \"cultish\" claim.  Just because Bitcoin \nuses the mining process to come to consensus over the state of the \nledger that does not mean the software versions have the same level of \ndecentralization because users can decide which version to run. I am in \nthe USA and I can vote in elections but I would not call the US \ngovernment \"decentralized.\"  It is a very complicated issue and cannot \nbe explained in one or two sentences of hand-waiving arguments like you \noften see here.\n\nRuss\n\n\n\n\nOn 6/25/2015 3:51 AM, cipher anthem wrote:\n\u003e +1 on this!\n\u003e\n\u003e I have come across Milly a couple of times on reddit and disqus and \n\u003e she basically dismisses anyone who doesn't agree with her opinions. \n\u003e always labeling them \"cultish\". Please ignore her so you can stay \n\u003e productive.\n\u003e *Sent:* Thursday, June 25, 2015 at 5:07 AM\n\u003e *From:* \"Jeff Garzik\" \u003cjgarzik at gmail.com\u003e\n\u003e *To:* bitcoin-dev at lists.linuxfoundation.org\n\u003e *Subject:* Re: [bitcoin-dev] BIP Process and Votes\n\u003e Ladies \u0026 gents, please do not feed the troll. This has been explained \n\u003e to Milly multiple times in the past, on previous mailing list \u0026 github \n\u003e with no impact.\n\u003e On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin \u003cmilly at bitcoins.info\u003e \n\u003e wrote:\n\u003e\n\u003e     I'm sorry but that is the kind of defensive, cultish response\n\u003e     everyone gets when they ask that question.  If you had a well\n\u003e     constructed documented process then you would be able to point to\n\u003e     it ... but you can't. While there are a few bits and pieces\n\u003e     scattered  about in different places there is no coherent plan or\n\u003e     process.\n\u003e\n\u003e     It is easy to make statements like \"consensus must be unanimous\"\n\u003e     but the issue is that you never have true 100% consensus yet you\n\u003e     have to move forward in some fashion and everyone has to run\n\u003e     software with the same consensus rules.  The issue is how you move\n\u003e     forward is the question that nobody wants to answer because (a) it\n\u003e     is a hard question to answer and (b) developers see it as a threat\n\u003e     to their authority/position.  If people just keep shutting down\n\u003e     the discussion with a bunch of cultish stock answers then you are\n\u003e     never going to move forward with developing some kind of process.\n\u003e\n\u003e     \u003eFrom what I can see much of the discussion is personality-driven\n\u003e     and not based on Computer Science or and defined process.  The\n\u003e     issue is that a personality has changed so the process is\n\u003e     perceived to be different and some people want to hard fork. \n\u003e     Previously, the cultish answer is that Bitcoin development is\n\u003e     decentralized because people can fork the code.  Now that some\n\u003e     developers want to fork the code suddenly it is a big problem.  \n\u003e     Is forking the code part of the consensus process or is it the\n\u003e     work of the devil?   The fact that there is so much diverse\n\u003e     opinion on this shows a defined process has never been fully\n\u003e     vetted or understood.\n\u003e\n\u003e     I have worked on these processes for many years for projects\n\u003e     orders of magnitudes larger than Bitcoin.  I can absolutely assure\n\u003e     you the current mishmash does not scale and huge amounts of time\n\u003e     are wasted.  That should be readily apparent from the recent\n\u003e     discussions and the recent concern it has caused from people\n\u003e     outside the developer's inner circle.\n\u003e\n\u003e     Lack of defined process = high risk and wasted effort.\n\u003e\n\u003e     Russ\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e     On 6/24/2015 9:50 PM, Mark Friedenbach wrote:\n\u003e\n\u003e         I'm sorry but this is absolutely not the case, Milly. The\n\u003e         reason that people get defensive is that we have a carefully\n\u003e         constructed process that does work (thank you very much!) and\n\u003e         is well documented. We talk about it quite often in fact as it\n\u003e         is a defining characteristic of how bitcoin is developed which\n\u003e         differs in some ways from how other open source software is\n\u003e         developed -- although it remains the same in most other ways.\n\u003e         Changes to the non-consensus sections of Bitcoin Core tend to\n\u003e         get merged when there are a few reviews, tests, and ACKs from\n\u003e         recognized developers, there are no outstanding objections,\n\u003e         and the maintainer doing the merge makes a subjective\n\u003e         judgement that the code is ready.\n\u003e         Consensus-changes, on the other hand, get merged into Bitcoin\n\u003e         Core only after the above criteria are met AND an extremely\n\u003e         long discussion period that has given all the relevant\n\u003e         stakeholders a chance to comment, and no significant\n\u003e         objections remain. Consensus-code changes are unanimous. They\n\u003e         must be.\n\u003e         The sort of process that exists in standards bodies for\n\u003e         example, with working groups and formal voting procedures, has\n\u003e         no place where changes define the nature and validity of other\n\u003e         people's money. Who has the right to reach into your pocket\n\u003e         and define how you can or cannot spend your coins? The premise\n\u003e         of bitcoin is that no one has that right, yet that is very\n\u003e         much what we do when consensus code changes are made. That is\n\u003e         why when we make a change to the rules governing the nature of\n\u003e         bitcoin, we must make sure that everyone is made aware of the\n\u003e         change and consents to it.\n\u003e         Everyone. Does this work? Does this scale? So far, it does.\n\u003e         Uncontroversial changes, such as BIP 66, are deployed without\n\u003e         issue. Every indication is that BIP 66 will complete\n\u003e         deployment in the very near future, and we intend to repeat\n\u003e         this process for more interesting changes such as BIP65:\n\u003e         CHECKLOCKTIMEVERIFY.\n\u003e         This isn't about no one stepping forward to be the \"decider.\"\n\u003e         This is about no one having the right to decide these things\n\u003e         on the behalf of others. If a contentious change is proposed\n\u003e         and not accepted by the process of consensus, that is because\n\u003e         the process is doing its job at rejecting controversial\n\u003e         changes. It has nothing to do with personality, and everything\n\u003e         to do with the nature of bitcoin itself.\n\u003e         On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin\n\u003e         \u003cmilly at bitcoins.info\u003e wrote:\n\u003e\n\u003e             I have seen this question asked many times.  Most\n\u003e             developers become defensive and they usually give a very\n\u003e             vague 1-sentence answer when this question is asked. It\n\u003e             seems to be it is based on personalities rather than any\n\u003e             kind of definable process.  To have that discussion the\n\u003e             personalities must be separated out and answers like\n\u003e             \"such-and-such wouldn't do that\" don't really do much to\n\u003e             advance the discussion.  Also, the incentive for new\n\u003e             developers to come in is that they will be paid by\n\u003e             companies who want to influence the code and this should\n\u003e             be considered (some developers take this statement as an\n\u003e             insult when it is just a statement of the incentive process).\n\u003e\n\u003e             The other problem you are having is the lead developer\n\u003e             does not want to be a \"decider\" when, in fact, he is a\n\u003e             very significant decider. While the users have the\n\u003e             ultimate choice in a practical sense the chief developer\n\u003e             is the \"decider.\"  Now people don't want to get him upset\n\u003e             so nobody wants to push the issue or fully define the\n\u003e             process.  Now you are left with a broken,\n\u003e             unwritten/unspoken process.  While this type of thing may\n\u003e             work with a small group of developers businesses/investors\n\u003e             looking in from the outside will see this as a risk.\n\u003e\n\u003e             Until you get passed all the personality-based arguments\n\u003e             you are 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\n\u003e                 undefined, or at least unwritten, portion of the BIP\n\u003e                 process.  Who should get to vote on approval to commit\n\u003e                 a BIP implementation into Bitcoin Core? Is a simple\n\u003e                 majority of these voters sufficient for approval?  If\n\u003e                 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                 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             https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\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 _______________________________________________ bitcoin-dev mailing \n\u003e list bitcoin-dev at lists.linuxfoundation.org \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/51d968ab/attachment-0001.html\u003e"}