{"type":"rich","version":"1.0","author_name":"npub1zw5sx3at9e7k6yvpuw7dnsxdcfmch5ngrkfvxdsuwwmn5c0ue4wqajkh0g","author_url":"https://nostr.ae/npub1zw5sx3at9e7k6yvpuw7dnsxdcfmch5ngrkfvxdsuwwmn5c0ue4wqajkh0g","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-07-22\n📝 Original message:Pieter, I agree with the overall gist of your statement (that Bitcoin is a\nconsensus-driven protocol that's incompatible with certain forms of central\ngovernance) but I respectfully disagree with some of the conclusions you're\ndrawing.\n\n\u003e Consensus changes should be done using consensus, _and the default in\ncase of controversy is no change_.\n\n(emphasis mine)\n\nI think that there's a disconnect between the idea that Bitcoin Core making\na consensus-driven change in turn means that the network is being forced\ndown a certain path. This takes away a great deal of the individual agency\nthat makes Bitcoin what it is today. Upgrading to a version of Bitcoin Core\nthat is incompatible with your ideals is in no way a forced choice, as you\nhave stated in your email; forks, alternative clients, or staying on an\nolder version are all valid choices. If the majority of the network chooses\nnot to endorse a specific change, then the majority of the network will\ncontinue to operate just fine without it, and properly structured consensus\nrules will pull the minority along as well. (For example, re: block sizes,\nif the majority of hashing power remains on a version or fork that does not\nmine \u003e1MB blocks, a chain of \u003c1MB blocks will continue to be the longest,\nand up to date clients will still respect that. That is consensus at work,\npure and simple.)\n\nObviously Core is in a unique position as a reference client and ignoring\nthat would be irresponsible. If broad consensus among the developers cannot\nbe reached, then Core should not make a given change. However, freezing\nCore's ability to make changes in light of _any_ controversy is allowing a\nfew voices to dictate direction and is counter to any kind of\nconsensus-driven decision making.\n\nPlacing Core and its developers on some sort of pedestal where we believe\nthat they dictate policy and therefore shouldn't be allowed to take any\nrisks will create the very situation that you're advocating against- that a\nsmall group of developers have control over Bitcoin's policies. Instead, we\nshould strive to treat Core as _just another Bitcoin Client_, we should\neducate users to make informed choices about the version of software they\nare running and the choices implicit in that, and we should allow consensus\nat the protocol level to make the decisions on the overall direction of the\nnetwork.\n\n\u003e My personal opinion is that we - as a community - should indeed let a fee\nmarket develop, and rather sooner than later\n\nI will keep this brief because this is straying off topic of the idea of\nthis thread- but I don't believe that increasing Bitcoin's capacity as a\nnetwork is inherently incompatible with the development of a fee market,\nand considering a fee market to be formed of only a single set of variables\n(transaction rate versus block size) is not sound economic analysis.\n\nOn Wed, Jul 22, 2015 at 10:32 AM, Milly Bitcoin via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e default in case of controversy is no change.\n\u003e\u003e\n\u003e\n\u003e I think the result of this would probably be that no controversial changes\n\u003e ever get implemented via this process so others will hard fork the code and\n\u003e eventually make this process irrelevant.  Since you need close to 100%\n\u003e agreement the irrelevance would have to come as a step function which will\n\u003e manifest itself in a rather disruptive manner.\n\u003e\n\u003e The question is really is this hark-forking disruption worse than coming\n\u003e up with some kind of process to handle controversial changes.\n\u003e\n\u003e Russ\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/6f2fbfdd/attachment.html\u003e"}