Dissecting the code responsible for the Bitcoin halving

> 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 :

> 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... )

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

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).

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.

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?