On 24 July 2019, the Bitcoin SV (BSV) network will undergo a forking protocol upgrade. This upgrade is focused on scaling: the only change planned is to lift the default block size hard cap from its current 128MB to 2GB (2000 MB). Although the default block size hard cap will be 2GB, initially, a significant portion of miner hash rate will manually set their hard cap to a lower (but still very robust) level of 512MB – far higher than any other competing Bitcoin project.
The Quasar upgrade represents a key step in Bitcoin SV’s journey to unlock the massive on-chain scaling power that was always possible with Bitcoin, and enable BSV to become the global enterprise blockchain. BSV can already handle 300+ transactions per second comfortably; this capacity is continually being expanded and is expected to cross 1000+ transactions per second in the coming months after the Quasar network upgrade.
Bitcoin Association Founding President Jimmy Nguyen comments on how this upgrade helps Bitcoin miners: “Miners need to be aware that massive scaling is critical for their profitability – especially after the next block reward halving in May 2020 which reduces the block reward subsidy from 12.5 to 6.25 coins, and then again in 2024 when the subsidy is reduced to 3.125 coins, and again every several years after. For mining to remain profitable, miners need to earn more in transaction fees from each block to compensate for the lower block reward subsidy. This is only possible on BSV. During a 21 May 2019 test on the BSV Scaling Test Network, a 1.42GB block was mined – which resulted for the first time in transaction fees which were more than the 12.5 coin block reward subsidy. This is how Bitcoin’s economic model is meant to work, and this is what Satoshi always envisioned to ensure miners remain profitable.”
Mining nodes and blockchain listeners: update software before 24 July 2019
This announcement describes the Quasar protocol upgrade and what it means for mining nodes, and other operators of BSV instances (“blockchain listeners”) which do not write to the blockchain.
Note that the Quasar upgrade is different than version 0.2.1 of the Bitcoin SV Node implementation released on 12 July 2019. Version 0.2.1 was an optional release which added certain improvements – in particular to substantially decrease the time it takes to produce blocks with many transactions, enabling miners to produce even larger blocks than are already common on the BSV blockchain.
Version 0.2.1 adds certain improvements and is strongly recommended for miners, but it is NOT REQUIRED for the Quasar protocol upgrade. Any mining node or blockchain listener who prefers to continue using BSV Node version 0.2.0 can still upgrade directly to Quasar for the network upgrade on 24 July 2019.
The BSV network will upgrade to Quasar on 24 July 2019 at approximately 13:00 G.M.T. Mining nodes and blockchain listeners are encouraged to immediately update their BSV software, in advance of the network upgrade.
Source code for the Quasar upgrade will be available on the BitcoinSV.io website at: https://download.bitcoinsv.io/bitcoinsv/0.2.1/
Block size caps: 3 different types
There are actually three block size caps to consider when thinking about how block size governance works in Bitcoin. People often talk about two caps: soft cap and hard cap. But it is worth thinking about two different versions of the hard cap.
Soft cap: this is a miner specific setting that indicates that maximum sized block a specific node will try to mine.
Hard cap: this is the maximum sized block that a miner will accept as valid. This is the setting that the BSV Node team intends to remove entirely in the “Genesis” upgrade in February 2020. The hard cap should be considered in two ways.
- Default hard cap. These is a default setting for the hard cap. If a BSV node operator does not manually set this value, it will use the default. The Quasar upgrade on 24 July 2019 changes this default value from 128MBto 2GB, or more specifically 2,000,000,000 bytes.
- Consensus hard cap. No matter what the default setting is for the hard cap, the majority of mining hash rate may use a different setting. In this case, we have previously announced that a group of miners totalling what we expect to be a majority of hash rate have signalled their intent to manually set their hard cap to 512MB – still much higher than the prior 128MB default hard cap, but lower than the 2GB default hard cap.
Recommendation for miners
We recommend that only mining nodes make manual changes to the default hard cap. This is for the simple reason that it is easier to follow consensus if you do not enforce a hard cap at all; and if you cannot do that, the next best thing is to have a higher hard cap than the consensus hard cap. We will explain in more detail soon.
If you are a mining pool operator or 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 Bitcoin SV software, these are config parameters that actually have different names. By way of example, here are the specific config parameters for a 512MB hard cap/256MB soft cap configuration:
Hard cap: -excessiveblocksize=512000000
Soft cap: -blockmaxsize=256000000
Recommendations for everyone else besides miners: “blockchain listeners”
Many businesses and individuals run an instance of Bitcoin SV but are not involved in mining. For example, if you operate a wallet or an exchange that supports BSV, you are running an instance of the Bitcoin SV Node software. But unlike miners – who write to the blockchain – other operators of BSV instances are just “blockchain listeners.”
If you are a blockchain listener, we recommend that you do not change any default settings in the BSV Node software. Your default hard cap should remain at 2GB. If you attempt to change it to match the miners, there is a risk the miners will change the setting sometime between now and February 2020 (and you may not hear about it); in that scenario, you will be permanently forked off the network until you notice the change made by miners and raise your own hard cap limit.
But what if there’s a bigger block than 512MB?
Your node will accept that block initially, but then one of two things will happen:
- If the miner that mined the larger block has a majority of hashrate, 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. We expect this is the likely scenario.
- If the miner that mined the larger block has minority hashrate, the block will get orphaned and your Bitcoin SV instance will reorganize back to the majority chain.
Contrary to what the Bitcoin world has incorrectly been told for the past 10 years, orphaned blocks are not bad and are not a security risk. Orphaned blocks are a feature of Bitcoin and are actually part of how Bitcoin’s Nakamoto consensus is supposed to work. Read more about this from nChain’s Chief Technology Officer Steve Shadders.
Changing the Culture of Bitcoin
The Quasar upgrade represents a significant cultural shift for Bitcoin. By separating the default hard cap (set by protocol developers) from the consensus hard cap (set by miners), the Bitcoin SV Node team is diluting the power of the default setting. This is a very active effort by the Bitcoin SV Node team to push the responsibility for capacity consensus into the hands of miners. Miners are now responsible for managing block size consensus, and if they make mistakes, it will cost them because they have an economic interest in making the best decisions.
Next year, the Bitcoin SV network will take the final step in this cultural transition. With the “Genesis” upgrade in February 2020, the Bitcoin SV Node team will completely remove the default hard cap (or more accurately, the default hard cap will be infinite). Over the next 6 months, we hope miners will learn their new role in managing the consensus hard cap on the BSV network. During this time, the Bitcoin SV Node team will work on getting miners better tools to manage uncapped block sizes more safely.
Furthermore, operators of blockchain listeners are slowly getting accustomed to the idea that they need to make peace with orphan blocks and block reorganizations; or at the least, they need to learn how to manage in an environment where orphan blocks and block reorganizations are normalised. Block reorganizations do not break services; they only appear to shock people who have been incorrectly listening to Bitcoin Core developers for too long.
Steve Shadders, nChain’s Chief Technology Officer and Technical Director of the Bitcoin SV Node team explains: “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. The Quasar upgrade is all about helping all Bitcoin (BSV) participants to understand and adapt to that fact, in preparation for BSV’s Genesis upgrade in February 2020.”
