<p>Section 4. Proof of Work:  (Block production rules)</p>
<blockquote>
<ol start="4">
<li>Proof-of-Work
To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proofof-work system similar to Adam Back's Hashcash [6], rather than newspaper or Usenet posts.
The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the
hash begins with a number of zero bits. The average work required is exponential in the number
of zero bits required and can be verified by executing a single hash.
For our timestamp network, we implement the proof-of-work by incrementing a nonce in the
block until a value is found that gives the block's hash the required zero bits. Once the CPU
effort has been expended to make it satisfy the proof-of-work, the block cannot be changed
without redoing the work. As later blocks are chained after it, the work to change the block
would include redoing all the blocks after it.
The proof-of-work also solves the problem of determining representation in majority decision
making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone
able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority
decision is represented by the longest chain, which has the greatest proof-of-work effort invested
in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the
fastest and outpace any competing chains. To modify a past block, an attacker would have to
redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the
work of the honest nodes. We will show later that the probability of a slower attacker catching up
diminishes exponentially as subsequent blocks are added.
To compensate for increasing hardware speed and varying interest in running nodes over time,
the proof-of-work difficulty is determined by a moving average targeting an average number of
blocks per hour. If they're generated too fast, the difficulty increases</li>
</ol>
</blockquote>
<p>Gold related Supply Model (6. Incentive):</p>
<blockquote>
<p>By convention, the first transaction in a block is a special transaction that starts a new coin owned
by the creator of the block. This adds an incentive for nodes to support the network, and provides
a way to initially distribute coins into circulation, since there is no central authority to issue them.
The steady addition of a constant of amount of new coins is analogous to gold miners expending
resources to add gold to circulation. In our case, it is CPU time and electricity that is expended.
The incentive can also be funded with transaction fees. If the output value of a transaction is
less than its input value, the difference is a transaction fee that is added to the incentive value of
the block containing the transaction. Once a predetermined number of coins have entered
circulation, the incentive can transition entirely to transaction fees and be completely inflation
free.
The incentive may help encourage nodes to stay honest. If a greedy attacker is able to
assemble more CPU power than all the honest nodes, he would have to choose between using it
to defraud people by stealing back his payments, or using it to generate new coins. He ought to
find it more profitable to play by the rules, such rules that favour him with more new coins</p>
</blockquote>
<p>The exact number limited supply I believe is not specifically mentioned in the paper but showed up in the earliest versions of the software. Auditing supply is mentioned however (Section 2 Transactions):</p>
<blockquote>
<p>In the mint based model, the mint was aware of all transactions and
decided which arrived first. To accomplish this without a trusted party, transactions must be
publicly announced [1], and we need a system for participants to agree on a single history of the
order in which they were received. The payee needs proof that at the time of each transaction, the
majority of nodes agreed it was the first received.</p>
</blockquote>
<p>It would be somewhat irresponsible for the whitepaper to include the exact supply specification as it was a proof of concept paper made when bitcoin was started not when bitcoin was deployed in practice(maybe someone else disagrees, personally I think it makes sense, I am learning from history so someone who was there at the time will know more about it). That being said the deflationary nature is self evident in the code for the supply which caps the total supply for bitcoin at 21 million. This happens with &quot;halvings&quot; which reduce the reward of a mined block by half, they happen every 210000 blocks, they have happened before without a problem which leads us to assume they will continue to drop off until the implicit block reward is zero and the network will need to incentivize miners through transaction fees.</p>

CC BY-SA 4.0
2023-02-14T15:11:21.710Z
2023-02-14T15:17:40.237Z
2023-02-14T15:17:40.237Z
Poseidon
<p>Where in the white paper does it mention that every ten minutes only one block will be produced, and where does it mention the deflationary nature of bitcoin, or the maximum supply?</p>

