On the 24th of July 2019 the BSV blockchain will undergo a forking protocol upgrade. This upgrade has very limited scope with just changing the block size hard cap but it warrants some further explanation. It was first detailed in part one of this post series.
The first upgrade, code named “Quasar”, is proposed for Jul 24th 2019 and is primarily focused on scaling. At a protocol level the only change planned for this upgrade is a lifting of the default block size hard cap. We have previously signaled an intent to raise the cap to 512MB however after consultation with the Bitcoin Association (the owner of the BSV project) and miners representing a significant majority of hash rate it has been decided that the BSV software will implement a default of 2GB in July. Initially a majority of miner hash rate will manually set their hard cap down to 512MB.
Quick recap of caps
There are actually three block size caps to consider when thinking about how block size governance works in Bitcoin. I have previously only talked about two: soft cap and hard cap. But in this case it’s worth thinking about two different versions of the hard cap.
Soft cap: Is a miner specific setting that indicates that maximum sized block a specific node will try to mine.
Hard cap: Is the maximum sized block that a miner will accept as valid. This is the setting we intend to remove entirely in the Genesis upgrade next February. It is also the one we need to consider in two ways.
Firstly, there is the default setting. If you don’t manually set this value on a BSV node it will use the default. The upcoming Quasar upgrade changes this default value from 128mb to 2gb or more specifically 2,000,000,000 bytes.
Secondly there is the setting that the majority of mining hashrate is using. In this case we have previously announced that a group of miners totaling a majority of hashrate have signaled their intent to manually set their hard cap to 512mb.
So let’s call these two cases the “default hard cap” and the “consensus hard cap” respectively.
Consensus is among miners
If you’ve ever heard the nonsense about how it’s important for other people (non-miners) to run fully validating nodes, you’re about to get a real life demonstration that this is simply not true.
We are not recommending that anyone but miners make manual changes to their hard caps. This is for the simple reason that it is easier to follow consensus if you don’t enforce a hard cap at all and if you can’t do that, the next best thing is to have a higher hard cap than the consensus hard cap. We will explain this in more detail later in this post.
Recommendations for miners
If you are a miner it is recommended that you set your hard cap to 512mb and that you set your soft cap to some lower value. In the BSV software these are config parameters that actually have different names. By way of example I’ll give you the specific config parameters for a 512/256 cap configuration:
Hard cap: -excessiveblocksize=512000000 Soft cap: -blockmaxsize=256000000
Recommendations for everyone else
By everyone else we mean people/businesses that are running an instance of BSV blockchain that is not involved in mining. I call these “Blockchain listeners”. Miners write the blockchain, anyone else running BSV is just listening to it.
For these we don’t recommend changing any of the above settings. Your default hard cap should remain at 2gb. If you do attempt to change it to match the miners there is a risk the miners will change the setting sometime between now and February next year (and you may not hear about it) and you will be permanently forked off the network until you notice and raise your own limit.
But what if there’s a bigger block than 512mb?
Fair question. Your node will accept that block initially then one of two thing will happen.
1/ If the miner that mined the larger block has a majority of hashrate then the chain will get longer and you’ll continue following the longest chain. The other miners will have to choose to either raise their limit and follow the longest chain or remain forked. I’d put my money on the former.
2/ If the miner that mined the larger block has minority hashrate then the bock will get orphaned and your BSV instance will reorg back to the majority chain.
That sounds dangerous
Of course it does. We’ve all been told for 10 years that orphans are bad and a security risk. But it’s simply not the case, it’s actually how Bitcoin is supposed to work. I’ve addressed this point extensively here.
Retraining Bitcoin
In the introduction we described the Quasar upgrade as being very limited in scope. That’s not entirely true. From a technical point of view the changes are limited but its role in the lead up to the Genesis upgrade is much more important that it may seem on the surface.
Some will no doubt ask “what if a malicious party mines blocks larger than 512mb just to cause trouble”. Well I hope they do because it will be the first real life demonstration of the power of Nakamoto consensus as a capacity governance tool.
This upgrade represents a very significant cultural shift for Bitcoin. By separating the default hard cap (developer chosen) from the consensus hard cap (miner chosen) we are diluting the power of the default setting which can only be set by a single group (us). This is a very active effort by the BSV development team to push the responsibility for capacity consensus out of their own hands and into the hands of miners. The miners are now responsible for managing block size consensus and if they screw it up it will cost them. The final stage in that transition is removing the default altogether next year (or rather the default will be infinite). But we think it’s fair to give the miners time to get used their new role and we also need a bit more time to give them better tools to manage uncapped block sizes more safely.
Putting aside miners for a moment, there is another consideration. Operators of blockchain listeners are slowly getting used to the idea that they need to make peace with orphans and reorgs or at the least, if they can’t make peace with it, learn how manage in an environment where they are normalized. It’s not hard to do and we already have some of the tools to do it. But a reorg or two from time to time is a good reminder. This is another reason we are pushing businesses onto the STN. We want to break your services there. But reorgs don’t really break services they seem to cause more of a mental shock to people who’ve been listening to Core for too long. So if someone wants to mine 600mb blocks and try to cause some reorgs we’re pretty happy for that to happen. It will do two things, it will help people in the ecosystem get used to reorgs as normal events and Nakamoto consensus will ensure the event costs some miner dearly which is also a thing they need to get used to.
Bitcoin is a brutally Darwinian game. It is a reflection of the natural world in which some of the harsher realities are the very things that drive the strengthening of species and the global ecosystem that hosts them. Quasars are one the most brutal phenomena in nature and the Quasar upgrade is all about helping all Bitcoin participants to understand and adapt to those facts in preparation for the gloves coming off fully after the return to Genesis.
Steve Shadders
