In part 1, we covered the tools that Bitcoin uses—cryptography, elliptic curves, hashing, Merkle roots—how these are all used to generate proof of work. We will now consider the Bitcoin money supply and how it is restricted. We will discuss transactions, how they are constructed and sent and a specific type of transactions known as Coinbase transactions.

2) The Bitcoin Money Supply

We covered Bitcoin mining in part 1. Mining is crucial to the ecosystem for both its security and the money supply. New bitcoin enters the ecosystem through Bitcoin mining. Miners issue new coins to themselves when they mine a block, and these new coins are called Coinbase transactions.

With the help of some definitions embedded in the Bitcoin codebase, we will see how the Bitcoin money supply works: 

• 1. COIN is a constant and represents 100,000,000 satoshis (one bitcoin).

1. nSubsidy is the block reward given to miners for mining a block.
2. nfees are the transactions fees associated with a Bitcoin block.

1. nheight is the number of blocks that have been mined up to this point.

1. SubsidyHalvingInterval is a constant: 210,000. The Bitcoin reward halves every 210,000 blocks (about four years). 

The code behind the money supply looks like this:

{

nSubsidy = 50 x COIN

halvings = nheight/subsidy halving interval

nSubsidy >>= halvings [>> is a function in C++ that divides by 2]

if (halvings >= 64) return nFees 

return nSubsidy + nFees

}

In English this means

The base block reward is 50 BTC.

We then calculate how many halvings we have had by referencing the current block height and the subsidy halving interval. We are currently at block 584,877/210,000 = 2 halvenings

The code >>= is known as the binary right shift operator. It simply divides by two for each halving calculated above. In our example, it would be 50 ÷ 4 = 12.5 BTC—the current block reward in 2019.

Once we go past 64 halvings, the block reward becomes zero, and the miner only gets fees.

Otherwise, Bitcoin rewards the miner with the subsidy in 3 and the fees.

Even if you are not computer literate, if you spend a few minutes with the code and definitions above, you will understand it. The entire Bitcoin money supply is defined in five lines of code. Even better, check the code yourself; it is public. Click the link and search for ‘nSubsidy = 50 x COIN’:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp

This system stands in stark contrast to central banking, which is so complex that hardly anyone understands it. It is impossible to verify the money supply of EUR, USD, or any other major currency. In Bitcoin, the money supply is simple and known, and you can check it yourself.

The code defines the money supply. It starts with 50 bitcoins and grows by 50 bitcoins every ten minutes. After four years, this cycle drops to 25 bitcoins every ten minutes. In 2019, it is 12.5 bitcoins every ten minutes. By 2030, 99% of all bitcoins will be mined. By that point, inflation will be incredibly low at around 0.1% per annum.

Instead of a central bank controlling the money supply through the banking system, Bitcoin’s money supply is administered through the Coinbase transactions contained in each block. These Coinbase transactions are defined by the code in section 2 above.

Every block mined in the blockchain has a Coinbase transaction as its first transaction. These transactions contain the payment to the miner that mined that particular block and are comprised of

The Block Reward: The block reward is a newly minted amount of bitcoin algorithmically determined by the code above whereby the number of blocks already mined determines the amount to mint and then reward to the miner.

Transaction Fees: The miner also collects the transactions fees of the transactions they have selected for inclusion in the block—generally the transactions with the highest fees first.

The genesis block—or Block 1—was the first block mined into the blockchain. Its initial block reward of 50 BTC was paid via a Coinbase transaction to one of Satoshi’s addresses, minting the first 50 bitcoin in existence. There were no transactions beyond this Coinbase transaction because they were no other bitcoins in existence; thus, there were no transaction fees. 

There is a huge incentive for miners to participate here—they receive a major portion of the currency base for minimal work.

Block 170 is a significant block because it contained the first transaction in the protocol that wasn’t a Coinbase transaction. It was also the first time the Coinbase transaction contained more than just the block reward; miners were paid a minimal fee for the single peer-to-peer transaction that was included in the block.

