rich1.0npub1rv5ajnhgrc0wq3ulrk6tcjkgsaq8h4rs5rtsvrnklz4j0lw40egqphc5wthttps://nostr.ae/npub1rv5ajnhgrc0wq3ulrk6tcjkgsaq8h4rs5rtsvrnklz4j0lw40egqphc5wtnjumphttps://nostr.ae📅 Original date posted:2015-06-25 📝 Original message:"Cultish" means making claims without any supporting facts. Labeling Open Source software as being "decentralized" just because people can choose which version to run is a "cultish" claim. Just because Bitcoin uses the mining process to come to consensus over the state of the ledger that does not mean the software versions have the same level of decentralization because users can decide which version to run. I am in the USA and I can vote in elections but I would not call the US government "decentralized." It is a very complicated issue and cannot be explained in one or two sentences of hand-waiving arguments like you often see here. Russ On 6/25/2015 3:51 AM, cipher anthem wrote: > +1 on this! > > I have come across Milly a couple of times on reddit and disqus and > she basically dismisses anyone who doesn't agree with her opinions. > always labeling them "cultish". Please ignore her so you can stay > productive. > *Sent:* Thursday, June 25, 2015 at 5:07 AM > *From:* "Jeff Garzik" <jgarzik at gmail.com> > *To:* bitcoin-dev at lists.linuxfoundation.org > *Subject:* Re: [bitcoin-dev] BIP Process and Votes > 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> 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 > 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/51d968ab/attachment-0001.html>