roydan
Elite Member
- Dec 17, 2013
- 5,618
- 14,552
or: One hundred (and twenty) years of solitude.
New bitcoins entering circulation (= subsidy =inflation) at a known and decreasing rate, that's being cut in half every 210K blocks (every about 4 years).
In the happy days of epoch1, every block released 50 new coins to circulation. Then epoch2 came, with a reward of 25btc/block, then epoch3 with 12.5, and today we get 6.25 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 was kept almost unchanged since it was written by Satoshi Nakamoto himself.
Let's focus on two interesting things that are written there:
1. We call it halving, but it's not what it is.
Line 1149
The comment above it says
But it's NOT what actually happens.
Instead of cutting the reward by half, the function just right-shift (deleting the rightmost digit).
Think about dividing the number 13800 by 10, 5 times in a row. But instead of dividing them by 10, we just remove the last character (LSB=least significant bit).
The first 2 divisions are acting "properly" and as expected. Returning 1380, and then 138. In the third division, we go from 138 to 13, then from 13 to 1, and then from 1 to 0.
In the case of Bitcoin, the number is not decimal but binary and the initial value is "50 * COIN" (line: 1147). 5 billion sats:
100101010000001011111001000000000.
As it turned out, the first 9 halvings (~36 years) are actually dividing the reward by 2, but from the 10th forward, the division starts to get messy (like in our example of 13800)
2. How much is 0/2? Bitcoin allows, in a planned and conscious way, 120 full years where the question "how much is zero divided by 2" is being answered over and over again.
The type of variable that controls the subsidy size is int64. It has a total of 64 digits (of either 0 or 1) so you can delete the rightmost digit only 63 times. Beyond that, the variable itself will disappear completely from memory and will return an error.
Line 1144 ensures that we do not get into this situation. It was designed to allow the first 63 deletions, to prevent the 64th attempt onwards, and to determine that from now on the size of the subsidy is zero without making any calculation (read the last 2 sentences again, they're super important).
We saw earlier that the number 5 billion is represented by only 33 binary digits. The 32nd halving will divide the subsidy from 10 (2) to one single satoshi, and the 33rd will eliminate it completely, from 1 sat / block to 0.
And what about the other halvings, from the 34th to the 63rd? They will all skip lightly over line 1144, divide by 2 (delete LSB) by the number zero, get the result zero again, and determine that the size of the new subsidy is no longer zero as it was before, but a new zero. And it will keep happening for 120 years!
120 whole years in which each computer node at least once every ten minutes is calculating how much is zero divided by two and comes to the shocking conclusion that the result is still zero.
Why is the code written like this? Why not stop the farce as early as 2140 when the subsidy reaches zero? Why allow another 120 full years of unnecessary divisions from zero to zero?
Line 1144 only protects the variable "logically" from attempts to delete more digits than it has and has no reference to a situation (which will come after 33 halvings) in which the value of the variable has already dropped to zero.
This is one of the most interesting things about bitcoin. I don't think this is a flawed code, but a very impressive look into the future, where every Satoshi may have to be divided too.
Don't trust - verify: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1140
New bitcoins entering circulation (= subsidy =inflation) at a known and decreasing rate, that's being cut in half every 210K blocks (every about 4 years).
In the happy days of epoch1, every block released 50 new coins to circulation. Then epoch2 came, with a reward of 25btc/block, then epoch3 with 12.5, and today we get 6.25 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 was kept almost unchanged since it was written by Satoshi Nakamoto himself.
Let's focus on two interesting things that are written there:
1. We call it halving, but it's not what it is.
Line 1149
The comment above it says
Code:
Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.Instead of cutting the reward by half, the function just right-shift (deleting the rightmost digit).
Think about dividing the number 13800 by 10, 5 times in a row. But instead of dividing them by 10, we just remove the last character (LSB=least significant bit).
The first 2 divisions are acting "properly" and as expected. Returning 1380, and then 138. In the third division, we go from 138 to 13, then from 13 to 1, and then from 1 to 0.
In the case of Bitcoin, the number is not decimal but binary and the initial value is "50 * COIN" (line: 1147). 5 billion sats:
100101010000001011111001000000000.
As it turned out, the first 9 halvings (~36 years) are actually dividing the reward by 2, but from the 10th forward, the division starts to get messy (like in our example of 13800)
2. How much is 0/2? Bitcoin allows, in a planned and conscious way, 120 full years where the question "how much is zero divided by 2" is being answered over and over again.
The type of variable that controls the subsidy size is int64. It has a total of 64 digits (of either 0 or 1) so you can delete the rightmost digit only 63 times. Beyond that, the variable itself will disappear completely from memory and will return an error.
Line 1144 ensures that we do not get into this situation. It was designed to allow the first 63 deletions, to prevent the 64th attempt onwards, and to determine that from now on the size of the subsidy is zero without making any calculation (read the last 2 sentences again, they're super important).
We saw earlier that the number 5 billion is represented by only 33 binary digits. The 32nd halving will divide the subsidy from 10 (2) to one single satoshi, and the 33rd will eliminate it completely, from 1 sat / block to 0.
And what about the other halvings, from the 34th to the 63rd? They will all skip lightly over line 1144, divide by 2 (delete LSB) by the number zero, get the result zero again, and determine that the size of the new subsidy is no longer zero as it was before, but a new zero. And it will keep happening for 120 years!
120 whole years in which each computer node at least once every ten minutes is calculating how much is zero divided by two and comes to the shocking conclusion that the result is still zero.
Why is the code written like this? Why not stop the farce as early as 2140 when the subsidy reaches zero? Why allow another 120 full years of unnecessary divisions from zero to zero?
Line 1144 only protects the variable "logically" from attempts to delete more digits than it has and has no reference to a situation (which will come after 33 halvings) in which the value of the variable has already dropped to zero.
This is one of the most interesting things about bitcoin. I don't think this is a flawed code, but a very impressive look into the future, where every Satoshi may have to be divided too.
Don't trust - verify: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1140
Last edited by a moderator:
