{"type":"rich","version":"1.0","author_name":"npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","author_url":"https://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-18\n📝 Original message:On Thu, Jun 18, 2015 at 1:14 PM, Wladimir J. van der Laan \u003claanwj at gmail.com\u003e\nwrote:\n\n\u003e Like in any open source project there is lots of decision making ability\n\u003e for code changes. I'd say look at the changelog for e.g. 0.11\n\u003e https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log,\n\u003e or follow pull requests for a while, to see how many decisions about\n\u003e changes are made from day to day. No, I'm not sitting on my hands, and so\n\u003e is none of the other contributors that you'd like to get rid of.\n\u003e\n\nThe analogy goes further even. Even though I disagree with some of the\nchanges you're making, I respect Mike's (and anyone's) right to make a fork\nof Bitcoin Core. That's how open source works: if people disagree with\nchanges made or not made, they can maintain their own version. However:\n\n\n\u003e Consensus changes are *much* more difficult, on the other hand. Even\n\u003e relatively straightforward softforks come with a long discussion process\n\u003e (see BIP62, BIP66). A hardfork is hard to do at the best of times (everyone\n\u003e needs to upgrade their software!), and simply not possible if almost the\n\u003e entire technical community disagrees with you.\n\u003e\n\nConsensus changes - in particular hardforks - are not about making a change\nto the software. You are effectively asking users of the system to migrate\nto a new system. Perhaps one which is a philosophical successor to the old\none, but a different system, with new rules that are incompatible with the\nold one.\n\nI believe this is something that can only be done if there is no\ncontroversy about the change, for different reasons:\n\n* Risk: no matter how you determine the switchover date, there is no way of\nknowing when (and whether at all) everyone changes their full nodes (and\nperhaps other software), and even very high hash power votes cannot prevent\nan actual fork from appearing afterwards. At best, people lose the\nguarantee that their confirmations are meaningful (because at some point it\nbecomes clear that the other side will get adopted, and they need to\nswitch). At worst, a fork persists, and two partitions appear, in each of\nwhich you can spend every pre-existing coin. This defeats the primary\npurpose Bitcoin was designed for: double spend protection.\n\n* Philosophy: Bitcoin is not a democracy. The full node security model is\ndesigned to minimize trust in other parties in the system. This works by\nvalidating as much as possible according to the consensus rules. In\nparticular, there is no \"majority vote\" that can override things (contrary\nto what some people think, it is not \"longest chain wins, and a majority of\nminers decide\"; even a majority of miners cannot steal your coins or\nproduce more than the allowed subsidy, unless they convince others to\nchange their software). Changing the rules should be possible if there is\nwide consensus, but nobody should feel forced to change their code against\ntheir will.\n\n* Governance: being able to push for a controversial change to the system\nsets an incredibly dangerous precedent about who is in charge of the\nsystem's rules. What if next time it is a change demanded by parties with\nless good intentions (and yes, I believe people in this discussions all\nhave good intentions to improve the system in a way they think is most\nuseful)? I can promise you that I will say anything in mail to this list if\nsomeone points a gun at me, and I think you should make the same assumption\nabout other people here. By avoiding controversial changes, you avoid\nexternal and potentially invisible manipulation.\n\nOf course, sometimes changes to the consensus rules may be wanted. The\npresence of a bug is a good reason, and widespread agreement about one of\nthe system's limitation is too. As I said before, I think technological\ngrowth in network bandwidth, processing power, and storage, are a good\nreason why the system should be able to scale proportionally. I think there\nare good technical and economic reasons why we should be cautious about\nthis, but the primary requirement is consensus, and aligning people's\nexpectation about what they can expect from network's evolution.\n\n-- \nPieter\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/306edc65/attachment.html\u003e"}