Examining the Bitcoin Whitepaper - Part 2/3
A post to understand key concepts behind the famous Bitcoin whitepaper. Part 2/3
What’s this post about?
This is a three part post where I explain concepts included in the famous white-paper that are not introduced nor described beforehand, and are important to have a better grasp of the problems tackled by Bitcoin. They are divided into the same sections of the paper.
This is not a one-stop-shop for Bitcoin or crypto, but a good catch-most of the under-explained concepts in the original whitepaper. Also, this is not financial advise, nor am I trying to evangelize this to you. :)
How to make the best out of this post
I believe the best way to understand the original paper is to have this post by your side, stop here for the tricky and technological concepts, and return to reading the paper. There is no specific order, and you can skip any section (specially the mathy ones).
This is Part 2. Check Part 1 here, and Part 3 here.
Table of Contents
Network
How does a node realize it missed one block?
In the Bitcoin network, each peer maintains a full copy of the ledger (blockchain).
What would happen if a node lost one of in its blocks in the blockchain (e.g. another process on the peer accidentally wiped out the disk area that stores the block)?
Will this peer be able to detect that this block is missing? If yes, how will the peer detect it and how is it going to repair?
It depends on the implementation. For Bitcoin Core, the node maintains a database which has the locations of all blocks on disk.
If a block is deleted, then it will notice that the location of a block either does not exist or contains garbage or invalid data.
If it does notice that a block is missing (or something is corrupted), it will attempt to rebuild the database using the blocks stored on disk and then download the missing blocks from its peers.
However, blocks can actually be deleted after they have been verified and the local database has updated so that the node knows the block it has just deleted was a valid block.
This is called pruning, and with pruning, old, historical blocks can be deleted as they aren't used for anything in normal node operation (except helping new nodes sync).
Incentive
Because of the decreasing amount of BTC that is paid as a reward (due to the halving), the incentive for nodes to mine also decreases.
To compensate for that, Nakamoto introduces a secondary incentive: transaction fees.
These fees should replace, at some point in the future, the mined block reward.
At the beginning of 2022 block rewards still are greater than transaction fees, so miners still focus on them as their main source of income.
Either the fees need to increase significantly (a problem currently for Ethereum), or the price of BTC itself should climb much higher. These are the only ways in which the transition can occur.
If neither happens, miners will abandon the network, therefore lowering the security of the blockchain and entering a negative feedback loop.
Reclaiming Disk Space
Pruning
Pruning allows a node to free up storage space by removing transactions that are no longer needed to verify that the blockchain is in a consistent state (i.e. no bitcoins were created improperly).
Estimates of needing to store only a portion of data versus the ~500 GB we are approaching reduces the cost required at least for mobile storage by about $10.
As for growth, storage requirements for a pruned node scale more closely with how bitcoins are distributed in the unspent transaction set (a.k.a. UTXO). This means storage will grow O(the number of users) rather than with O(the number of transactions).
At these levels it starts to be practical for a phone or tablet to run a pruned node. This is useful for those that want a greater level of trust with their mobile wallets as well as those who wish to help Bitcoin nodes with bandwidth and connectivity challenges to keep up to date.
This development should help Bitcoin to extend its network reach and improve the trust level possible on commodity phones, tablets, and network equipment, be that mobile or otherwise.
How a UTXO Works
UTXO transactions sound complicated, but they really are fairly simple. UTXO or unspent transaction outputs are used in cryptocurrency transactions.
These are the transactions that are left unspent after someone completes a transaction, similar to the change someone receives after conducting a cash transaction at the store.
Here's how it works. A UTXO database is used to store change from cryptocurrency transactions. This database or ledger is initially set to empty or zero. As transactions occur, the database becomes populated with change records from various transactions.
When a transaction is completed and there are outputs that aren't spent, they are deposited back into a database as inputs that can be used at a later date for a new transaction.
Cryptocurrency transactions —such as those used for bitcoins— are similar to cashier checks. You cannot exchange them for custom amounts and must spend the entire amount stored in that data byte.
But cryptocurrencies like bitcoin are also unique in that transactions can be conducted using fractions of the cryptocurrency. This means spending does not take place using a single data byte.
Instead, multiple fractions of bitcoin are retrieved by the algorithm to fulfill a spending request.
For example, a purchase worth 1 bitcoin may retrieve 0.6 BTC from one byte and 0.4 BTC from another. Change from each of these fractions is then sent to the UTXO database to be spent at a later date.
Simplified Payment Verification
Has the strategy of network node alerts ever worked?
The network wide alert system was created by Satoshi Nakamoto as a means of informing Bitcoin users of any important information regarding Bitcoin.
It has been used in the past to inform users about important network events such as accidental blockchain forks.
However, the alert system also represents a large source of centralization in Bitcoin. The holders of the singular Alert Key can at any time send an alert which could affect the entire network.
As more developers join, the alert key is given to others, but cannot be taken away from those who have left.
This has led to the alert key potentially falling into the hands of malicious actors who could use it to disrupt the network.
Because there is only one alert key, it is not possible to prevent former developers from sending an alert nor is it possible to identify who sent an alert.
In addition, the alert system is primarily Bitcoin Core specific. Many other wallets have their own systems in place but still must have handling for the alert system because it is network wide. Something specific for one software should not be imposed on the entire network.
The alert system has also lost its usefulness. It is no longer necessary to use it to inform users about problematic network events as users can easily get their information from any major Bitcoin news outlet.
Comments
Thank you for your comment! Under review for moderation.