There is a healthy amount of confusion about the way that this would work out in practice, with people thinking that miners are the ones making the decision about the outer limits, which is exactly the opposite of what this proposal is suggesting.
As such a simple made up scenario to see how the moving parts actually could interact. It is my hope that a simple scenario would be helpful for people to follow the concepts a bit better.
Scenario
We have today a maximum blocksize which the miners manually set. This property is only used by miners or mining pools. This property is set by them to indicate the maximum size of the blocks they will produce.
We have today a blocksize-accept-limit . This is a technical property, meant to indicate the technical abilities of anyone parsing blocks in the Bitcoin Cash space.
The accept-limit does not need coordination to be changed, if 20% of the full nodes changes to 40MB tomorrow nothing bad will happen.
So in our scenario we go over a couple of years of changes in the wider ecosystem and what each stage looks like.
Year now+1. Our ecosystem has grown, new software releases have happened. A lot more full nodes are deployed. We might have a bunch of 32MB-accepting ones, some 40MB ones, some services even accept 64MB! Lots of differences because those people running that software will have been tested for different limits.
Year now+3 The actual block size being mined is 10MB. The majority of services have software that by default supports 40MB. The miners want to protect themselves and even while the full node mining software by default does more, they configured themselves to keep their accept-limits at 32MB.
Year now+4. Blocksizes are 20MB regularly. Some miners are mining 30MB blocks when the mempool gets really full. We still make sure that the transactions get included in the next block. Practically all of the ecosystem (exchanges, merchants, full nodes, fulcrum like indexers) are running with software marked to support 64MB blocks. The miners are still broadcasting they are accepting only 32MB.
Miners may coordinate between themselves to remove the 32MB accept-limit. They are 100 full nodes in an ecosystem of 40000 full nodes. Price has risen to a level where mining a block for the lolz is not happening anymore. Any attacker is going to lose $100K per block trying to disrupt the network. The big risk is over.
The miners decide its safe, they remove their custom-set accept limits, going back to the default set by their full node team. They KNOW its safe because the rest of the ecosystem is saying they will accept bigger blocks in well-known places or simply their connect string you can find on the future coin.dance like sites.
Year now+5. Blocksizes often touch 32MB. Never going over. In the mean time practically all miners have been replaced by new ones and for sure the software being run by miners is just a year, max 2 old.
A random miner ends up mining a 33MB block. Everyone accepts it because the limits have been raised a year or more ago. By everyone in the ecosystem, over time. As new hardware and software became available.
Miners don’t have to take a risk
The entire problem we have had in the past revolves around miners taking a risk in a cut-throat business. This is solved with the proposal given here. There is no risk when you KNOW that the entire ecosystem will accept it, and you know because the proposal makes clear how everyone should tell the miners what is accepted by the exchanges, services and full nodes.
This proposal removes the risks and avoid complicated systems that may have a negative influence on the open market balances.