This process continues with each block containing the 50 BTC reward and then all the transactions in the block.

Over time, transaction fees have risen as a percentage of the overall reward. By 2040, they will represent the entire reward.

In part 1, we noted that miners must create a candidate block for submission to the network with the following components:

1. Software version number 
2. Previous block’s hash
3. Merkle root of the selected transactions (a hash of the root of the transactions selected for the block)
4. Timestamp (seconds from the Unix epoch)
5. Difficulty target (proof-of-work difficulty target for this block)
6. Nonce
7. With the Merkle root, the miner must summarise all the transactions the miner is looking to mine. The Coinbase transaction is always the first transaction in the Merkle tree. If the miner is successful, he will publish his block containing all this data to the network.Upon publishing a block, the rest of the network checks the transactions, including the Coinbase transaction, to make sure they are valid and comply with the rules. Specifically, the functions in the codebase are ‘CheckBlock’ and ‘CheckBlockHeader’.

Let’s look at a recent example of what happens when a miner tries to cheat. 

On 10 July 2019 at block height 584,801, a miner tried to award himself 13.26 BTC, not 12.5 BTC, and our node at ListedReserve rejected the block (as did all others did across the world). See the error message ‘Coinbase pays too much’ in the image below. The miner.

This action is distributed consensus in action—everyone is monitoring the blockchain with a node. When someone breaks the rules of the protocol, it is obvious. Their block becomes invalid, and they lose the reward. In this case, the miner lost USD 150,000-worth of Bitcoin by trying to cheat.* 

Cheating hardly ever happens because nobody wants to risk throwing away the block reward and fees.

* What happened in this case was that the block was not perfectly formed. The 13.26 BTC was 12.5 BTC plus the fees from the transactions. This reward correct, but the miner forgot to include the transactions generating the fees in the Merkle tree. Therefore, the block was rejected.

The basis of Bitcoin’s transactions is the system of inputs and outputs. There are no accounts or balances in Bitcoin; there are only unspent transaction outputs (UTXOs). Anytime an address is credited with owning bitcoin, the balance simply refers to the amount of UTXOs that belong to that particular address. 

Here’s how it works:

Imagine the first-ever transaction that was mined. 50 BTC, a Coinbase transaction, now belongs to Satoshi. Let’s call it UTXO1. UTXO1 is not a balance. It is a transaction containing 50 BTC. Satoshi sends 30 BTC to his friend Hal. This creates

1. UTXO2 belonging to Satoshi with 20 BTC
2. UTXO3 belonging to Hal with 30 BTC

Every transaction creates new UTXOs. These transactions will be mined in the next block, along with a new Coinbase transaction.

Let’s look at another example:

Bob has 3 BTC from a single transaction output. Bob wants to send 1 BTC to James.

Bob must use his entire 3 BTC UTXO as the input (a) for the transaction. The transaction then assigns the output of 1 BTC to James’s address (b) and 2 BTC back to Bob’s address (c). The UTXOs here (shown in the transaction box) are the amounts ‘sent’ to each address by the transaction. Bob now has a single UTXO of 2 BTC, while James has a single UTXO of 1 BTC. 

This arrangement is the most abstract part of the UTXO system. When you make a transaction, you are utilising the entire amount or your UTXO (you can’t split it), and the ‘change’ you get from the transaction goes to a new UTXO.

With UTXOs constantly being split, merged and manipulated to match the requirements of new transaction inputs, it may seem as though this system is excessively complex. However, Bitcoin wallets do all this work for us. Users simply see the sum of all their UTXOs in their wallets and assume they are seeing a balance when what they are seeing is a summation of transaction outputs. 

The amount of bitcoins in circulation at any point in time is simply the sum of all UTXOs.

Now we will look at how you keep your UTXOs (your bitcoins) secure. All the tools we need to do so have been covered in part 1. Note that a public key is not a Bitcoin address, and a Bitcoin address is not a UTXO. They are all distinct.

The Private Key (k)

