<p>i wanna add additional info towards what Pieter wrote:</p>
<p>it would not be wise to change into more than that for shown MAX_MONEY value before the year 2100 and only into the next million, if even. for synching into 22nd century (22000000) next.
(but synching code had also been written in the past. so maybe its not even a good idea towards that. making changes at all from here on towards that value. Ever! otherwise: &quot;out of synch&quot; problems)</p>
<p>this ensures its not growing larger than what the century it exist inside is capable to offer in limitation capabilities for growth itself.</p>
<p>however you will loose structural integrity towards that build like it is today.
meaning: an extension may not be an advantage here! but its too far away to tell for sure yet, so its more a warning!!!</p>
<p>a shorter number is like a triangle vs. a square that would be the next bigger number if the shorter is the triangle.</p>
<p>transfering only 3 lines takes up lesser space in bytes than transfering 4 lines the same size a line.
we are more on an advantage with the number 21 here cause 2+1 in crosssum gives us the principle of the 3 lines i mentioned above as well.</p>
<p>sure you can increase further depending on further centuries it develops into.</p>
<p>but you can also work yourself downwards to its beginnings. when 21 wasnt even in place yet towards the millions shown today.</p>
<p>choice is yours! (to point on forking into own chain ideas and values solutions for that)</p>
<p>and regarding: sanity checking, it wasnt named that way without reason. cause it would be insane to meddle with that entry by people in the wrong mind for the burden it takes to keep it the way it is and should be! to make sure things running stable (the most important aspect from a developers perspective i would say anyways).
(a static and constexpr for this variable also points strongly on this fact)</p>
<p>but where it will be growing into more. its up to future generations to deal with that problem i guess.</p>
<p>still it cannot hurt to have mentioned that i think still important relationship towards that number. 21st century tech build for 21st century like it is right now! an alone important monetization aspect for the network itself. and maybe most important future anchor as well!</p>
<p>there is also a bit more to it. but from my experience regarding its source code. the century linking does the job best! while anything how it became that way. was how it grew into that.</p>
<p>long enough time to figuring out from now on. if we should make a change for it or not in the future! i would call this a fair deal as well towards the yet unknown future in general understanding!</p>

