
Dissecting the code responsible for the Bitcoin halving - Mojah
https://ma.ttias.be/dissecting-code-bitcoin-halving/
======
westurner
> _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...](https://bitcoin.stackexchange.com/questions/22308/what-would-happen-
if-90-of-the-bitcoin-miners-suddenly-stopped-mining#comment40537_22319) )

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)

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

~~~
kadoban
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.

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

------
DC-3
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
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.