Private keys are your keys to the Bitcoin kingdom. In Bitcoin, private keys are identified by a lowercase k. They protect your UTXO. Never, ever share them with anybody else under any circumstances. 

Private keys must be generated randomly. They simply need to be any 256-bit number that no one could guess between 1 and 2256, which as we know, is a very large number. One way to create this key is with a pen and paper (so it never touches the internet) and two dice:

1. Roll the dice.
2. If you roll nine or less, write down the number.
3. If you roll ten, write down the number zero.
4. If you roll 11 or higher, write nothing.
5. Repeat xx times
6. When you have your number, convert it to hexadecimal format (64 characters long).
7. Using this method, I got this number:4513148943280021525786150910166722441228176762109154710063663433725396433285157392663997834610926074484660258157237415508698774818957707828892086118849186472754206954720476631222331734190315137861508439738788940720541557273269869330813342837340088683866886I then converted it to this 64-character hexadecimal number:KzjsSVNiPGrvHUr5nYVDv5CKHnpQWUFXA9By5WyUHaYezHdSuyhHThis your private key. Public Key (K)

   Recall cryptography from part 1:

8. 
9. We used a common generator in our modular maths: the number 3. This system allowed both sides to generate the secret without knowing the other person’s private number.In Bitcoin, the common generator is larger. It is a pre-defined point on the elliptic curve above, and for completeness, it is known as G and looks like this:02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798It is always the same, and everyone in Bitcoin uses it. It is just a common point on the elliptic curve. To generate your public key (K), we now generate another point on the elliptic curve by multiplying k by G.

If I do that with the above, I get the following public key:

04DF517FF28B2E619A5D44363B913810FA82ED1A688295D3B8B5E371E25B240F47300B438FA8E0A59D66E9CFB23DDE492CD2B23FCD512F84ED840D8B11C08B742C

Bitcoin Addresses

The final part of the sequence is Bitcoin addresses. Addresses are hashed public keys and are just a fail-safe step to protect coins further. Bitcoin works with public keys as addresses, but these hashes move the reliance away from the elliptic curve alone. 

Addresses are generated as follows:

1. The protocol takes my public key K and applies the SHA-256 hash (see part 1). 
2. The protocol applies a further hash known as RIPEMD160, which generates shorter results than SHA, so they’re easier to use. 
3. I receive a Bitcoin address that looks like this: 15yzoTvTKNcDcHUGf76ENKtgk1UzJCfETy

Note how this is address shorter than what would be produced if we just used the public key. That’s the only reason its hashed, and it’s only hashed twice due to paranoia.

 The RIPE hash is used to keep they length of private keys down. Bitcoin would have worked by just using the RIPE hash alone and not the SHA hash first, but the creators were slightly worried because there is a relationship between the elliptic curve and RIPEMD160. While nobody knows if that relationship is useful or if they can prove anything meaningful with it, the Bitcoin creators didn’t want to run the risk, and a simple solution was to apply SHA-256 first and break the suspected link between RIPE and ECC.

This step proves something: Bitcoin was written by people who didn’t have all the answers. They knew there might be a slight weakness here in future (and I mean slight and the distant future), and they papered over it with a hash we probably don’t need, just in case.

We have not covered how these keys actually protect your UTXOs. 

Recall that UTXOs have two parts:

1. An amount of bitcoin denominated in satoshis
2. A locking script known as an encumbrance (specifies the conditions that need to be met to spend this coin)

In most cases, the locking script locks the output to a specific Bitcoin address. To unlock this script, you must have the private key. 

As we have seen from the power of elliptic curve cryptography, nobody can compute your private key from your public key; nobody can ever guess it. In essence, that is the real power behind Bitcoin: property rights secured by mathematics, not by a social contract.

In part 3, we will cover an economic argument for Bitcoin:

1. Scarcity and stock-to-flow ratios
2. Central bank policy since 2008
3. Government deficits
4. The bond market
5. Demography and its impact on digital adoption
6. The retirement crisis
7. Negative interest rates