If you’re coming through without having read part 1, welcome! Part 2 may or may not make a whole lot of sense without that, so give that a gander if you need a refresher. And here’s the paper itself, if you’d like to follow along.
Key terms: mining, transaction fee, inflation-free, honesty incentive
Each block gets ‘mined‘ by the network of nodes who compete to be the first to find the next value that hashes to a nonce. Why do these miners nodes show up to work, contributing electricity and processing power? Because they’re getting paid! The first transaction in every block mints new bitcoins (currently 12.5 per block), and sends it to the miner who solved the nonce and mined the block, until the last bitcoin is mined. The bitcoin code is written such that there will never be more than 21 million bitcoins. Even if they get lost. Therefore, the system is inflation-free after 21 million bitcoins are minted, though it’s debated whether being inflation-free is actually important for a cryptocurrency.
The miner of the block also collects a small percentage of each transaction, a transaction fee. This is, in fact, additional incentive against would-be attackers. If by some chance, an attacker were to gain a majority of CPU power on the network, he/she would face a decision: whether to make payments, then immediately steal them back by publishing the latest block without his/her payments, or to play by the rules and generate new coins for himself/herself by mining each new block.
Interlude: Some Real Numbers
At time of writing (September 2018), 144 blocks are mined every day, with 12.5 bitcoins mined per block, with the price of BTC at $6400, so the majority CPU miner would make 12.5*144*6400=$11.52 million in an honest day. Or, he/she could steal back his transactions, which would undermine the validity of the system, and the value of the attackers’ own bitcoin stash.
It should be mentioned that the current figure for annual energy consumed by the Bitcoin network is 73.12 TWh (“terra-Watt-hours”), which is about the annual electricity consumption of Austria. An attacker group would require half of that to attack the network.
Reclaiming Disk Space
Key terms: Merkle Tree, Blockchain growth rate versus storage growth rate
One question that may be posed: If every node stores a full copy of the blockchain, including all the transactions in every block from now until the end of time, wouldn’t that take a great deal of space? You’re damn right, now get all these blocks off my yard.
Actually, we don’t need to store every transaction, only those made in recent blocks (recent being around 6 blocks). The rest of the blockchain is stored in a Merkle Tree. A Merkle tree is a tree where the leaves of the tree are individual data, whose parents are the hashes of those leaves. In this case, the data are transactions. Each parent is a hash of two (or more) child nodes. The root hash is then a hash of a pair of hashes, which are in turn, hashes of yet more hashes. Lost? look two inches down.What all this means for storage is that we only need to store a few things in each block: the previous hash, the nonce, and the root hash, which sums to about 80 bytes per block. Blocks generate every 10 minutes.
(80 bytes/block)(1 block/10 minutes)(6 blocks/hr)(24 hrs/day)(365 days/year) = 4.2*10^6 bytes/year = 4.2MB per year. Satoshi notes that with Moore’s law predicting current storage growth rate at 1.2GB year, quite a bit more than enough to outpace the blockchain.
Simplified Payment Verification
Key terms: partial/lightweight node
Even so, a blockchain user may want to interact with the blockchain without running a full Blockchain node. An example of this could be a user with a bitcoin spending app on their phone, wanting to conduct a transaction, while storing as little as possible on their phone.
Such a user may instead opt to keep a partial node, storing only a copy of block headers in the longest chain. To verify a given transaction, the user’s partial node will query other nodes with the transaction’s timestamp. The network’s nodes will share the transactions’s location in the blockchain, confirming the network has accepted the partial node’s transaction, or that the transaction has not yet been mined to a block.
Querying the Blockchain about a transaction
To protect against attackers, a partial node implementation would improve its security by storing a full copy of the most recent blocks, or by retrieving a full copy if querying full-nodes results in discrepancies, signaling a possible attack.
Combining and Splitting Value
Key concept: Transaction elements
Each transaction contains both inputs and outputs. A would-be spender must inform the network of the locations of previous transactions ending in their address. Network nodes check those locations to see if the sender has sufficient bitcoin to satisfy the new transaction.
The amount of Bitcoin received in prior transactions will exceed the amount being spent, so the new transaction will send two amounts, one to the recipient, and the rest to send back to themselves.
Key Terms: Two models of privacy, addresses (same as Public Keys)
Traditional banking privacy limits information between parties and the public, but not to the trusted party (the bank).
The blockchain model, on face value, removes anonymity between parties, by publicly announcing transactions between addresses. However, new addresses are easily generated:
An address is 26-34 characters in length, with 58 possible characters in each position. There are then roughly 9.2E59 possible addresses.
Each address is anonymously held, though if anonymity between parties is broken, a new address can easily be used for all future transactions by any given party. If the highest possible privacy is desired, a user may avoid ever reusing any address.
While I intend to convey the contents of the paper with clarity, I encourage you to see the calculations of the original paper if they interest you, in which Satoshi Nakamoto describes the probability that an attacker succeeds in generating a chain faster than the honest chain.
Any attempt at summary of the original passage would do the the clarity of Nakamoto’s writing a disservice. Ergo, I quote:
We have proposed a system for electronic transactions without relying on trust. We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending. To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.
A Conclusion of My Own
This is the end of my first white paper review. My intended purpose here was to educate myself, and present an entry-point for others to follow. While I enjoy writing summaries such as these, I want to improve my writing for my audience as best as possible. Comments and suggestions will earn you the illustrious title of FEEDBACK HERO among my readers. Just kidding, I don’t know if I can actually tag people like that, but if I can, I will. Additionally, if you enjoyed my post or found it illuminating, I’d appreciate it if you shared the post with your friends. I can’t imagine a better reward than inspiring and educating my as many people as I can.
In any case, thanks for reading.