Bitcoin DOES NOT have a Cap of 21 Million Coins!!

[MicroGuy]

Contrary to popular belief, Bitcoin does NOT have a cap of 21 million coins.

The block rewards resets to 50 every 256 years making the supply grow indefinitely, forever.

[1714117884]

1714117884

[1714117884]

1714117884

[googs84]

Contrary to popular belief, Bitcoin does NOT have a cap of 21 million coins.

The block rewards resets to 50 every 256 years making the supply grow indefinitely, forever.

I think the problem is that cap exists because after that the Hash rate would be so high that everyone would get a very minuscule rewards for mining one block which would decrease miner's interest in mining bitcoin which is why I think people say there is a cap of 21 million coins. The speed of mining would become too damns low after that barely a single coin could be mined in a day.

[Herbert2020]

The block rewards resets to 50 every 256 years making the supply grow indefinitely, forever.

lol. no it doesn't
is it April already?

[MicroGuy]

The block rewards resets to 50 every 256 years making the supply grow indefinitely, forever.

lol. no it doesn't
is it April already?

This isn't a joke.

Satoshi made a mistake in the code that causes the block reward cycle to repeat itself every 256 years.

[Herbert2020]

The block rewards resets to 50 every 256 years making the supply grow indefinitely, forever.

lol. no it doesn't
is it April already?

This isn't a joke.

Satoshi made a mistake in the code that causes the block reward cycle to repeat itself every 256 years.

well first of all post the link to the lines of code that you think are doing this.

secondly even if there is such a thing in the code (which i seriously doubt it), it is a bug. and bugs don't define bitcoin. they will be fixed and removed. just like the inflation but that bitcoin experienced in early years. that didn't change anything about the supply even though the bug existed.

[MicroGuy]

The block rewards resets to 50 every 256 years making the supply grow indefinitely, forever.

lol. no it doesn't
is it April already?

This isn't a joke.

Satoshi made a mistake in the code that causes the block reward cycle to repeat itself every 256 years.

well first of all post the link to the lines of code that you think are doing this.

secondly even if there is such a thing in the code (which i seriously doubt it), it is a bug. and bugs don't define bitcoin. they will be fixed and removed. just like the inflation but that bitcoin experienced in early years. that didn't change anything about the supply even though the bug existed.

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.

[CryptoBry]

The block rewards resets to 50 every 256 years making the supply grow indefinitely, forever.

lol. no it doesn't
is it April already?

This isn't a joke.

Satoshi made a mistake in the code that causes the block reward cycle to repeat itself every 256 years.

I have never looked into this revelation of yours. Anyway, in case it is true that the reward cycle repeats itself every 256 years I am thinking that it can be something I will not be concerned about as that can be a long, long, long way into the future. The number 2140 rings a bell a lot in many posts online because that can be the time when mining rewards can be gone and that is around 120 years from today. Now, I am sure that nobody can ever remember me at that time except maybe if this forum will still be existing and that accounts from the past are not deleted for any reason. Maybe we should be asking the real Satoshi Nakamoto wherever he can be why he made this mistake.

[MicroGuy]

I have never looked into this revelation of yours. Anyway, in case it is true that the reward cycle repeats itself every 256 years I am thinking that it can be something I will not be concerned about as that can be a long, long, long way into the future.

Sure. As long as we stop falsely advertising a finite supply of 21 million. Bitcoin has an unlimited supply currently.

Maybe we should be asking the real Satoshi Nakamoto wherever he can be why he made this mistake.

Ummm, by definition people don't make mistakes on purpose.

[Herbert2020]

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!

[Wexnident]

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?

[Broly46]

The bitcoin reset itself after 256 years? I think it also reset all the balance in our wallet too, basically we have to mine bitcoin from block 0 all over again? No body is going to wait 256 years to start it over again. We can just fork the code to 1024 years, 2048 years, and start mining from block 0, but no body going to mine the forked coin.

[Herbert2020]

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?

no, there is no cycle. you and OP are overthinking it.
the consensus rule is that every 210,000 blocks the block reward must be cut in half. the way implementations of bitcoin consensus rule turn that rule into code is up to them. here the decision is to do it with a shift because shifts are faster and also it uses a 64-bit integer because there is no point in using anything bigger!
this has nothing to do with code limitation, there just is no point in doing it any other way.

think of it this way. you have a small box containing your junk and you want to store it somewhere. you may add some junk to that box later but not for years. for storage you could use your garage, or you could rent a storage unit somewhere or you could rent a gigantic villa and store that tiny box alone there! obviously the choice is your garage until it become bigger that you need a bigger space but not sooner.

[DannyHamilton]

Bah. This is nonsense.

You are looking at an old version of the code.  The hard fork that you are warning of has already happened in the past.  This is what the code looks like now:

Code:

CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
    int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return 0;

    CAmount nSubsidy = 50 * COIN;
    // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
    nSubsidy >>= halvings;
    return nSubsidy;
}

That means that we could have a problem every 350,725,227,654,375 years (assuming that we are still using 64 bit computers at that time and that Bitcoin still exists).

For all intents and purposes, we can say that there is a finite supply of less than 21 million.

[aplistir]

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.

Interesting find 

The "right" way to fix that would be to just add a check. Eg.  If nsubsidy < "than some value", then nSubsidy == 0
With this kind of a check the binary shift would not happen when it is not needed any longer.

Why would this need a hard fork? Couldn't it just be fixed in the next versions of core? After all it is just a bug, and repairing it wouldn't conflict with any other core implementation atleast in the next 250 years or so.

[MicroGuy]

Bah. This is nonsense.

You are looking at an old version of the code.  The hard fork that you are warning of has already happened in the past.  This is what the code looks like now:

Code:

CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
    int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return 0;

    CAmount nSubsidy = 50 * COIN;
    // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
    nSubsidy >>= halvings;
    return nSubsidy;
}

That means that we could have a problem every 350,725,227,654,375 years (assuming that we are still using 64 bit computers at that time and that Bitcoin still exists).

For all intents and purposes, we can say that there is a finite supply of less than 21 million.

Thanks Danny. Apparently the code was indeed fixed.

https://github.com/bitcoin/bitcoin/pull/3842

Probably makes sense to lock this thread now. Sorry for the confusion.