The Bitcoin whitepaper is a nine-page document titled “Bitcoin: A Peer-to-Peer Electronic Cash System”, published on October 31, 2008 by a person or group using the name Satoshi Nakamoto. In twelve short sections it describes how digital money can work without a bank: an open network of computers puts all payments into a fixed order, and computing work ensures that nobody can falsify that order after the fact. Every single bitcoin you buy, hold or send today still rests on these nine pages.
On October 31, 2026, the paper turned 18. Anyone who holds bitcoin today essentially owns what Satoshi sketched out back then: an entry in a public ledger that can only be spent by whoever holds the matching private key. This article goes through the whitepaper section by section, explains the technical terms in plain language and shows what still applies in exactly the same way in 2026 and what was only added later.
What is the Bitcoin whitepaper? Nine pages from October 31, 2008
A whitepaper is a technical position paper that presents an idea before a finished product exists. Satoshi Nakamoto announced the Bitcoin whitepaper in a short post on the Cryptography mailing list, a distribution list for cryptographers, computer scientists and privacy advocates. The first sentence of the message reads: “I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party.”
Peer-to-peer means that participants are connected directly to each other and no central server controls the network. The file itself was hosted at bitcoin.org then, as it is now. The document runs to nine pages, structured into an abstract, twelve numbered sections and a reference list of eight sources. The only contact given in the paper is an email address at a free webmail provider. Who is behind the name has still not been established; we have collected the known theories and suspects in a separate article on the search for Satoshi Nakamoto.
The timing was no accident of the calendar: it fell in the middle of the financial crisis. A few weeks earlier, the US investment bank Lehman Brothers had collapsed, and governments around the world were propping up their banks. The whitepaper itself does not mention the crisis at all. Its criticism is aimed, soberly, at a payment system that depends on trust in intermediaries.
The structure of the whitepaper at a glance
Section 1, introduction: the problem of trust-based payments on the internet Sections 2 to 4: transactions, timestamp server and proof of work Sections 5 and 6: how the network operates and why participants take part Sections 7 to 9: reclaiming disk space, simplified payment verification, combining and splitting value Sections 10 and 11: privacy and the probability calculations on attacks Section 12: conclusionThe double-spending problem: the gap the whitepaper set out to close
The double-spending problem is the question of how to prevent someone from spending the same digital coin twice. With cash the question does not arise: whoever hands over a banknote no longer has it. A file, by contrast, can be copied at will. Until 2008 the problem was solved with a central authority, usually a bank or payment service, that keeps a ledger and reconciles every payment.
It was precisely this central authority that Satoshi wanted to make redundant. In its introduction, the whitepaper describes the costs of the old model: payments can be reversed, so merchants have to be wary of their customers and ask for more information than necessary, a certain percentage of fraud is accepted as unavoidable, and small payments are barely worthwhile because of fees. What is called for is an electronic payment system based on cryptographic proof instead of trust. Two parties should be able to transact directly with each other without a third party having to approve.
One point matters for understanding: Satoshi was not the first with this idea. The reference list names b-money by Wei Dai from 1998 first, and also Hashcash by Adam Back, a method from 2002 originally designed to curb spam. What was new was the combination: a network without a centre that uses computing work to agree on a shared ledger by itself.
Transactions and digital signatures: how a coin changes hands
Section 2 defines an electronic coin as a chain of digital signatures. A digital signature is mathematical proof that a message comes from the holder of a particular private key, without that key being disclosed. Whoever passes on bitcoin signs a hash of the previous transaction together with the recipient's public key. In this way anyone can trace a coin's history back to its origin.
A hash is a kind of digital fingerprint: a mathematical function turns any data into a short string of fixed length. If even a single character of the data changes, the entire fingerprint changes. The original data cannot be worked out from the fingerprint.
Signatures alone do not solve the problem, however. The recipient can see who a coin belonged to, but not whether the previous owner has already given it to someone else. The whitepaper draws the decisive conclusion from this: all transactions must be publicly announced, and participants need a system to agree on a single valid order. The transaction confirmed first always counts, and any later spending of the same coin is invalid.
For you as an investor, this section contains the most important sentence about ownership: bitcoin belongs to whoever controls the private key. How public and private keys work together is explained in detail in our guide to private keys and public keys.
Each block points to its predecessor: the whitepaper describes this link as a timestamp server.
Timestamp server and proof of work: why computing work secures the order
Section 3 describes a timestamp server. It takes a hash of a bundle of data, a block, and publishes this hash. This proves that the data existed at that point in time. Each new timestamp includes the previous one, so every further block reinforces the ones before it. This very chaining from block to block is what is now called the blockchain.
So that no central server issues these timestamps, section 4 distributes the task through proof of work. Proof of work is a method in which a computer has to make many attempts before it finds a hash with a particular property, while checking the result takes a single computational step. The whitepaper cites the SHA-256 hash function as an example: the hash sought must begin with a certain number of zero bits. To find it, the computer changes a number in the block, the so-called nonce, until the result fits.
Anyone wanting to change an old block would have to redo this work for that block and for all the blocks appended after it, and then overtake the honest participants. The whitepaper puts the core idea as “one-CPU-one-vote”, one vote per processor rather than one vote per IP address, since IP addresses could be obtained cheaply in large numbers. The valid version of the ledger is the longest one, meaning the one with the most computing work invested in it.
The difficulty adjustment was already in the 2008 text
One detail is often overlooked: the whitepaper already provides for the difficulty of the proof of work to adjust. It is based on a moving average targeting a fixed number of blocks per hour. If blocks are found too quickly, difficulty rises. This mechanism explains why bitcoin stays at roughly one block every ten minutes on average, despite ever faster mining hardware.
Network and mining incentive: how new bitcoin come into circulation
Section 5 describes the network's operation in six steps. New transactions are broadcast to all nodes. Each node collects them into a block and works on finding the proof of work for it. Whoever finds it broadcasts the block. The other nodes accept it only if all transactions in it are valid and not already spent, and express their acceptance by working on the next block. A node is a computer that runs the Bitcoin software, checks the rules and relays data.
If two nodes find a block at the same time, two branches briefly emerge. The whitepaper resolves the conflict pragmatically: work continues on the branch received first, and the other is kept in case. As soon as one of the two branches becomes longer, everyone switches to it.
Why should anyone commit computing power and electricity? The answer is in section 6, on incentive. The first transaction in each block creates a new coin owned by the creator of the block. Satoshi compares this to gold miners expending resources to add gold to circulation; with bitcoin, it is CPU time and electricity. On top of that come transaction fees: if a transaction's output value is less than its input value, the difference goes to the miner. Once a “predetermined number” of coins has entered circulation, the incentive is to consist entirely of fees.
The argument about honesty is remarkable. An attacker with more computing power than everyone else would have to weigh up whether to use it to defraud people or to generate new coins. He ought to find it more profitable to play by the rules than to undermine the system and with it the value of his own wealth. This idea gave rise to the mining industry, which today runs data centres full of specialised machines. If you want to join the network yourself without mining, you can run your own node; what that costs in electricity is set out in our guide Running a Bitcoin node.
Merkle tree and SPV: how bitcoin was meant to manage with 80 bytes per block
Section 7 deals with disk space. To stop the volume of data growing without limit, the transactions in a block are bundled in a Merkle tree. A Merkle tree is a structure of hashes in which pairs of values are combined into a new one until a single root hash remains at the end. Only this root hash sits in the block header. Old, long-spent transactions can thus be pruned without invalidating the block.
The calculation in the whitepaper is one of the finest passages in the text. A block header without transactions is about 80 bytes. With one block every ten minutes, that comes to 80 bytes times 6 times 24 times 365, or 4.2 megabytes per year. Satoshi points out that computers in 2008 typically shipped with 2 gigabytes of RAM and that Moore's law predicted growth of 1.2 gigabytes per year. Storage would therefore not be a problem even if all block headers had to be kept in memory. For the block headers that still holds true today. The full blockchain with all transactions, on the other hand, has grown many times over, because pruning old data is hardly used in practice.
Simplified payment verification: the forerunner of the mobile wallet
Section 8 describes simplified payment verification, or SPV for short. Anyone who only wants to verify payments does not need a full node. The block headers of the longest chain and the Merkle branch linking a transaction to its block are enough. The user then does not check the transaction personally, but can see that the network has accepted it and that further blocks are being built on top of it.
Satoshi names the weakness openly: this method can be fooled as long as an attacker overpowers the network. Businesses receiving frequent payments would therefore probably want to run their own nodes. Many lightweight wallet apps on smartphones are based on this principle. Choosing a wallet today therefore also means deciding how much verification you do yourself and how much you leave to a server.
Computers in 2008 typically had 2 gigabytes of RAM, enough for all block headers, Satoshi calculated.
Splitting amounts and privacy: pseudonymous keys instead of banking secrecy
Section 9 settles a practical question: how do you pay 0.3 bitcoin if you own a coin worth 0.5 bitcoin? Transactions therefore have multiple inputs and outputs. Normally there is either a single input from a larger previous transaction or several smaller ones combined, and at most two outputs: one for the payment and one for the change, which goes back to the sender. Today this is called the UTXO model, after unspent transaction outputs.
Section 10 covers privacy. In the banking model it is preserved because only the parties involved and the bank see the data. Bitcoin makes all transactions public and therefore has to create protection differently: the public keys are anonymous. Everyone can see that someone is sending an amount to someone else, but not who the parties are. Satoshi compares this to the stock exchange, which publishes the time and size of every trade but not the names of the parties.
As an additional firewall, the whitepaper recommends using a new key pair for each transaction. But it concedes that transactions with multiple inputs reveal that those inputs belong to the same owner. If the owner of a key becomes known, further transactions can be linked to them. That is everyday reality in 2026: anyone who buys bitcoin on a regulated exchange with identity checks, as the providers in our buy bitcoin comparison require, is linked to their addresses for the exchange and, through reporting obligations, for the authorities too. Pseudonymous therefore does not mean anonymous.
Probability calculations in section 11: how unlikely an attack becomes
The mathematically most demanding part of the whitepaper is section 11. It plays through how an attacker tries to build an alternative version of the blockchain faster than the honest participants. Even a successful attack does not allow arbitrary changes: the attacker can neither create value out of thin air nor take money that never belonged to him. He can only try to take back a payment he recently made himself.
Satoshi describes the race as a so-called gambler's ruin problem, the probability that a player ever makes up a deficit. If the attacker is behind and has less computing power than the honest nodes, his chance falls exponentially with each additional block. The whitepaper includes a short calculation in the C programming language and a table of results.
The table from the whitepaper: confirmations against hashrate share
The table shows how many blocks a recipient has to wait for the attacker's chance of success to fall below 0.1 percent. The value q stands for the attacker's share of the network's computing power, z for the number of blocks added since the payment.
| 10 percent | 5 |
| 15 percent | 8 |
| 20 percent | 11 |
| 25 percent | 15 |
| 30 percent | 24 |
| 35 percent | 41 |
| 40 percent | 89 |
| 45 percent | 340 |
This explains a practice you will know from exchanges: a bitcoin deposit is only credited after several confirmations. With a 10 percent share of computing power, an attacker would, according to the whitepaper, have only a chance of just over 0.09 percent after five blocks. But the table also shows the model's limit: as the attacker approaches half of the computing power, the number of confirmations needed rises steeply. Beyond half, in the so-called 51 percent attack, the calculation no longer applies.
What is not in the Bitcoin whitepaper: 21 million, the halving and the word blockchain
Many features now considered core to bitcoin are nowhere to be found in the whitepaper. The word “blockchain” does not appear in the text. Instead, Satoshi describes blocks linked together by their hashes and declares the longest sequence of such blocks to be the valid version. The compound word only caught on later.
The cap of 21 million bitcoin is also missing. The whitepaper only speaks of a “predetermined number” of coins. Satoshi gave the specific figure on January 8, 2009, in the announcement of the first software version on the same mailing list: total circulation would be 21,000,000 coins, and the amount per block would be halved every four years. This halving is known as the halving. Since the most recent halving in April 2024, miners have received 3.125 bitcoin per block; our halving countdown shows when the next one is due.
Later extensions such as Segregated Witness, Taproot or the Lightning Network for fast small payments are not in the text either. These extensions build on the rules of 2008 but do not change the basic idea. If you want to understand what makes bitcoin an investment today, an overview of what bitcoin is covers supply, mining and custody in figures.
From whitepaper to network: the genesis block and first software in January 2009
A good two months passed between the paper and a running system. On January 3, 2009, the genesis block was created, the first block of the Bitcoin blockchain. It contains a headline from the British newspaper The Times of the same day: “Chancellor on brink of second bailout for banks”. The line is regarded as proof that the block was not created before that date and is often read as a comment on the banking crisis. Because of a quirk in the code, the 50 bitcoin from this first block cannot be spent.
On January 8, 2009, Satoshi announced Bitcoin v0.1 on the mailing list, the first version of the software for Windows. The same message stated that the software ran only on Windows for now and that the C++ source code was included. Bitcoin was thus open source, and anyone could check the rules from the whitepaper in the program. From then on the network ran, and it has been producing block after block ever since, according to the same basic rules set out on those nine pages.
Reading the Bitcoin whitepaper: the original and the German translation
The original is in English and easy to read once you know the technical terms. If you would rather read it in German, there is a German translation on bitcoin.org under the title “Bitcoin: Ein elektronisches Peer-to-Peer-Cash-System”. The translation runs to eleven pages and follows the structure of the original. A short glossary is worth having for the reading:
Double spending: spending the same coin twice Proof of work: proof through computational effort Node: a computer running the Bitcoin software Timestamp server: a server that proves the order of events Merkle tree: a tree of hashes for space-saving storage Simplified payment verification: checking payments without a full node Trusted third party: an intermediary such as a bankOur advice for a first read: start with the abstract and sections 1, 2, 4 and 12. These four parts contain the whole idea in just over three pages. You can skip section 11 if the mathematics does not interest you; the table above summarises the result.
Bitcoin whitepaper: after 18 years, the core idea still carries the network
The whitepaper makes no promise of value and names no price. It describes a payment system in which ownership depends on a key and not on a bank. Anyone deriving something from it for their own investments arrives at three steps:
Understand a wallet: before you buy bitcoin, it is worth looking at how a wallet manages your keys. Our software wallet comparison gives an overview of apps and programs. Hold the key yourself: the whitepaper's idea of not having to trust a third party is implemented most consistently through self-custody. Our hardware wallet comparison shows which devices are suitable. Choose a verified way to buy: in Germany, getting started usually means an exchange, a broker or a banking app. You can compare fees, licensing and withdrawal to your own wallet in our guide to buying bitcoin.(As of November 3, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)
Bengali (Bangladesh) · 
English (United States) ·