rich1.0npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rhttps://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rnjumphttps://nostr.ae📅 Original date posted:2017-03-28 📝 Original message:On Tue, Mar 28, 2017 at 12:56 PM, Paul Iverson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > So I think Core can't decide on hard forks like this. It must be left up to > the users. I think only choice is for Core to add a run-time option to allow > node operators to increase block size limit, so that this very controversial > decision is not coming from Core. It must come from the community. Bitcoin Core's (nor any other software's) maintainers can already not decide on a hard fork, and I keep being confused by the focus on Core in this topic. Even if a hard forking change (or lack thereof) was included into a new release, it is still up to the community to choose to run the new software. Bitcoin Core has very intentionally no auto-update feature, as the choice for what network rules to implement must come from node operators, not developers. Ask yourself this: if a new Bitcoin Core release would include a new rule that blacklists <random famous person>'s coins. What do you think would happen? I hope that people would refuse to update, and choose to run different full node software. Core is not special. It is one of many pieces of software that implement today's Bitcoin consensus rules. If a hardfork is to take place in a way that does not result in two currencies, it must be clear that the entire ecosystem will adopt it. Bitcoin Core will not merge any consensus changes that do not clearly satisfy that criterion. -- Pieter