The Bitcoin White Paper Explained
11.02.2018

Satoshi Nakamoto’s bitcoin white paper “Bitcoin: A Peer-to-Peer Electronic Cash System” was published 10 years ago this week. Since then, countless articles and blog posts have debated Satoshi’s vision, but the text itself has often been overlooked, or even ignored. In celebration of the anniversary, we analyze key sections for the general reader, looking at how Satoshi intended his (or her) ideas to be enacted.

The abstract.

The paper begins: A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution

Breakdown: The first line of the abstract defines the problem that Satoshi hoped to solve. As the e-commerce era flourished, various commentators had speculated about how we could achieve electronic “cash”: a digital asset that could be exchanged directly from one person to another, just like a dollar bill, without needing to pass through an intermediary like a bank or credit card processor.

We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work.

In a nutshell, here is the key problem and a sketch of the solution.

The thing about electronic cash is that digital files are easy to copy. If you send me an MP3 or a JPEG online, you still keep the original file. Clearly this is incompatible with a store of financial value—if you can keep duplicating it, it’s worthless. Hence, the “double-spending problem.”

Generally this is solved by an intermediary like PayPal or VISA to keep track of who owns what, making sure that if you send me $10, that money is no longer in your account. To eliminate the need for this intermediary, transactions have to be broadcast across a peer-to-peer network as a public record, which collectively contains the details of each transaction sent and received. (More on the hashing and proof-of-work part later.)

1. Introduction

Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. … Merchants must be wary of their customers, hassling them for more information than they would otherwise need.

With bitcoin, Satoshi wanted to cut out financial intermediaries but also eliminate the need for personal data to be collected for each transaction. Coming five years before the scale of NSA data collection was revealed by Edward Snowden, this focus on privacy proved prescient.

Satoshi was not a fan of financial institutions. Bitcoin’s genesis block, the beginning of the blockchain, contains the text: “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks,” a reference to the newspaper headline on that day. The reference proves the genesis block was made after that moment, but also comments on the problem of financial institutions imposing a great cost on the people they were supposed to serve.

With bitcoin, Satoshi wanted to cut out financial intermediaries but also eliminate the need for personal data to be collected for each transaction. Coming five years before the scale of NSA data collection was revealed by Edward Snowden, this focus on privacy proved prescient.

What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers.

Cryptographic proofs of trust have long been used to secure and authenticate digital communications over the internet. HTTPS, the secure version of the HTTP web protocol, was released in 1994, and PGP email encryption was developed in 1991.

The idea of making transactions computationally expensive had also been around for a while. Adam Back’s 2002 Hashcash paper, one of eight references cited in the bitcoin white paper, proposed a small computational cost to send certain digital messages, thus preventing denial-of-service attacks and email spam.

2. Transactions

We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.

Money doesn’t have to be a physical object. The number of U.S. dollars that exist as coins or bills is minuscule compared to dollars that exist as entries in the databases of banks or credit card companies. To cut out the banks as an intermediary, Satoshi conceived of a “coin” as a record of ownership history, which could be transferred by adding the new owner’s address to the end. Roughly, you could imagine a $100 bill in an envelope covered with the signatures and street addresses of everyone who had previously spent it being delivered to your mailbox by mail. To spend it, you add your signature, and mail it on.

We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don’t care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions.

Think of the same $100 being sent to you in an envelope, but this time it’s a check, and you don’t know if you have the original or a photocopy. If we make public the serial numbers of every check cashed by everyone across the country, you can search through to make sure no one else spent the same check before you received it.

3. Timestamp Server

The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post.

Hashing data is an extremely useful process for checking the integrity of data. A hashing algorithm takes a variable size of data as an input, and gives a fixed-length output—so the hash of a 5GB movie download is the same size as the hash of a 10kb text file.

The other key property is that changing even the smallest part of the original data gives a completely different hash value output. Taking the SHA256 hashing algorithm used by bitcoin, the word “BREAKER” results in this hash:

1B41EFF7B6A933EE7ED89ECEF78A990002C6394703408D439D35DE326A01576E

And the word “BREAKERS” results in this hash:

FCAE30A377D448F2617A624F6FBFCFBB9754D53B5D657A5D80A7747C0D853296

This means that if the hash of a block of data is published, you can easily confirm that the data has not been changed.

4. Proof-of-Work

To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back’s Hashcash… 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.

