The Bitcoin Whitepaper

(This is a ChatGPT supported translation of a text I wrote last year https://www.dhirubhai.net/pulse/das-bitcoin-whitepaper-dr-ing-wolfgang-lohmann-f54he/).

October 31 marks the anniversary of the publication of the Bitcoin Whitepaper [1] by Satoshi Nakamoto on the Cryptography Mailing List. This occasion provides an opportunity for a brief, simplified look at the Whitepaper from my perspective.

The topic holds significant importance for Cypherpunks. If Nakamoto was one of them, he would probably have released the Whitepaper on the Cypherpunk Mailing List first. Bitcoin is often presented as a response to the bankruptcy of Lehman Brothers or the financial crisis. Interestingly, Nakamoto wrote in 2008 that he had already been working on this project the year before [2].

Title. Bitcoin is often advertised as "digital gold." The limitation to 21 million Bitcoin is certainly an essential feature. However, Nakamoto barely addresses this in his Whitepaper. Instead, he clearly describes Bitcoin in the title as a system for electronic cash for direct exchange. Cash has particular properties that many people may not be aware of in comparison to our everyday payments.

Motivation. Nakamoto explains that online transactions currently rely on financial institutions to act as intermediaries, securing, potentially reversing, or mediating conflicts in the payment process. Merchants must bear the costs for these processes. In physical retail, these costs can be avoided by using cash. In the Whitepaper, Nakamoto describes how electronic cash can achieve similar properties, including the instant payment for a coffee without high fees.

Electronic Coins. This electronic cash has certain similarities to checks, which are barely used today – paper forms used to transfer funds to others. Generally, you fill in an address, amount, and date, sign the check for confirmation, and use it as a payment method. Nakamoto defines an electronic coin as a chain of digital signatures, meaning each coin carries its transaction history. This traceability is an undesirable feature for Cypherpunks. Coins can represent values from 1 Satoshi up to slightly less than 21 million Bitcoin – and can even include arbitrary additional data.

Private Keys Bitcoin provides digital signing procedures – but no encryption. Typically, the owner signs a transaction with a private key. Although a transaction could be technically signed with a stolen key, such signatures are generally not legally valid. Electronic signatures require an identity for larger values, which can be managed through certification authorities, as seen in [3]. Nakamoto considers identity in the design but protects privacy with a firewall.

It’s only partly true that private keys control Bitcoin. Transactions are actually controlled by programs attached to the respective coins. Most of these programs are simple, merely verifying the signature using the corresponding key. However, there are also options allowing anyone to spend a coin, like a signed check without a designated recipient. Furthermore, an almost endless variety of transaction forms is possible.

Timestamp. Nakamoto envisioned making each transaction public to prevent an electronic coin from being duplicated and spent twice. The first seen version of the transaction is considered valid. Transactions are collected in data blocks. Interestingly, the Whitepaper doesn’t specify a size limit for these blocks. Blocks are timestamped, organizing them along a timeline.

Proof-of-Work. The blocks are linked through digital fingerprints (hashes). Changing the past would require recalculating the hashes of all subsequent blocks, which becomes unfeasible due to the costly conditions of the calculation. This resistance to change is essential for a reliable bookkeeping system that documents under what conditions coins can be spent. However, it’s a misconception that stolen coins, for instance, cannot be frozen or their value rebooked. Technically, it’s straightforward and likely to happen in the future.

Nodes. Nakamoto describes the tasks of nodes, which enforce Bitcoin’s rules. Since the primary task is to broadcast new transactions to all nodes, Bitcoin allows for fast payments in regular and interactive transactions. The transaction can be considered complete once visible on the network. For larger amounts, it’s advisable to wait for one or more confirmations from other nodes. New blocks must also be forwarded immediately. This can detect and reject hidden block creation in the case of 50% attacks, as honest nodes only work on honestly generated chains. Interestingly, Nakamoto uses the word “honest” 16 times in the 8-page document.

Incentive. The newly generated Bitcoin per block is termed by Nakamoto as an incentive, which later can also be filled by transaction fees. Together with the Proof-of-Work mechanism, this economic incentive makes following the rules more profitable than attacking the network.

Merkle Trees. It’s less known that transactions within blocks are stored in a special hierarchical structure built with hash values, rather than in a list. This structure allows for efficient management of immense amounts of transactions per block: while 255 transactions require a path (Merkle path) of 8 steps, 16 steps suffice for 65,535 transactions, and 24 steps for over 16.7 million transactions.

The hashes are reflected in the block header. This allows the removal of old transactions from the blockchain later and is essential for scaling.

Simplified Payment Verification. With billions of transactions in blocks, searching for a specific payment within the blockchain becomes impractical. Nakamoto describes how users can verify such transactions. They only need the list of all block headers (80 bytes, 4MB/year). When Alice makes a payment to Bob, she provides the relevant transaction along with its Merkle path. Bob can reproduce the resulting hash of the block header and compare it with his list of block headers. The nodes have already confirmed validity by consensus. For large values in recent blocks, waiting for a few confirmations is still advisable. For large sums, our legal system, not just a waiting period, provides additional protection. For example, the buyer’s identity is known in a car purchase, and in court, they could prove payment if necessary.

For small amounts (cents), an additional step is possible. Alice can create a new transaction based on coins from confirmed transactions and give these, along with hash paths to the coins, directly to Bob (peer-to-peer). This enables instant, highly scalable payments. Of course, Bob should still register the received transaction quickly in the network. There’s a residual risk, but the effort for double-spending in microtransactions is rarely worth it.

Scaling. Bitcoin can scale in principle. In the initial discussions with Donald in 2008 [4] and later with Hearn in 2009 [5], Nakamoto emphasized that Bitcoin would never hit a scaling limit. He compares it with VISA and predicted that nodes would later become companies with server farms. The design enables users to remain simply users [4,6]. Decentralization is not a goal in the Whitepaper.

Forks = Variants. Much like the Bible, Nakamoto’s work has different interpretations that led to forks. The view on Bitcoin has evolved over the years, and developers have gradually introduced changes. In 2017, SegWit (similar to separating a signature from a check) was introduced as a basis for scaling on side chains, resulting in such a profound change that some Bitcoiners resisted this change. Even software-compatible changes alter the rules. However, many still view the SegWit version (BTC) as Bitcoin. Temporarily, BCH, and later BSV emerged from refusal to protocol changes.

Different versions of Bitcoin represent different philosophies. BTC focuses on separate scaling, privacy, independence from the state, "decentralization," "digital gold," and introduces features like Taproot, MAST, viewing Bitcoin as a settlement system, creating a market for block space.

BitcoinSV (Satoshi Vision), on the other hand, reverted previous changes, restored deactivated OP Codes, adheres to "SetInStone," seeks rule conformity, and creates a market for transactions to cover costs through volume rather than amount. The data (Bit) aspect of Bitcoin is also increasingly valued.

Smart Contracts. It’s a myth that Bitcoin lacks smart contracts or that they were deliberately designed to be weak. Nakamoto equipped Bitcoin with a Forth-like machine language with all necessary elements: arithmetic operators, bitwise logical operators, control flow operators, stack management, constants. OP_PUSHDATA4, for instance, allowed data up to 4GB. These programs are directly linked to the coins. Each input and output program’s size can be represented by an 8-byte number (> ~18 million TB). Contrary to popular belief, all required calculations are possible. BTC’s Taproot, MAST, as well as ring signatures, zero-knowledge proofs, Rule 110, and more have been demonstrated in BSV with the original OP codes.

Nakamoto justified the complexity of the language as the only way to enable future, unknown transaction types without altering Bitcoin’s design, as it was set in stone with v0.1. [7]

Applications. Bitcoin is too often reduced to digital gold. However, it can make payments significantly more efficient. The data (Bit) aspect and its possibilities remain underappreciated. Depending on the version, applications already exist that would not be efficient and secure without Bitcoin:

Tamper-proof supply chains, timestamping data, intrusion detection for networks, NFT invoicing, online trading card games, data integrity assurance, triple entry accounting, music streaming, and much more.

For me as a user, it’s beneficial to see various approaches in development. Regardless of the version you prefer, the development has only just begun.

Disclaimer: My preference is BSV due to its logic, simplicity, and personal benefits. I own some BSV, a small amount of BCH, and a fraction of BTC. This article is not an investment recommendation.

[1] Satoshi Nakamoto, Bitcoin - A Peer-to-Peer Electronic Cash System, 31.10.2008, https://www.bitcoin.com/satoshi-archive/emails/cryptography/1/

[2] Bitcoin P2P e-cash paper, 17.11.2008, https://satoshi.nakamotoinstitute.org/emails/cryptography/15/

[3] UNCITRAL Model Law on Electronic Signatures, 2001, https://uncitral.un.org/en/texts/ecommerce/modellaw/electronic_signatures

[4] "Answer to James A Donald 3.11. 2008, https://www.bitcoin.com/satoshi-archive/emails/cryptography/2/

[5] Re: Soft block size limit reached, action required by YOU, 7.3. 2013,

https://bitcointalk.org/index.php?topic=149668.msg1596879#msg1596879,

[6] Re: Scalability and transaction rate, 29.7.2010, https://satoshi.nakamotoinstitute.org/posts/bitcointalk/287/

[7] Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG, 17.6.2010, https://satoshi.nakamotoinstitute.org/posts/bitcointalk/126/