So the question isn't whether we should or shouldn't change a block size. It's how the hell do we change the block size? Can you change the blocksize? Please enlighten me on how you intend to change the blocksize in everyone else's client? Bitcoin has become too large for even developers of the primary client to forcefully change, and they're certainly not going to risk their own reputation by attempting to change it against the will of users.
So how do you even get the consensus of users of the system to agree to whatever blocksize increase you intend to have? Attempts at civil discussion were shut on both sides. There were some not willing to compromise on the existing blocksize, or even asking for smaller sizes, while others were not willing to accept anything but complete removal of the limit. The correct action was taken to do nothing, since it was too controversial to force one opinion on everyone, and would've set a terrible precedent that a few developers have the authority to specify the rules on behalf of everyone.
Bitcoiners have settled on the fact that nobody is in charge. Bitcoin Cashers are still arguing about who's going to be in power.
By convincing them to do so, in the same way that every other change to bitcoin is made? Or, alternatively, implement my changes via a soft fork, get half the hash power, and start orphaning people. Segwit, for example, was a major change to the bitcoin protocol, deployed via exactly this same strategy.
> The correct action was taken to do nothing, since it was too controversial to force one opinion on everyone
Segwit was very controversial as well. Don't for a second pretend like it wasn't. Lots of people disagree with it. Perhaps not a majority, but a large amount did. And yet segwit was activated and exist today. It was literally a soft fork blocksize increase that was forced on people who disagreed.
And before someone brings up the whole "soft fork, vs hardfork", I'd like to point out that segwit itself was a soft fork blocksize increase. Blocksize increases do not require hardforks. some methods of increasing the blocksize do, but there are many ways to do the same thing that segwit did, and increase the blocksize via a softfork.
So if you really want to be technical, the way that I would increase the blocksize a second time, is to create a second softfork blocksize increase, convince 51% of the hashpower to include the change, and then orphan all blocks that don't use the new changes.
At this point it doesn't matter if some people refuse to install the software. Soft forks are backward compatible, and all past nodes would follow, unless they specifically decide to hard fork away to stop the soft fork.
If you want proof that a blocksize increase can be done with a soft fork, go google "Extension blocks". It was a soft fork blocksize increase, created by Joseph Poon, the Lighting Network inventor. If you do believe that I am credible on the topic of soft fork blocksize increases, then surely you should believe that the inventor of the lightning network is credible.
Although I guess I should have said "one of the people who created this proposal", as there were multiple authors. chjj also deserves much of the credit. I only referenced Joseph specifically, because of the lightning network thing, which core supporters seem to like a lot.
Proof: https://github.com/tothemoon-org/extension-blocks/blob/maste...
Bitcoiners are silenced as soon as they start asking questions. Bitcoin Cashers have carried on with the original experiment and are currently trying to figure out governance.
It has a better model, which is every user is autonomous and has the volition to choose the software they wish to run to interact with the economy they wish to participate in.
Governance inherently means you want some people to tell other people how to behave.
But of course, that's a lie, such a change would not be liquid with the rest of the economy, and you'd have forked yourself off into irrelevance, just as the fools who tried to set the 1mb temporary limit to permanent have done themselves. That they're too stupid to figure out they're on the wrong side is of zero consequence to the fact that they are.
Is that you Theymos?
> ...and has the volition to choose the software they wish to run to interact with the economy they wish to participate in.
How many software choices do BTC users have? I know the answer to this. It's one. You've got one choice to choose from.
> Governance inherently means you want some people to tell other people how to behave.
Governance means if people are willing to talk to each other (and listen), they'll find they have common ground and can make progress and move forward together.
No
> How many software choices do BTC users have? I know the answer to this. It's one. You've got one choice to choose from
What? There's a bunch of BTC clients. Bitcoin Core is the defacto reference client due to its lineage and presence on bitcoin.org/bitoincore.org, and the fact that the developers work on it in tandem with the BIP process. (There's a process!)
> Governance means if people are willing to talk to each other (and listen), they'll find they have common ground and can make progress and move forward together.
You can't listen to everyone and you ultimately end up having "leaders" to present ideas. Populism does not work. Ideas based on merit will get support by people who put principles above ego.
There were many attempts to get common ground in the block size debate. The ones who attempted to find the middle-ground (ie, Pieter Wuille and Adam Back) had their ideas shot down by big blockers like Mike Hearn, who brought his ego into the equation and tried to make it about "I was here first," and did not want to follow the BIP process. He openly states on the Bitcoin mailing list that he thinks developers should decide the system on behalf of all the users. Other maintainers made it clear that backward incompatible changes don't happen to the rules without broad consensus (of which there was none).
Here's what Adam Back thought about the block size back before Blockstream's agenda took hold of Bitcoin's development. https://i.redd.it/9enseqrfp1v01.png
> Other maintainers made it clear that backward incompatible changes don't happen to the rules without broad consensus (of which there was none).
And this is the fundamental problem. The community had no idea how many people actually wanted blocks bigger than 1mb because everyone who voiced it was kicked out and labeled a scammer. The "bigger block" group was and continues to be massive. The 1mb group continues to be a minority.
He himself gave directions on how to increase the blocksize, and talked about how the base layer could scale up to visa scale transactions.