5 ms·

Dissecting the code responsible for the Bitcoin halving

39 points by Mojah 6y ago

DC-3 6y ago
TL;DR It's a right bitshift Hasn't bitcoin been around long enough that articles about it don't need to spend the first half explaining how the Bitcoin hash challenge works?
- Zariel 6y ago
  Or if you are someone who doesn't know how it works it makes the whole article flow and make sense without having to context shift out to Google. The world of readers doesn't know what you know, or what I know for that matter.
westurner 6y ago
> The difficulty of the calculations are determined by how many zeroes need to be at the front. [...] The difficulty is actually not determined by the number of zeroes (as was initially the case). https://en.bitcoinwiki.org/wiki/Difficulty_in_Mining https://en.bitcoinwiki.org/wiki/Difficulty_in_Mining : > The Bitcoin network has a global block difficulty. Valid blocks must have a hash below this target. Mining pools also have a pool-specific share difficulty setting a lower limit for shares. "Less than" instead of "count leading zeroes" makes it possible for the difficulty to be less broadly adjusted in a difficulty retargeting. Difficulty retargetings occur after up to 2016 blocks (~10 minutes, assuming the mining pool doesn't suddenly disappear resulting in longer block times that could make it take months to get to 2016 blocks according to "What would happen if 90% of the Bitcoin miners suddenly stopped mining?" https://bitcoin.stackexchange.com/questions/22308/what-would-happen-if-90-of-the-bitcoin-miners-suddenly-stopped-mining#comment40537_22319 https://bitcoin.stackexchange.com/questions/22308/what-would... ) Difficulty is adjusted up or down (every up to 2016 blocks) in order to keep the block time to ~10 minutes. The block reward halving occurs every ~4 years (210,000 blocks). Relatedly, Moore's law observes/predicts that processing power (as measured by transistor count per unit) will double every 2 years while price stays the same. Is energy efficiency independent of transistor count? https://en.wikipedia.org/wiki/Moore%27s_law https://en.wikipedia.org/wiki/Moore%27s_law
jcranmer 6y ago
There's an error in the post: x >> 65 in C is not the same as in x >> 1. It's undefined behavior, so theoretically the compiler can do whatever it wants with it (although, this is the kind of undefined behavior that's particularly rare to take advantage of). But even in the absence of optimizer shenanigans, it's not even consistent on hardware. On x86, the hardware only looks at the low 6 bits of the shift amount, i.e., it's x >> 1. On ARM, the full shift amount is used, so x >> 65 would be 0.
hendzen 6y ago
Why implement the halving as a step function every 210k blocks instead of continuously reducing the block subsidy each block? An infrequent halving event that poses a bit of a shock to the cashflow of miners seems more risky, in that it will suddenly bankrupt a chunk of the miners with insufficient marginal profitability, rather than blurring out those bankruptcies over a larger window of time. More concretely, rather than having the block subsidy = 50 >>= floor(height / halvings), it could simply be 50 / 2^(height / 610k).
- deleted 6y ago
  [deleted]
- improv32 6y ago
  Well it shouldn't make a difference in practice because everyone knows exactly how far away the halving is and makes their financial calculations accordingly
- kadoban 6y ago
  Does seem like a better idea. Only counter I'd mention is that it's _very_ predictable when the halvenings are coming, it should be simple to price them in to planning decisions.
- officialjunk 6y ago
  in the beginning, but in many decades from now the change in value will be smaller and smaller and more smooth looking function.

39 points by Mojah 6y ago

DC-3 6y ago

TL;DR It's a right bitshift Hasn't bitcoin been around long enough that articles about it don't need to spend the first half explaining how the Bitcoin hash challenge works?

Zariel 6y ago
Or if you are someone who doesn't know how it works it makes the whole article flow and make sense without having to context shift out to Google. The world of readers doesn't know what you know, or what I know for that matter.

westurner 6y ago

> The difficulty of the calculations are determined by how many zeroes need to be at the front. [...] The difficulty is actually not determined by the number of zeroes (as was initially the case). https://en.bitcoinwiki.org/wiki/Difficulty_in_Mining https://en.bitcoinwiki.org/wiki/Difficulty_in_Mining : > The Bitcoin network has a global block difficulty. Valid blocks must have a hash below this target. Mining pools also have a pool-specific share difficulty setting a lower limit for shares. "Less than" instead of "count leading zeroes" makes it possible for the difficulty to be less broadly adjusted in a difficulty retargeting. Difficulty retargetings occur after up to 2016 blocks (~10 minutes, assuming the mining pool doesn't suddenly disappear resulting in longer block times that could make it take months to get to 2016 blocks according to "What would happen if 90% of the Bitcoin miners suddenly stopped mining?" https://bitcoin.stackexchange.com/questions/22308/what-would-happen-if-90-of-the-bitcoin-miners-suddenly-stopped-mining#comment40537_22319 https://bitcoin.stackexchange.com/questions/22308/what-would... ) Difficulty is adjusted up or down (every up to 2016 blocks) in order to keep the block time to ~10 minutes. The block reward halving occurs every ~4 years (210,000 blocks). Relatedly, Moore's law observes/predicts that processing power (as measured by transistor count per unit) will double every 2 years while price stays the same. Is energy efficiency independent of transistor count? https://en.wikipedia.org/wiki/Moore%27s_law https://en.wikipedia.org/wiki/Moore%27s_law

jcranmer 6y ago

There's an error in the post: x >> 65 in C is not the same as in x >> 1. It's undefined behavior, so theoretically the compiler can do whatever it wants with it (although, this is the kind of undefined behavior that's particularly rare to take advantage of). But even in the absence of optimizer shenanigans, it's not even consistent on hardware. On x86, the hardware only looks at the low 6 bits of the shift amount, i.e., it's x >> 1. On ARM, the full shift amount is used, so x >> 65 would be 0.

hendzen 6y ago

Why implement the halving as a step function every 210k blocks instead of continuously reducing the block subsidy each block? An infrequent halving event that poses a bit of a shock to the cashflow of miners seems more risky, in that it will suddenly bankrupt a chunk of the miners with insufficient marginal profitability, rather than blurring out those bankruptcies over a larger window of time. More concretely, rather than having the block subsidy = 50 >>= floor(height / halvings), it could simply be 50 / 2^(height / 610k).

deleted 6y ago
[deleted]
improv32 6y ago
Well it shouldn't make a difference in practice because everyone knows exactly how far away the halving is and makes their financial calculations accordingly
kadoban 6y ago
Does seem like a better idea. Only counter I'd mention is that it's _very_ predictable when the halvenings are coming, it should be simple to price them in to planning decisions.
officialjunk 6y ago
in the beginning, but in many decades from now the change in value will be smaller and smaller and more smooth looking function.