How Bitcoin Achieves Trustless Peer‑to‑Peer Electronic Cash

Abstract

A pure peer‑to‑peer electronic cash system would allow online payments to be sent directly from one party to another without involving financial institutions. Digital signatures provide a partial solution, but if a trusted third party is still required to prevent double‑spending, the main advantage disappears. We propose a method that uses a peer‑to‑peer network to solve the double‑spending problem. The network timestamps transactions by hashing them into a continuously growing proof‑of‑work chain, creating an immutable record. As long as the majority of CPU power is not controlled by an attacker, the longest chain will be generated by honest nodes and will outweigh any attack.

1. Introduction

Online commerce relies almost entirely on financial institutions as trusted third parties to process electronic payments. While this works for most transactions, the trust‑based model has inherent weaknesses: irreversible transactions are impossible because institutions cannot avoid arbitration disputes, which increase costs and limit the size of practical transactions. Trust requirements spread, forcing merchants to collect more information from customers and making fraud seem inevitable. Physical cash can avoid these costs in face‑to‑face transactions, but no mechanism exists for secure payments over communication channels without a trusted party.

What is needed is an electronic payment system based on cryptographic proof rather than trust, allowing any two willing parties to transact directly without a trusted third party.

2. Transactions

We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next owner by signing the hash of the previous transaction together with the public key of the new owner and appending this signature to the chain. The recipient can verify ownership by checking the signatures.

The problem is that a recipient cannot be sure that a previous owner has not double‑spent the same coin. A common solution is to introduce a trusted central authority (a mint) that checks each transaction for double‑spending, but this re‑introduces a single point of failure and the need for every transaction to pass through the authority.

Instead, we require a system where the recipient can be confident that the previous owner has not signed any earlier transaction. The earliest transaction is the most important, so we need a single, universally agreed history of transaction order. This can be achieved without a trusted party by having participants publicly announce transactions and reach consensus on their order.

3. Timestamp Server

Our solution starts with a timestamp server. The server timestamps a block of records by hashing the block and widely publishing the hash (e.g., in a newspaper or Usenet post). Each timestamp includes the previous timestamp’s hash, forming a chain that strengthens earlier timestamps.

4. Proof‑of‑Work

To implement a distributed timestamp server on a peer‑to‑peer basis we use a proof‑of‑work system similar to Adam Back’s Hashcash. Proof‑of‑work requires finding a nonce such that the hash of the block (e.g., using SHA‑256) starts with a required number of zero bits. The expected work grows exponentially with the number of zero bits, but verification requires only a single hash.

For our timestamp network we increment a random number in the block until we find a hash with the required zero bits. Once the CPU effort satisfies the proof‑of‑work, the block cannot be altered without redoing the work. Adding new blocks forces the attacker to redo the work for all subsequent blocks.

Proof‑of‑work also solves the problem of representing voting power in a majority decision. An IP‑based vote can be subverted by a node with many IP addresses, but proof‑of‑work gives each CPU a vote. The longest chain, which has the most accumulated work, represents the majority. If honest nodes control the majority of CPU power, their chain will grow fastest and outpace any attacker.

The difficulty of the proof‑of‑work is adjusted by a moving average of the block generation rate, increasing if blocks are found too quickly.

5. Network

Network operation proceeds as follows:

New transactions are broadcast to all nodes.

Each node collects new transactions into a block.

Each node works to find a difficult proof‑of‑work for its block.

When a node finds a valid proof‑of‑work, it broadcasts the block to all nodes.

Nodes accept a block only if all transactions are valid and unspent.

Nodes create the next block by using the hash of the accepted block as the previous hash, thereby extending the chain.

Nodes always consider the longest chain to be correct and continue extending it. If two different blocks are broadcast simultaneously, some nodes will receive one first and work on it, but they keep the other branch in case it becomes longer. When a longer branch appears, the network switches to it.