CC BY-SA 4.0
2024-01-23T19:36:07.753Z
Hi CrashOverride, I’m having a hard time following your train of thought. Could you perhaps try to read your _answer_ as if you were looking at it with a fresh set of eyes to ensure that you are providing enough information to establish your line of argument? Also, answer posts on Bitcoin Stack Exchange are meant to provide their own _standalone_ answer to the question. It seems to me that you are trying to discuss Pieter’s answer, but our platform is a poor fit for discussions.
Murch
CC BY-SA 4.0
2024-02-20T19:59:00.103Z
i did what you asked of me. it may be a long explanation. but it is solid. detailed and simple written to understand it by normal coders. you do not need to be a pro coder to understand what i wrote about. but the problem is, it was simple explained. and this is the main reason why people struggle with it.
i wasnt trying to discuss his answer. i was extending it and going into more details about the number limitation per se. i was pointing on a potential change but with a warning. and i explained why i think it has its reasons for that warning. but also for a potential change.
CrashOverride
CC BY-SA 4.0
2024-01-23T18:16:14.033Z
2024-01-23T18:57:58.540Z
2024-01-23T18:57:58.540Z
CrashOverride
<blockquote>
<p>Where is the bitcoin source code is the 21 million hard cap stated?</p>
</blockquote>
<p>Nowhere, because there isn't actually a 21 million cap rule.</p>
<p>The relevant code is <a href="https://github.com/bitcoin/bitcoin/blob/v25.0/src/validation.cpp#L1552L1563" rel="nofollow noreferrer">this</a>:</p>
<pre><code>CAmount GetBlockSubsidy(int nHeight, const Consensus::Params&amp; consensusParams)
{
    int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
    // Force block reward to zero when right shift is undefined.
    if (halvings &gt;= 64)
        return 0;

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

// consensusParams.nSubsidyHalvingInterval = 210000.
</code></pre>
<p>It computes the maximum subsidy a miner can claim at a given block height, and this function effectively controls Bitcoin's inflation schedule. The often-stated &quot;21 million&quot; limit is just the <em>approximate</em> result of summing all coins this function permits to be brought into circulation, over all time.</p>
<p>The code, in short, implements the following:</p>
<ul>
<li>The first 210000 blocks (roughly 4 years) allow up to 50 BTC subsidy each.</li>
<li>Then 210000 blocks with 25 BTC each</li>
<li>Then 210000 blocks with 12.5 BTC each</li>
<li>...</li>
<li>After 10 halvings, the subsidy becomes 0.04882812 BTC rather than 0.048828125 (which would need half-satoshi precision, and the code uses integer division which rounds down).</li>
<li>After 33 halvings, the subsidy becomes 0.</li>
</ul>
<p>If one sums up all the subsidy values over all halvings, the result is 20999999.9769 BTC, not 21000000 BTC. Though, due to various minutiae, that's also not the real limit; <a href="https://bitcoin.stackexchange.com/a/38998/208">this answer</a> goes into more detail.</p>
<hr />
<p>Now, the <a href="https://github.com/bitcoin/bitcoin/blob/v25.0/src/consensus/amount.h#L17L26" rel="nofollow noreferrer">code</a> does also contain this constant:</p>
<pre><code>/** No amount larger than this (in satoshi) is valid.
 *
 * Note that this constant is *not* the total money supply, which in Bitcoin
 * currently happens to be less than 21,000,000 BTC for various reasons, but
 * rather a sanity check. As this sanity check is used by consensus-critical
 * validation code, the exact value of the MAX_MONEY constant is consensus
 * critical; in unusual circumstances like a(nother) overflow bug that allowed
 * for the creation of coins out of thin air modification could lead to a fork.
 * */
static constexpr CAmount MAX_MONEY = 21000000 * COIN;
</code></pre>
<p>which, as the comment explains, does not actually control the total supply (as that's rather the result of summing all the subsidy), but is used as a sanity check in many places.</p>

CC BY-SA 4.0
2023-09-01T13:34:51.403Z
What about this https://github.com/bitcoin/bitcoin/blob/master/src/consensus/amount.h. I came across it this morning whilst browsing through doxygen.
Eoin
CC BY-SA 4.0
2023-09-01T15:56:17.553Z
I've cited this file already in my answer above.
Pieter Wuille
CC BY-SA 4.0
2023-08-31T14:39:42.087Z
2023-09-02T02:26:35.080Z
2023-09-02T02:26:35.080Z
Pieter Wuille
<p>I'd like to be able to see the 21,000,000 number.</p>

CC BY-SA 4.0
2023-08-31T14:12:06.273Z
Does this answer your question? [What actually caps Bitcoin's supply at 21 million?](https://bitcoin.stackexchange.com/questions/100639/what-actually-caps-bitcoins-supply-at-21-million)
alcio
CC BY-SA 4.0
2023-08-31T14:22:05.927Z
I don't think that actually answers OP's question; it goes into how consensus rules define the limit, but doesn't show the source code that actually effects this.
Pieter Wuille
<bitcoin-core-development><reward-schedule>
Where is the bitcoin source code is the 21 million hard cap stated?
Eoin
# Where is the bitcoin source code is the 21 million hard cap stated?

(Asked by: username_0 on 2023-08-31)

I'd like to be able to see the 21,000,000 number.

**Tags:** bitcoin-core-development, reward-schedule

> **Comments:**
> **username_1**: Does this answer your question? [What actually caps Bitcoin's supply at 21 million?](https://bitcoin.stackexchange.com/questions/100639/what-actually-caps-bitcoins-supply-at-21-million)  
> **username_2**: I don't think that actually answers OP's question; it goes into how consensus rules define the limit, but doesn't show the source code that actually effects this.  

---

## 2 answers

### Answer by username_2 on 2023-08-31. Score: 14 | Accepted answer

> Where is the bitcoin source code is the 21 million hard cap stated?

Nowhere, because there isn't actually a 21 million cap rule.

The relevant code is [this](https://github.com/bitcoin/bitcoin/blob/v25.0/src/validation.cpp#L1552L1563):

```
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;
}

// consensusParams.nSubsidyHalvingInterval = 210000.

```

It computes the maximum subsidy a miner can claim at a given block height, and this function effectively controls Bitcoin's inflation schedule. The often-stated "21 million" limit is just the *approximate* result of summing all coins this function permits to be brought into circulation, over all time.

The code, in short, implements the following:

* The first 210000 blocks (roughly 4 years) allow up to 50 BTC subsidy each.
* Then 210000 blocks with 25 BTC each
* Then 210000 blocks with 12.5 BTC each
* ...
* After 10 halvings, the subsidy becomes 0.04882812 BTC rather than 0.048828125 (which would need half-satoshi precision, and the code uses integer division which rounds down).
* After 33 halvings, the subsidy becomes 0.

If one sums up all the subsidy values over all halvings, the result is 20999999.9769 BTC, not 21000000 BTC. Though, due to various minutiae, that's also not the real limit; [this answer](https://bitcoin.stackexchange.com/a/38998/208) goes into more detail.

---

Now, the [code](https://github.com/bitcoin/bitcoin/blob/v25.0/src/consensus/amount.h#L17L26) does also contain this constant:

```
/** No amount larger than this (in satoshi) is valid.
 *
 * Note that this constant is *not* the total money supply, which in Bitcoin
 * currently happens to be less than 21,000,000 BTC for various reasons, but
 * rather a sanity check. As this sanity check is used by consensus-critical
 * validation code, the exact value of the MAX_MONEY constant is consensus
 * critical; in unusual circumstances like a(nother) overflow bug that allowed
 * for the creation of coins out of thin air modification could lead to a fork.
 * */
static constexpr CAmount MAX_MONEY = 21000000 * COIN;

```

which, as the comment explains, does not actually control the total supply (as that's rather the result of summing all the subsidy), but is used as a sanity check in many places.

> **Comments:**
> **username_0**: What about this https://github.com/bitcoin/bitcoin/blob/master/src/consensus/amount.h. I came across it this morning whilst browsing through doxygen.  
> **username_2**: I've cited this file already in my answer above.  

---

### Answer by username_3 on 2024-01-23. Score: -3

i wanna add additional info towards what username_2 wrote:

it would not be wise to change into more than that for shown MAX\_MONEY value before the year 2100 and only into the next million, if even. for synching into 22nd century (22000000) next.
(but synching code had also been written in the past. so maybe its not even a good idea towards that. making changes at all from here on towards that value. Ever! otherwise: "out of synch" problems)

this ensures its not growing larger than what the century it exist inside is capable to offer in limitation capabilities for growth itself.

however you will loose structural integrity towards that build like it is today.
meaning: an extension may not be an advantage here! but its too far away to tell for sure yet, so its more a warning!!!

a shorter number is like a triangle vs. a square that would be the next bigger number if the shorter is the triangle.

transfering only 3 lines takes up lesser space in bytes than transfering 4 lines the same size a line.
we are more on an advantage with the number 21 here cause 2+1 in crosssum gives us the principle of the 3 lines i mentioned above as well.

sure you can increase further depending on further centuries it develops into.

but you can also work yourself downwards to its beginnings. when 21 wasnt even in place yet towards the millions shown today.

choice is yours! (to point on forking into own chain ideas and values solutions for that)

and regarding: sanity checking, it wasnt named that way without reason. cause it would be insane to meddle with that entry by people in the wrong mind for the burden it takes to keep it the way it is and should be! to make sure things running stable (the most important aspect from a developers perspective i would say anyways).
(a static and constexpr for this variable also points strongly on this fact)

but where it will be growing into more. its up to future generations to deal with that problem i guess.

still it cannot hurt to have mentioned that i think still important relationship towards that number. 21st century tech build for 21st century like it is right now! an alone important monetization aspect for the network itself. and maybe most important future anchor as well!

there is also a bit more to it. but from my experience regarding its source code. the century linking does the job best! while anything how it became that way. was how it grew into that.

long enough time to figuring out from now on. if we should make a change for it or not in the future! i would call this a fair deal as well towards the yet unknown future in general understanding!

> **Comments:**
> **username_4**: Hi username_3, I’m having a hard time following your train of thought. Could you perhaps try to read your _answer_ as if you were looking at it with a fresh set of eyes to ensure that you are providing enough information to establish your line of argument? Also, answer posts on Bitcoin Stack Exchange are meant to provide their own _standalone_ answer to the question. It seems to me that you are trying to discuss username_2’s answer, but our platform is a poor fit for discussions.  
> **username_3**: i did what you asked of me. it may be a long explanation. but it is solid. detailed and simple written to understand it by normal coders. you do not need to be a pro coder to understand what i wrote about. but the problem is, it was simple explained. and this is the main reason why people struggle with it. i wasnt trying to discuss his answer. i was extending it and going into more details about the number limitation per se. i was pointing on a potential change but with a warning. and i explained why i think it has its reasons for that warning. but also for a potential change.  

---

