Quote from: Herbert2020 on October 10, 2019, 01:13:18 PM

Quote from: MicroGuy on October 10, 2019, 12:56:41 PM

Fixing this bug correctly would require a hard fork which is not happening anytime soon!

Code:

int64_t nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210,000 blocks
// which will occur approximately every 4 years.
nSubsidy >>= (nHeight / 210000);

The block number is divided by 210000 (the "apparent" subsidy halving interval in blocks), and the result is used as input for a binary shift, applied to the original payout (50 BTC), expressed in base units.

Thanks to the new-goldmine interval being exactly 64 times the halving interval, and 64 being the size in bits of the currency datatype, the cycle repeats itself every 64 halvings.

this is not a bug, this is more like a convenience. right now and until hundreds of years we are going to use fixed bit integers (such as 32 and 64 bit ints) to represent a lot of things. in programming we do this all the time. for example the year 2038 problem in time representation has been a thing for a long time as we were using 32 bit integers. now we are using 64 bit integers and that postpones it until we change it in a couple of hundred years!

the same is happening here, after a hundred years when we get close to this being a problem, by that time computers will surely support 256 bit numbers by default as their small integers that a CPU can handle in one call and we simply change int64_t to int256_t without needing any kind of hard fork or anything like that.

changing that line of code right now to anything bigger like 256-bit would require handling 192-bits of zero for no reason for 200+ years!

So does that mean the code seemed like it repeats the cycle every 256 years but in reality it would actually still end after 256 years? Like the code was supposed to cap bitcoin at 21 million, but because of code limitations, the code was instead written in a format where it instead shows that the block resets every 256 years?