rich1.0npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rhttps://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rnjumphttps://nostr.ae📅 Original date posted:2015-06-18 📝 Original message:On Thu, Jun 18, 2015 at 1:14 PM, Wladimir J. van der Laan <laanwj at gmail.com> wrote: > Like in any open source project there is lots of decision making ability > for code changes. I'd say look at the changelog for e.g. 0.11 > https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log, > or follow pull requests for a while, to see how many decisions about > changes are made from day to day. No, I'm not sitting on my hands, and so > is none of the other contributors that you'd like to get rid of. > The analogy goes further even. Even though I disagree with some of the changes you're making, I respect Mike's (and anyone's) right to make a fork of Bitcoin Core. That's how open source works: if people disagree with changes made or not made, they can maintain their own version. However: > Consensus changes are *much* more difficult, on the other hand. Even > relatively straightforward softforks come with a long discussion process > (see BIP62, BIP66). A hardfork is hard to do at the best of times (everyone > needs to upgrade their software!), and simply not possible if almost the > entire technical community disagrees with you. > Consensus changes - in particular hardforks - are not about making a change to the software. You are effectively asking users of the system to migrate to a new system. Perhaps one which is a philosophical successor to the old one, but a different system, with new rules that are incompatible with the old one. I believe this is something that can only be done if there is no controversy about the change, for different reasons: * Risk: no matter how you determine the switchover date, there is no way of knowing when (and whether at all) everyone changes their full nodes (and perhaps other software), and even very high hash power votes cannot prevent an actual fork from appearing afterwards. At best, people lose the guarantee that their confirmations are meaningful (because at some point it becomes clear that the other side will get adopted, and they need to switch). At worst, a fork persists, and two partitions appear, in each of which you can spend every pre-existing coin. This defeats the primary purpose Bitcoin was designed for: double spend protection. * Philosophy: Bitcoin is not a democracy. The full node security model is designed to minimize trust in other parties in the system. This works by validating as much as possible according to the consensus rules. In particular, there is no "majority vote" that can override things (contrary to what some people think, it is not "longest chain wins, and a majority of miners decide"; even a majority of miners cannot steal your coins or produce more than the allowed subsidy, unless they convince others to change their software). Changing the rules should be possible if there is wide consensus, but nobody should feel forced to change their code against their will. * Governance: being able to push for a controversial change to the system sets an incredibly dangerous precedent about who is in charge of the system's rules. What if next time it is a change demanded by parties with less good intentions (and yes, I believe people in this discussions all have good intentions to improve the system in a way they think is most useful)? I can promise you that I will say anything in mail to this list if someone points a gun at me, and I think you should make the same assumption about other people here. By avoiding controversial changes, you avoid external and potentially invisible manipulation. Of course, sometimes changes to the consensus rules may be wanted. The presence of a bug is a good reason, and widespread agreement about one of the system's limitation is too. As I said before, I think technological growth in network bandwidth, processing power, and storage, are a good reason why the system should be able to scale proportionally. I think there are good technical and economic reasons why we should be cautious about this, but the primary requirement is consensus, and aligning people's expectation about what they can expect from network's evolution. -- Pieter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/306edc65/attachment.html>