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.