rich1.0npub1zw5sx3at9e7k6yvpuw7dnsxdcfmch5ngrkfvxdsuwwmn5c0ue4wqajkh0ghttps://nostr.ae/npub1zw5sx3at9e7k6yvpuw7dnsxdcfmch5ngrkfvxdsuwwmn5c0ue4wqajkh0gnjumphttps://nostr.ae📅 Original date posted:2015-07-22 📝 Original message:Pieter, I agree with the overall gist of your statement (that Bitcoin is a consensus-driven protocol that's incompatible with certain forms of central governance) but I respectfully disagree with some of the conclusions you're drawing. > Consensus changes should be done using consensus, _and the default in case of controversy is no change_. (emphasis mine) I think that there's a disconnect between the idea that Bitcoin Core making a consensus-driven change in turn means that the network is being forced down a certain path. This takes away a great deal of the individual agency that makes Bitcoin what it is today. Upgrading to a version of Bitcoin Core that is incompatible with your ideals is in no way a forced choice, as you have stated in your email; forks, alternative clients, or staying on an older version are all valid choices. If the majority of the network chooses not to endorse a specific change, then the majority of the network will continue to operate just fine without it, and properly structured consensus rules will pull the minority along as well. (For example, re: block sizes, if the majority of hashing power remains on a version or fork that does not mine >1MB blocks, a chain of <1MB blocks will continue to be the longest, and up to date clients will still respect that. That is consensus at work, pure and simple.) Obviously Core is in a unique position as a reference client and ignoring that would be irresponsible. If broad consensus among the developers cannot be reached, then Core should not make a given change. However, freezing Core's ability to make changes in light of _any_ controversy is allowing a few voices to dictate direction and is counter to any kind of consensus-driven decision making. Placing Core and its developers on some sort of pedestal where we believe that they dictate policy and therefore shouldn't be allowed to take any risks will create the very situation that you're advocating against- that a small group of developers have control over Bitcoin's policies. Instead, we should strive to treat Core as _just another Bitcoin Client_, we should educate users to make informed choices about the version of software they are running and the choices implicit in that, and we should allow consensus at the protocol level to make the decisions on the overall direction of the network. > My personal opinion is that we - as a community - should indeed let a fee market develop, and rather sooner than later I will keep this brief because this is straying off topic of the idea of this thread- but I don't believe that increasing Bitcoin's capacity as a network is inherently incompatible with the development of a fee market, and considering a fee market to be formed of only a single set of variables (transaction rate versus block size) is not sound economic analysis. On Wed, Jul 22, 2015 at 10:32 AM, Milly Bitcoin via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > default in case of controversy is no change. >> > > I think the result of this would probably be that no controversial changes > ever get implemented via this process so others will hard fork the code and > eventually make this process irrelevant. Since you need close to 100% > agreement the irrelevance would have to come as a step function which will > manifest itself in a rather disruptive manner. > > The question is really is this hark-forking disruption worse than coming > up with some kind of process to handle controversial changes. > > Russ > > > > _______________________________________________ > 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/20150722/6f2fbfdd/attachment.html>