CC BY-SA 4.0
2023-02-14T15:31:11.227Z
Does this answer your question? [How do we know that Bitcoin supply is actually capped at 21 million?](https://bitcoin.stackexchange.com/questions/113940/how-do-we-know-that-bitcoin-supply-is-actually-capped-at-21-million)
Vojtěch Strnad
CC BY-SA 4.0
2023-02-18T16:34:25.213Z
the inter block target time distance could not make it into the paper because it is unnecessary implementation detail
Mercedes
<reward-schedule><whitepaper>
Where in the white paper can we see the block mining frequency or maximum supply?
sat0me
# Where in the white paper can we see the block mining frequency or maximum supply?

(Asked by: username_0 on 2023-02-14)

Where in the white paper does it mention that every ten minutes only one block will be produced, and where does it mention the deflationary nature of bitcoin, or the maximum supply?

**Tags:** reward-schedule, whitepaper

> **Comments:**
> **username_1**: Does this answer your question? [How do we know that Bitcoin supply is actually capped at 21 million?](https://bitcoin.stackexchange.com/questions/113940/how-do-we-know-that-bitcoin-supply-is-actually-capped-at-21-million)  
> **username_2**: the inter block target time distance could not make it into the paper because it is unnecessary implementation detail  

---

## 1 answers

### Answer by username_3 on 2023-02-14. Score: 1

Section 4. Proof of Work: (Block production rules)

> 4. Proof-of-Work
>    To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proofof-work system similar to Adam Back's Hashcash [6], rather than newspaper or Usenet posts.
>    The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the
>    hash begins with a number of zero bits. The average work required is exponential in the number
>    of zero bits required and can be verified by executing a single hash.
>    For our timestamp network, we implement the proof-of-work by incrementing a nonce in the
>    block until a value is found that gives the block's hash the required zero bits. Once the CPU
>    effort has been expended to make it satisfy the proof-of-work, the block cannot be changed
>    without redoing the work. As later blocks are chained after it, the work to change the block
>    would include redoing all the blocks after it.
>    The proof-of-work also solves the problem of determining representation in majority decision
>    making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone
>    able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority
>    decision is represented by the longest chain, which has the greatest proof-of-work effort invested
>    in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the
>    fastest and outpace any competing chains. To modify a past block, an attacker would have to
>    redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the
>    work of the honest nodes. We will show later that the probability of a slower attacker catching up
>    diminishes exponentially as subsequent blocks are added.
>    To compensate for increasing hardware speed and varying interest in running nodes over time,
>    the proof-of-work difficulty is determined by a moving average targeting an average number of
>    blocks per hour. If they're generated too fast, the difficulty increases

Gold related Supply Model (6. Incentive):

> By convention, the first transaction in a block is a special transaction that starts a new coin owned
> by the creator of the block. This adds an incentive for nodes to support the network, and provides
> a way to initially distribute coins into circulation, since there is no central authority to issue them.
> The steady addition of a constant of amount of new coins is analogous to gold miners expending
> resources to add gold to circulation. In our case, it is CPU time and electricity that is expended.
> The incentive can also be funded with transaction fees. If the output value of a transaction is
> less than its input value, the difference is a transaction fee that is added to the incentive value of
> the block containing the transaction. Once a predetermined number of coins have entered
> circulation, the incentive can transition entirely to transaction fees and be completely inflation
> free.
> The incentive may help encourage nodes to stay honest. If a greedy attacker is able to
> assemble more CPU power than all the honest nodes, he would have to choose between using it
> to defraud people by stealing back his payments, or using it to generate new coins. He ought to
> find it more profitable to play by the rules, such rules that favour him with more new coins

The exact number limited supply I believe is not specifically mentioned in the paper but showed up in the earliest versions of the software. Auditing supply is mentioned however (Section 2 Transactions):

> In the mint based model, the mint was aware of all transactions and
> decided which arrived first. To accomplish this without a trusted party, transactions must be
> publicly announced [1], and we need a system for participants to agree on a single history of the
> order in which they were received. The payee needs proof that at the time of each transaction, the
> majority of nodes agreed it was the first received.

It would be somewhat irresponsible for the whitepaper to include the exact supply specification as it was a proof of concept paper made when bitcoin was started not when bitcoin was deployed in practice(maybe someone else disagrees, personally I think it makes sense, I am learning from history so someone who was there at the time will know more about it). That being said the deflationary nature is self evident in the code for the supply which caps the total supply for bitcoin at 21 million. This happens with "halvings" which reduce the reward of a mined block by half, they happen every 210000 blocks, they have happened before without a problem which leads us to assume they will continue to drop off until the implicit block reward is zero and the network will need to incentivize miners through transaction fees.


---

