the bitcoin whitepaper explained and commented - part 1: introduction

The Bitcoin whitepaper, explained and commented — section 1, introduction Have you ever read Bitcoin’s whitepaper? Is it a bit too technical? In this series, we’ll look at Satoshi Nakamoto’s original whitepaper from 2008, which introduced Bitcoin to the world, and I will comment and explain it section by section, and try to put everything in context. The paragraph in quotes are from the whitepaper itself. Today, we start with… the introduction! Let’s get to it. 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. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for non- reversible services. From the start, we can see that Nakamoto was mostly preoccupied with e-commerce: how to do electronic transactions between two parties? More precisely, he was not satisfied with the current solutions for a few reasons: The reversibility of most transactions : trusted third parties (credit cards companies, banks, Paypal, etc…), who enable payments, are forced to play arbiters between parties when a disagreement arises, and this arbitration increases the cost of all other transactions. This cost, in turn, makes very small transaction impossible: the cost would exceed the value of the transaction itself. Example: sending 10 cents to watch a short clip or read a short newspaper article (instead of having to pay for a monthly subscription). On top of that, some services are simply non-reversible (for example, streaming), and thus should be paid by non-reversible transactions. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party. Nakamoto is linking the reversibility of transactions to the need for merchants to “know their customers”: in other words, because transactions can be reversed, merchants have to collect more information from their customers, invading their privacy. Privacy and irreversibility are thus connected: if payments were truly irreversible, they could occur without revealing any private information. 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. In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes. Here Nakamoto introduces his solution: the trust based on sharing private information with a third party can be replaced with the certainty of mathematical proofs of payment, thus eliminating the need for intermediaries. The non-reversibility of payments will ensure that merchants are protected (buyers can’t cancel their payments), while buyers can be protected through escrow mechanisms (we’ll see later how Bitcoin enables easily such mechanisms, in most cases without the need for a third party to actually intervene). An escrow works by delaying payment until the goods or services have been received by the buyer. The problem that Nakamoto tackles here is not new: several digital currencies have already been invented when the whitepaper is written in 2008. However, these currencies, such as “b-money” (1998) that Nakamoto refers to in the bibliography, had all failed. The main reason was that they were all using a centralized ledger (a record of all transactions) to verify payments,and thus presented a single point of failure: the centralized records could easily be the target of sufficiently organized hackers, or simply break down due to technical issues. Perhaps even more problematic, all participants had to trust the keeper of the ledger. The problem that these centralized ledger were trying to avoid is known as the double-spending problem: if Adam sends a digital payment to Beatrice in exchange for a service, what prevents him to send the same digital payment to Charlie at the same time, thus “double-spending” his money? Depending on which payment is received first, either Beatrice or Charlie would not be paid. That’s why a ledger of all payments is needed: to keep track of which digital coins have already been spent! Nakamoto’s greatest insight is to move this ledger to a peer-to-peer model: there isn’t going to be a centralized ledger anymore, instead everyone on the network will have a copy of the ledger. However, the double-spending problem remains: if two transactions try to spend the same virtual coins, the peers still have to decide which transaction came first (and reject the other one). And deciding which transaction comes first in a distributed system is complicated because of inherent lags: it takes times for messages to travel across the network. Nakamoto’s solution will manage to assign a “timestamp” (a given date and time) to every transaction without using a central third party: all participants can then reach a consensus (a shared history) about the order in which payments are to be treated. Reaching such consensus will require the “proof of work” trick, as we’ll see later. Finally, Nakamoto explains the main assumption required for his solution to work: that “honest” participants control the majority of the network’s computing power. This is the premise of correct behavior in Bitcoin, and we’ll see in the next sections how Nakamoto introduces incentives for participants to behave honestly rather than “count” on their honesty! That’s it for now. In the next installment of this series, we’ll look at the structure of “transactions” with Nakamoto. Hang on!