Transaction broadcast does not need to reach every node; as long as many nodes receive it, it will quickly be included in a block. Block broadcast can tolerate lost messages; a node that missed a block will request it after receiving a later block.

6. Incentives

The first transaction in each block is a special transaction that creates new coins owned by the block creator. This provides an incentive for nodes to support the network and a way to distribute coins without a central authority. The steady increase of new coins is analogous to gold miners adding gold to circulation; here the resource is CPU time and electricity.

Incentives can also come from transaction fees: if the sum of inputs exceeds the sum of outputs, the difference is a fee added to the block’s reward. Once a fixed supply of coins is reached, incentives can shift entirely to fees, eliminating inflation.

Incentives encourage honest behavior. An attacker with more CPU power than all honest nodes combined must choose between using that power to attack the system or to earn new coins honestly; the latter is more profitable if the protocol rewards honest work.

7. Disk‑Space Reclamation

When a coin’s latest transaction is buried under enough blocks, earlier transaction data can be discarded to save disk space. Transactions are stored in a Merkle tree; only the root is included in the block hash. Old blocks can be compressed by pruning tree branches, as internal hashes need not be stored.

A block header without transactions is about 80 bytes. Assuming one block every ten minutes, this amounts to roughly 4.2 MB per year, which is negligible compared with typical system memory.

8. Simplified Payment Verification

A user can verify a payment without running a full node by keeping only the block‑header chain of the longest proof‑of‑work. The user queries full nodes to obtain a Merkle branch linking the transaction to a block header. Although the user cannot directly check the transaction, the inclusion in a block that the network has accepted provides sufficient confidence.

If honest nodes control the network, verification is reliable; if an attacker controls the network, they could forge transactions, but honest nodes would raise alerts, prompting users to download full blocks for confirmation.

9. Combining and Splitting Value

Handling each satoshi individually would be inefficient, so transactions can have multiple inputs and outputs. Typically a transaction consumes one or more previous outputs and creates up to two new outputs: one for the payment and one for change returned to the sender.

Fan‑out (transactions depending on many prior transactions) is not a problem because a full independent copy of the entire transaction history is never required.

10. Privacy

Traditional banking achieves privacy by limiting information to the participants and trusted third parties. Publicly announcing all transactions removes this model, but privacy can still be preserved by keeping public keys anonymous. Observers can see that a certain amount moved from one address to another, but cannot link the addresses to real identities.

Using a fresh key pair for each transaction further reduces linkability. Multi‑input transactions inevitably reveal that the inputs share an owner, so some correlation is unavoidable.

11. Calculations

We consider an attacker attempting to generate an alternative chain faster than the honest chain. Even if successful, the attacker cannot arbitrarily rewrite history, create value out of thin air, or steal coins that never belonged to them. Honest nodes will never accept invalid transactions or blocks.

The race between honest and attacker chains can be modeled as a biased random walk. The probability that the attacker catches up from a deficit of z blocks is analogous to the gambler’s ruin problem:

p = probability an honest node finds the next block q = probability the attacker finds the next block q_z = probability the attacker catches up from z blocks behind

q_z = 1 if p ≤ q q_z = (q/p)^z if p > q

Since we assume p > q, the probability decreases exponentially with the number of blocks the attacker is behind.

When a recipient receives a transaction, they wait for z additional blocks to be added on top of the block containing the transaction. The expected attacker progress during this waiting period is λ = z·(q/p). The probability that the attacker can still overtake is:

1 – Σ_{k=0}^{z} (λ^k e^{-λ} / k!)·(1 – (q/p)^{(z‑k)})

Implementations of this formula in C show that the probability drops exponentially as z grows, and we can compute the value of z required for the probability to fall below 0.1 %.

Conclusion

We have presented a trust‑less electronic transaction system based on a peer‑to‑peer network and proof‑of‑work. By chaining timestamped blocks, the network creates an immutable public history of transactions. As long as honest nodes control the majority of CPU power, the system is secure, decentralized, and capable of supporting a digital cash system without a central authority.