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

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.

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

in the beginning, but in many decades from now the change in value will be smaller and smaller and more smooth looking function.

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?

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.