Transactions need to be confirmed by the network so everyone can agree on their validity, and no reversing is possible. To do this, data about bitcoin transactions are grouped together into blocks, which form the input to the hashing algorithm. Computers in the network then add a section of junk text to the data until they find a hash value—that long string of numbers and letters—that begins with a certain number of zeroes. This takes a huge number of guesses, but after the hash has has been found, it’s easy for anyone with the input data to check that it is correct.

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.

Here it is: the founding principle of the almighty blockchain.

Part of the input data for each block is a reference to the data in the block that came before. Since a hash algorithm gives a different output if any part of the input data is changed, if you want to alter the transactions in a past block, you then need to recalculate the hash value of every block that came after it, since the first change would alter the data in each successive block. The older the block, the more computing power would be needed to do this, and the less feasible it becomes to change the record.

5. Network

The steps to run the network are as follows:

1) New transactions are broadcast to all nodes.

2) Each node collects new transactions into a block.

3) Each node works on finding a difficult proof-of-work for its block.

4) When a node finds a proof-of-work, it broadcasts the block to all nodes.

5) Nodes accept the block only if all transactions in it are valid and not already spent.

6) Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.

The hard part about running a decentralized network is keeping the nodes in agreement without a controlling authority. Satoshi specifies here that a node can find a proof-of-work, but not the proof-of-work. This is important: Different nodes in the network can and frequently do find a different proof-of-work for a given block, resulting in two competing branches to the blockchain. Other nodes in the network will keep adding blocks to one of the two versions, until eventually one branch pulls ahead and becomes longer. At this point the shorter branch is discarded, and we’re back to one blockchain again.

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.

Part of the genius of bitcoin is that even a purely selfish actor is incentivized to support the network, rather than act against it.

The only way new bitcoins are created is as a reward for finding the hash value of a new block of transactions (beginning with a string of zeroes). This is the principle of mining.

Of course, mining today has expanded to a scale that Satoshi did not foresee, dominated by warehouse-sized industrial operations rather than personal computer hardware. Looking back, professionalized mining was a built-in consequence of a coin creation protocol that rewarded more processing power with more bitcoins. But it would have been hard to anticipate bitcoin reaching the financial value that would make this viable.

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 than everyone else combined, than to undermine the system and the validity of his own wealth.

Part of the genius of bitcoin is that even a purely selfish actor is incentivized to support the network, rather than act against it.

7. Reclaiming Disk Space

Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To facilitate this without breaking the block’s hash, transactions are hashed in a Merkle Tree, with only the root included in the block’s hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored.

Here’s one of the few parts of the white paper that has not been implemented. The fact that it isn’t used is a reminder that the bitcoin white paper was just one person’s theoretical framework: It took a team of developers to write the software that would make bitcoin a reality, and changes were made along the way.

8. Simplified Payment Verification

It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he’s convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it’s timestamped in. He can’t check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.

Satoshi couldn’t guess that this would be the most controversial part of the white paper. ‘Lite’ bitcoin clients like Electron Cash use this technique to operate on the bitcoin network without downloading the full blockchain. But they are disliked by bitcoin developers focused on security, who argue that all bitcoin nodes should be full nodes. On the other hand, lite clients are easier for new users to set up, which helps with bitcoin adoption overall. Each option comes with a trade-off.

9. Combining and Splitting Value

Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.

This part is tricky to grasp. To make up the exact sum of bitcoin transaction, there are two options: either a higher value chunk of bitcoin in your wallet is broken in two, or smaller chunks are combined to make a higher amount, with some change left over.

In a sense it’s like buying something with cash in a store: if you want to buy $13 of groceries, you might give the clerk $10 and three single bills to make the total, or you might hand over a $20 bill and get $7 change. The difference with bitcoin is that your change is always lumped in a single amount, as if it were a $7 bill. So if your regular wallet was like a bitcoin wallet, it would be filled with notes of irregular values—$2.65, $51.03, $0.02, and so on—and you’d have to combine these to buy something, receiving another irregular sum of money in change.

10. Calculations

This section is a lot of math that honestly no one at BREAKER can understand.

12. Conclusion

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.

The network is robust in its unstructured simplicity” is perhaps the most poetic line in the bitcoin white paper, a succinct phrasing of the philosophy that underpins blockchain technology. And so, with just a few thousand words, Satoshi had given birth to the first decentralized cryptocurrency.