How Reducing Bitcoin’s Smallest Unit of Account Could Extend the Block Subsidy Past the 33rd Halving
First, let me start by saying that I’m no expert when it comes to Bitcoin’s source code (or C++ for that matter). I’ve got enough coding experience to have a basic understanding of what’s going on though.
Second, this post isn’t about extending the block subsidy. It’s about reducing Bitcoin’s smallest unit of account on-chain. There’s a simple way of doing this but it inadvertently results in an extension of the block subsidy. I found this to be an interesting quirk in the code and something worth sharing.
Why reduce the smallest unit of account on-chain?
Imagine a future where the whole world uses bitcoin as their base layer money and a single satoshi has become quite valuable. In this future world, rounding to the nearest satoshi when settling on-chain may be undesirable. If we decide we need more resolution on-chain, then we’ll need to reduce the smallest unit of account from sats to something smaller.
Currently, Bitcoin’s smallest unit of account is 1/100,000,000th of a bitcoin or 0.00000001 BTC, also known as 1 satoshi. For those unaware, this parameter is defined here in src/amount.h, on line 14:
static const CAmount COIN = 100000000;
If we wanted to change the smallest unit of account, one way to do this would be to simply update this parameter:
static const CAmount COIN = 100000000000; // for a change to millisats
static const CAmount COIN = 100000000000000; // for a change to microsats
static const CAmount COIN = 100000000000000000; // for a change to nanosats
Warning! I’m not exactly sure how updating this parameter might affect other parts of Bitcoin’s code or whether this update would cause a hard fork. That’s outside the scope of this post and I’ll leave that discussion to the experts (or maybe I’ll try to tackle it in the future). What I would like to focus on instead is how reducing the smallest unit of account in this way would inadvertently extend the halving schedule past the well-known and frequently referenced “final” 33rd halving, which is estimated to take place around the year 2140.
In his article, Dissecting the code responsible for the Bitcoin halving, Mattias Geniar (@mattiasgeniar) does an excellent job explaining why, with sats as the smallest unit of account, Bitcoin will only have 33 halvings. In summary, the function GetBlockSubsidy(), located in src/validation.cpp, defines the initial block subsidy as 50 BTC:
CAmount nSubsidy = 50 * COIN;
Then, in the next line of code, there is a clever way of determining the current block subsidy by taking nSubsidy in its binary form and removing the same number of bits from the right side of that binary number as the number of halvings which have already occurred. So, for example:
sats
The initial subsidy is equal to 50 * 100,000,000 = 5,000,000,000 sats. Written in its binary form, we get 100101010000001011111001000000000. In our current epoch, after 3 halvings, we can determine the block subsidy by removing 3 bits from the right, 100101010000001011111001000000-000. Converting 100101010000001011111001000000 back to its decimal form gives us 625,000,000 sats (or 6.25 BTC). Great, the code and math all checks out!
As you can see, the maximum number of halvings is equal to the number of bits it takes to represent the initial subsidy in its binary form. With sats as our smallest unit of account, the initial subsidy (5 billion sats) in binary form, 100101010000001011111001000000000, only has 33 bits. Go ahead…count them…I did! So after the 33rd halving, there will be no more bits left to remove and the block subsidy will go to zero.
Now, let’s do the same exercise but with millisats, microsats, and nanosats:
millisats (msats)
The initial subsidy would be 50 * 100,000,000,000 = 5,000,000,000,000 msats, which in binary is 1001000110000100111001110010101000000000000 (43 bits). Thus, with msats as the smallest unit of account, Bitcoin would have 43 halvings until the block subsidy goes to zero around the year 2180.
microsats (μsats)
The initial subsidy would be 50 * 100,000,000,000,000 = 5,000,000,000,000,000 μsats, which in binary is 10001110000110111100100110111111000001000000000000000 (53 bits). Thus, with μsats as the smallest unit of account, Bitcoin would have 53 halvings until the block subsidy goes to zero around the year 2220.
nanosats (nsats)
The initial subsidy would be 50 * 100,000,000,000,000,000 = 5,000,000,000,000,000,000 nsats, which in binary is 100010101100011100100011000001001000100111101000000000000000000 (63 bits). Thus, with nsats as the smallest unit of account, Bitcoin would have 63 halvings until the block subsidy goes to zero around the year 2260.
One thing worth noting is the hard coded upper limit to the number of halvings, which is currently set to 64 here. I assume the reason this limit is set to 64 is because anything higher would require nSubsidy to change its data type from int64 to int128. This change is technically possible, so one could imagine a future where we simply continue shrinking the smallest unit of account and the block subsidy never actually runs out or goes to zero…it just keeps getting smaller and smaller. This could continue as long as our computers are able to work with these increasingly large initial nSubsidy integers.
Naturally, one might then ask, if the block subsidy never runs out, won’t we eventually exceed the 21 million hard cap? Quite beautifully, the answer is no! 21 million BTC would remain the hard cap and instead of exceeding it, we would just keep getting closer and closer to it the more we reduced the smallest unit of account. This might actually prove to be a better policy since most people already believe there will eventually be 21 million BTC in total when in reality there will only ever be 20,999,999.97690000 BTC (assuming we stick with sats as the smallest unit of account). Ok…one last calculation below…the number of bitcoin that will be mined in total and by when for each unit of account:
sats: 20,999,999.97690000 BTC by 2140
millisats: 20,999,999.99997060000 BTC by 2180
microsats: 20,999,999.99999995800000 BTC by 2220
nanosats: 20,999,999.99999999996010000 BTC by 2260
As we choose smaller and smaller units of account, we inadvertently extend the timeframe of the block subsidy and get closer and closer to the asymptotic limit of 21 million BTC. Maybe this won’t be a problem we have to deal with in our lifetimes or maybe there’s a better way to reduce the smallest unit of account on-chain without extending the halving schedule. Either way, I just wanted to share this interesting quirk in the code which connects the smallest unit of account and the number of halvings!
