roydan
Senior Member
Founding Member
Sapphire Member
Silver Star
Silver Star
Silver Star
Silver Star
Silver Star
There's an interesting fact about bitcoin halving that I don't think too many people know about. I wrote about it on another forum in 2021, but thought that in light of a recent bitcoin discussion, maybe it will interest more people here:
New bitcoins enter circulation (also known as subsidy or inflation) at a known and decreasing rate, which is cut in half every 210,000 blocks, roughly every 4 years.
In the happy days of epoch 1, every block released 50 new coins into circulation. Then epoch 2 came with a reward of 25 BTC per block, then epoch 3 with 12.5, then 6.25, and today miners get 3.125 new coins from every block.
Let’s take a look at the function in the code that executes it:
This simple and easy-to-understand function has remained almost unchanged since it was written by Satoshi Nakamoto himself.
Let’s focus on two interesting things written there:
The comment above it says:
Instead of cutting the reward in half, the function just right-shifts it, deleting the rightmost bit (the least significant bit, or LSB).
Think about dividing the number 98400 by 10 five times in a row. But instead of dividing by 10, we just remove the last digit each time.
First removal: 9840
Second: 984
Third: 98
Fourth: 9
Fifth: 0
The first few “divisions” work as expected, but eventually, the number becomes small enough that removing a digit doesn’t behave like division anymore. First it gets wonky until it just wipes the number out.
In Bitcoin’s case, the number isn’t decimal but binary, and the initial value is 50 * COIN (line 1926). That’s 5 billion sats, represented as a long binary string:
100101010000001011111001000000000.
As it turns out, the first nine halvings (around 36 years) effectively divide the reward by two, but from the 10th halving onward, the division starts to get messy, just like in our 98400 example.
The variable that controls the subsidy size is int64. It can hold a total of 64 bits (each either 0 or 1), meaning you can delete the rightmost bit only 63 times. Beyond that, the variable itself would vanish from memory and trigger an error.
Line 1923 ensures we don’t reach that situation. It’s designed to allow the first 63 deletions, prevent the 64th, and determine that from that point on, the subsidy size is zero without performing any further calculation.
(Read those last two sentences again. They’re super important.)
We saw earlier that 5 billion sats are represented by only 33 binary digits. The 32nd halving will reduce the subsidy from 2 sats to 1 satoshi, and the 33rd will eliminate it completely, from 1 sat per block to 0.
And what about the halvings from the 34th to the 63rd? They’ll all glide smoothly over line 1923, divide zero by two, get zero again, and then define that the “new subsidy” is still zero, but a freshly calculated zero.
This process will continue for 120 years.
That’s 120 years during which every Bitcoin node, every 10 minutes, calculates 0/2 and comes to the same conclusion that the result is still zero.
Just like a kid in the back sit of a car repeatedly asking "are we there yet?" For 120 years.
Line 1923 only protects the variable logically from attempts to delete more bits than it has. It doesn’t reference the situation (which arrives after the 33rd halving) where the value itself has already reached zero.
This is one of the most fascinating aspects of Bitcoin. I don’t think it’s a bug. It’s a deliberate, future proofed design that hints at a future where even a single satoshi may eventually have to be divided.
Don’t trust, verify:
https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1915
New bitcoins enter circulation (also known as subsidy or inflation) at a known and decreasing rate, which is cut in half every 210,000 blocks, roughly every 4 years.
In the happy days of epoch 1, every block released 50 new coins into circulation. Then epoch 2 came with a reward of 25 BTC per block, then epoch 3 with 12.5, then 6.25, and today miners get 3.125 new coins from every block.
Let’s take a look at the function in the code that executes it:
This simple and easy-to-understand function has remained almost unchanged since it was written by Satoshi Nakamoto himself.
Let’s focus on two interesting things written there:
1. We call it “halving,” but it’s not exactly that.
Line 1928The comment above it says:
But that’s NOT what actually happens.
Instead of cutting the reward in half, the function just right-shifts it, deleting the rightmost bit (the least significant bit, or LSB).
Think about dividing the number 98400 by 10 five times in a row. But instead of dividing by 10, we just remove the last digit each time.
First removal: 9840
Second: 984
Third: 98
Fourth: 9
Fifth: 0
The first few “divisions” work as expected, but eventually, the number becomes small enough that removing a digit doesn’t behave like division anymore. First it gets wonky until it just wipes the number out.
In Bitcoin’s case, the number isn’t decimal but binary, and the initial value is 50 * COIN (line 1926). That’s 5 billion sats, represented as a long binary string:
100101010000001011111001000000000.
As it turns out, the first nine halvings (around 36 years) effectively divide the reward by two, but from the 10th halving onward, the division starts to get messy, just like in our 98400 example.
2. How much is 0 / 2?
Bitcoin allows, in a planned and deliberate way, 120 full years in which the question “how much is zero divided by two?" is answered over and over again.The variable that controls the subsidy size is int64. It can hold a total of 64 bits (each either 0 or 1), meaning you can delete the rightmost bit only 63 times. Beyond that, the variable itself would vanish from memory and trigger an error.
Line 1923 ensures we don’t reach that situation. It’s designed to allow the first 63 deletions, prevent the 64th, and determine that from that point on, the subsidy size is zero without performing any further calculation.
(Read those last two sentences again. They’re super important.)
We saw earlier that 5 billion sats are represented by only 33 binary digits. The 32nd halving will reduce the subsidy from 2 sats to 1 satoshi, and the 33rd will eliminate it completely, from 1 sat per block to 0.
And what about the halvings from the 34th to the 63rd? They’ll all glide smoothly over line 1923, divide zero by two, get zero again, and then define that the “new subsidy” is still zero, but a freshly calculated zero.
This process will continue for 120 years.
That’s 120 years during which every Bitcoin node, every 10 minutes, calculates 0/2 and comes to the same conclusion that the result is still zero.
Just like a kid in the back sit of a car repeatedly asking "are we there yet?" For 120 years.
Why was the code written like this?
Why not stop the process in 2140 when the subsidy first reaches zero? Why allow another 120 years of unnecessary divisions from zero to zero?Line 1923 only protects the variable logically from attempts to delete more bits than it has. It doesn’t reference the situation (which arrives after the 33rd halving) where the value itself has already reached zero.
This is one of the most fascinating aspects of Bitcoin. I don’t think it’s a bug. It’s a deliberate, future proofed design that hints at a future where even a single satoshi may eventually have to be divided.
Don’t trust, verify:
https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1915