Solving the Double-Spending Problem in Peer-to-Peer Digital Coin Systems - A Partial Solution to Double Spending
A proposal for a peer-to-peer digital coin system that uses a proof-of-work “block record” (blocks in a chain) to nearly solve double-spending and digital money into the future.
Electronic payment systems historically rely on trusted third-party intermediaries (such as banks or clearinghouses) to prevent double-spending, the act of the same digital token being spent more than once. This trust-based modelintroduces vulnerabilities and costs: buyers and sellers must trust the intermediary, and irreversible payments are impossible because the intermediary can reverse transactions in case of disputes . What is needed instead is a system based on cryptographic proof rather than trust, allowing two parties to transact directly without a central authority . In this paper, we propose a peer-to-peer protocol for digital coins that uses a distributed timestamped block record (a ledger composed of blocks in a chain) to nearly solve the double-spending problem. Each transaction is secured by digital signatures and recorded in a public chain of proof-of-work, forming a block record that is computationally impractical to alter as long as honest nodes control the majority of computing power . This approach eliminates the need for a single mint or clearinghouse: transactions are broadcast to a network of nodes, timestamped into a chain of blocks, and collectively validated by network consensus. The result is an ongoing chain of hash-based proof-of-work that serves as a public ledger of all transactions, with the longest chain (most accumulated work) representing the agreed history .
Double-Spending and Our Contribution: Our protocol builds on decades of research in digital cash and cryptography. We leverage well-known primitives - digital signatures, hash functions, and peer-to-peer networking - and combine them with a novel integration of timestamp servers, proof-of-work (similar to Hashcash), and a public block record ledger structure. In doing so, we create a system where would-be double-spenders face a computationally prohibitive task to overwrite or outpace the honest transaction history. We acknowledge, however, that our approach is not completely foolproof. Certain open issues remain (such as bootstrapping initial coin issuance fairly and the network’s vulnerability to majority attacks in its early stages). Thus, we describe it as a partial solution to double-spending. It significantly raises the bar for fraud, though it does not entirely eliminate all attack vectors.
Context and Motivation: This work is released at a critical time. Signs of instability in the traditional financial system are emerging – notably the U.S. housing market bubble appears on the verge of collapse due to rampant subprime mortgage lending and complex derivative securities built on shaky loans. In fact, by mid-2006 U.S. home prices had peaked and started to decline, with rising interest rates triggering a spike in mortgage defaults . The collapse of the subprime mortgage market in late 2006 set off a chain reaction of financial turmoil spreading to global markets . Major financial institutions realized that their vast portfolios of subprime mortgages and related derivatives were far riskier than assumed, leading to significant losses and a credit crisis . This upheaval has exposed how lax regulation and opaque centralized systems can magnify risks: even federally regulated lenders (e.g. large banks and government-sponsored enterprises) engaged in reckless lending and suffered tremendous losses, showing that existing oversight failed to prevent the crisis . As we write (2006), it is evident that a severe correction is underway – in hindsight, by 2007 the housing bubble would burst and nearly bring down the global financial system . These events underscore the need for open, transparent, and trust-minimized financial infrastructures. A decentralized digital coin system, not dependent on the integrity of any single institution, could provide an alternative resilient medium of exchange if traditional systems falter. Our proposal is motivated by the desire for a trustless electronic currency that cannot be debased by policy or crippled by the failure of intermediaries – a system that empowers individuals to transact securely even in the face of institutional collapse.
Preface Note: Throughout this work, any discussion of potential centralization within a distributed digital coin system is presented strictly as a theoretical consideration rather than an observed outcome, as no large-scale empirical deployment yet exists from which such conclusions could be drawn. Nevertheless, historical patterns in economic and institutional behavior suggest that certain theoretical risks may, under specific conditions, manifest in practice. For this reason, we maintain a cautious analytical posture that treats such possibilities as non-trivial without asserting their inevitability. Similarly, our treatment of privacy concerns is derived almost entirely from earlier cryptographic and economic critiques, particularly those articulated during the Chaum era, which emphasized the long-term risks associated with persistent transactional records and identity correlation. While comprehensive transaction analysis has not yet been demonstrated at scale, it is reasonable to anticipate that sufficiently motivated actors could, over time, attempt to infer behavioral or relational information from publicly available financial records. In this context, broader concerns regarding financial monitoring, systemic observation of transactional flows, and the potential alignment of such systems with evolving regulatory and identity-verification practices must be acknowledged as plausible future developments. The increasing emphasis by global financial institutions on anti-money-laundering and customer identification frameworks suggests a gradual realignment toward enhanced oversight at institutional boundaries, which could, if coupled with publicly verifiable digital ledgers, introduce new tensions between transparency, privacy, and individual autonomy.
Finally, we note that we are not alone in exploring such a system. We are aware of a parallel effort by a certain individual (purportedly representing a consortium with questionable public motivations) developing a similar private e-currency protocol. In the spirit of transparency and open science, we have decided to publish our approach early. By doing so, we hope to encourage open development and peer review of this technology, ensuring it remains a public good rather than a closed tool controlled by a select group. In the sections that follow, we outline related work, then detail our proposed architecture and its security, before discussing remaining challenges and broader implications – including potential misuse of block record systems as tools of surveillance or control if co-opted by powerful actors.
Background: Digital Cash and Distributed Time-Stamps
Research into electronic money dates back at least to the 1980s. In 1985, Chaum introduced the concept of untraceable electronic cash using blind digital signatures to ensure user privacy . Chaum’s system (later implemented as DigiCash) allowed users to withdraw digital “banknotes” from a bank and spend them anonymously, with the bank’s signature guaranteeing validity. However, because digital data can be copied, Chaum’s solution still required an online trusted authority (a bank or mint) to verify each transaction and prevent double-spending by clearing spent tokens . In essence, the bank needed to check every coin spent against a database of spent coins, which reintroduced central trust. This highlights an important principle: to prevent double-spending, one must ensure no single coin gets spent twice – traditionally by having a central ledger or clearinghouse aware of all transactions.
Subsequent proposals sought to eliminate or minimize reliance on centralized clearing. Timestamping of data in a distributed manner emerged as a potential tool. Haber and Stornetta (1991) demonstrated how to timestamp digital documents so that one cannot back-date or forward-date them without detection . Their method linked documents in a cryptographic chain: each timestamp included the previous timestamp’s hash, forming an immutable sequence . This concept of a chained timestamp server – effectively a series of time-ordered records where each record’s hash commits to the previous – is a direct precursor to our block record ledger. Follow-up work improved efficiency and robustness of timestamping services and explored naming data by cryptographic hashes , anticipating key components of modern block chain structures.
In the late 1990s, researchers began to outline how digital money might work in a decentralized setting. Notably, Wei Dai’s b-money proposal (1998) described a scheme for “untraceable digital pseudonyms to pay each other with money and to enforce contracts” without outside help . In b-money’s first protocol, every participant maintains a separate account database of all balances. Money is created by solving computationally expensive puzzles and broadcasting the solutions – effectively using proof-of-work (PoW) as a minting mechanism . For example, solving a cryptographic problem that costs a known amount of computing effort yields a certain number of monetary units, proportional to the resource cost expended . This was a remarkable insight: it tied the value of digital money to objectively measurable computation, much like gold’s value is tied to the effort of mining. However, b-money’s fully distributed mode (where every node keeps the ledger) was deemed impractical due to communication overhead. Dai therefore proposed a second, more practical protocol involving a subset of participants called servers to maintain the accounts . These servers would be semi-trusted: they collectively hold the balances and process transactions, and to discourage misconduct they must put down a security deposit and regularly publish the state of their ledgers. Participants audit the servers by verifying that the total money in circulation matches the total PoW-generated money and that their own balances are correct . If any server deviates (for example, creates money illicitly), the cheat would be detectable and penalized via its deposit. This design removes the need for a single central bank, but it still requires some trust in a fixed set of server nodes and coordination to handle membership or failures. In summary, b-money introduced the idea of minting coins with computation and maintaining a distributed ledger, but it did not fully solve how to securely agree on transaction history without at least partially trusted parties.
Around the same time, Nick Szabo’s Bit Gold (circa 2005) outlined a similar concept of using proof-of-work strings as scarce objects that could act as digital gold, again with the challenge of how to prevent double-spending in a decentralized way. Szabo’s design chained proof-of-work solutions together and recorded them, but required a quorum of timestamp servers to verify and place transactions in sequence – foreshadowing elements of a blocks on the chain (including analysis) but not entirely avoiding trust in those servers.
Another piece of the puzzle was proof-of-work for spam prevention. Hashcash, proposed by Adam Back (1997; formalized 2002), showed that requiring a sender to perform a modest amount of computational work (like finding a hash with a certain number of leading zeros) could curb email spam and denial-of-service attacks . In Hashcash, the work is easy to verify but moderately hard to generate, thereby imposing a cost (in CPU cycles) on those who would abuse free resources . Hashcash was not a currency – it was a proof-of-work algorithm – but it demonstrated the feasibility of distributed, competition-based resource allocation using CPU power. Hashcash’s core idea of using a hash-based puzzle is directly employed in our system for selecting the next block writer.
Very recently, peer-to-peer networks (like BitTorrent for file sharing and earlier, Napster/Gnutella) had proven the viability of large, decentralized networks for sharing data without a central server. It was natural to consider marrying P2P networking with digital money. One attempt was Hal Finney’s Reusable Proofs of Work (RPOW) system in 2004. RPOW allowed Hashcash tokens (proofs of work) to be traded and re-used as a form of digital cash token. To prevent double spending, RPOW relied on a central server that maintained a database of which tokens had been spent, similar to a bank, but with a twist: the server itself ran on secure hardware (an IBM 4758 cryptographic co-processor) and was designed to be trust-minimized . The RPOW server would accept a Hashcash token from a user and return a signed token that could be passed on to someone else, who could in turn redeem it at the server. The server’s secure enclave would guarantee it followed the rules (never issuing more tokens than it received, etc.). In effect, Finney solved double-spending by concentrating trust in a auditable hardware module . RPOW was an elegant prototype and a direct precursor to our work – but it still had a central point of failure: if the RPOW server went down or was compromised, the system would break. It also did not implement a global transaction ledger; it handled token ownership transfer one at a time.
To truly decentralize digital currency, two breakthroughs were needed: (1) a way for a large, open network of nodes to agree on a single consistent transaction history (the “ledger”) without trusting each other, and (2) a way to incentivize nodes to participate honestly in maintaining this ledger. Our protocol addresses these by introducing a robust peer-to-peer consensus mechanism based on proof-of-work and by rewarding participants with newly generated coins for extending the ledger – all without any central authority. The following sections describe the components of our approach in detail.
Proposed Protocol Overview
Our system is a peer-to-peer electronic coin network. Participants (nodes) can transact directly with one another, and all transactions are publicly recorded in a tamper-evident ledger we call the block record. The block record is composed of sequential blocks (each block containing a batch of transactions) linked together using cryptographic hashes – effectively forming blocks in a chain where each block confirms the integrity of all prior blocks. We first outline how transactions work with digital signatures, then describe the construction of the block record via a distributed timestamp server and proof-of-work consensus, and finally the peer-to-peer network operations.
Transactions and Digital Signatures:
Each coin (or any fraction of coin value) is represented by a chain of digital signatures, similar to the “chain of ownership” in previous electronic cash proposals . When an owner transfers a coin to a recipient, they create a transaction by digitally signing a hash of the previous transaction (which indicates the coin’s history up to that point) together with the recipient’s public key, and then appending this signature to the coin’s record . The new owner’s public key becomes the identifier for the coin’s current owner, and the signature serves as an unforgeable proof of authenticity (only the previous owner’s private key could have produced it). In this way, possession of the coin is transferred much like endorsing a check – the signature is the endorsement giving value to the next holder. Anyone can verify the chain of signatures to confirm that the coin was indeed held by each prior owner in turn and that it has now been assigned to the new owner .
However, simply knowing the chain of ownership is not enough to prevent double-spending. The fundamental issue is that a payee cannot, on their own, verify that the payor didn’t send the same coin to someone else in a parallel transaction . If user Alice double-spends and signs two different transactions transferring the same coin (one to Bob, one to Charlie), both Bob and Charlie might see a valid signature from Alice – so each would think they are the new owner. In a purely peer-to-peer setting, how do we decide which transaction came first? Traditional electronic cash systems resolved this by having a central mint: all transactions had to go through a server that would serially check and invalidate coins, ensuring only the first spend is honored . That mint would refuse a second spend of the same coin. But relying on a single entity has the well-known downside that “the fate of the entire money system depends on the company running the mint” . If the mint misbehaves or is compromised, the currency collapses. Our goal is to achieve the same prevention of double-spending without a trusted third party.
To accomplish this, all transactions in our system are publicly announced to the network . Instead of a central mint knowing all transaction orders, every node in the peer-to-peer network will eventually learn of every transaction. We propagate transactions using a gossip protocol: when a user creates a transaction, they broadcast it to all the nodes they can reach, and those nodes relay it further, so that in short order, the entire network receives the transaction. Now, having a broadcast mechanism ensures everyone is aware of spends, but we still need a way to agree on a single global history – a linear ordering of all those broadcast transactions – so that no coin appears in two places in the order. In other words, the double-spending problem reduces to a consistency problem: the network must agree on which spend of a given coin happened “first” in the official history, rendering any other spends invalid.
Our solution is to organize transactions into blocks that are timestamped and linked, and to secure these blocks with computational proof-of-work so that honest nodes automatically converge on a single longest chain of blocks. The key innovation is leveraging proof-of-work to achieve distributed consensus on the transaction log.
Timestamp Server and Block Record Ledger:
We adopt a distributed timestamp server approach inspired by Haber-Stornetta timestamping . The idea is to batch transactions into a block, timestamp that block (in essence, assign it a position in history), and then link it to the previous block such that it is computationally infeasible to change the ordering. Each block contains: (a) a list of new transactions, (b) a reference (cryptographic hash) to the previous block in the chain, and (c) a proof-of-work nonce (described in the next section). The block is identified uniquely by a hash of its content. By including the hash of the prior block, each block cements the one before it – forming an immutable chain. This block chain (or block record) becomes a publicly verifiable ledger: if one tries to alter a transaction deep in the history, that block’s hash would change, which would invalidate every subsequent block (because their “previous block hash” field would no longer match). Thus, the ledger’s integrity is protected by this chain of hashes .
To publish a timestamp widely without a central authority, our nodes effectively use the block record itself as the publication medium. When a node generates a new block (with a set of pending transactions), it broadcasts the block to the network. The timestamp is implicitly the position of that block in the chain. Each block’s hash, when announced, serves as a tamper-evident timestamp: it proves those transactions existed at that moment (because the hash is now part of the global chain). Because each timestamp (block) includes the previous block’s hash, it reinforces all prior timestamps . In essence, the entire chain up to the latest block is re-published and reconfirmed every time a new block is added. This provides a linear, single-history timeline of all transactions.
Transactions inside a block are organized using a Merkle tree (a hash tree) for efficient verification . Rather than including every transaction’s full details in the block header, we include one master hash: the Merkle root. Transactions are hashed pairwise, then those hashes are hashed again, and so on up a binary tree until a single root hash is obtained. This Merkle root is stored in the block header. It allows any node to verify that a given transaction is in the block by retrieving a relatively short Merkle path (a sequence of hashes linking the transaction to the root). The use of Merkle trees (first proposed by Merkle in 1980 for digital signatures and authentication ) means blocks can be efficiently pruned or verified: you do not need to keep every transaction in memory to verify the chain, only the chain of block headers (each ~80 bytes) and whatever transactions you care about. This significantly reduces the storage and bandwidth burden for lightweight clients and is important for scalability.
Proof-of-Work Consensus Mechanism:
A proof-of-work (PoW) mechanism is used to secure the block record and achieve distributed consensus on the ordering of blocks. In our design, creating a valid block requires solving a computational puzzle, analogous to Adam Back’s Hashcash but applied to the entire block’s data . Specifically, the node assembling a block must find a nonce (an arbitrary number the miner can adjust) such that the hash of the block (when this nonce is included) is below a certain target value. Equivalently, the block’s hash must begin with a specified number of leading zero bits in binary. Because cryptographic hash functions (we use SHA-256 - NSA’s recent development) are effectively random outputs, a node must try many nonce values, hashing each time, until it finds a hash that meets the difficulty target. The probability of success for each hash is extremely low (proportional to 2^(−d) for d leading zeros required), so the only way to find a valid block is brute-force trial-and-error. Finding a block with, say, 60 leading zero bits might take on the order of 2^60 hash operations on average. However, verifying a proof-of-work is trivial: one just computes a single hash to check that the block’s hash indeed has the required zeros. This asymmetry ensures that producing blocks is resource-intensive, but checking them is cheap .
PoW serves several purposes in our protocol:
Order and Timestamping: The proof-of-work effectively timestamps the block in the sense that a block could only have been created by expending a certain amount of computational effort after the previous block. This prevents an attacker from easily back-dating blocks or inserting fake history, because they would need to catch up on all the work.
Sybil-Resistance: By making block creation computationally costly, we prevent a malicious actor from dominating the voting process by simply creating many pseudonymous nodes (Sybil attack). In our system, computing power is the resource that replaces identity: it’s “one CPU, one vote” rather than one user or one IP, one vote . A coalition controlling 30% of the network’s CPU power, for example, can expect to create 30% of the blocks on average. What matters for security is that no single adversary (or colluding group) obtains more than 50% of the total CPU power. Majority rule is enforced by longest-chain selection (described below).
Incentive and Scarcity: Requiring work creates a natural cost for adding blocks. We can attach a reward to block creation (e.g. a certain number of new digital coins minted in each block) to compensate miners for this cost. This not only incentivizes participation but also serves as the method of coin issuance in our system (analogous to gold miners being rewarded with gold, our “miners” earn some newly generated coins for each block they mine). As a result, the currency is introduced into circulation in a controlled, transparent way. For now, assume such a reward exists; we will discuss its implications later.
Longest Chain Consensus: All nodes follow a simple consensus rule: the longest valid chain of blocks is considered the authoritative ledger. “Longest” here actually means the chain with the most cumulative proof-of-work (technically, the highest total difficulty), but since difficulty is adjusted periodically, it usually corresponds to the greatest number of blocks. When a new block is found and broadcast, nodes will accept it only if all its transactions are valid (no double-spends, proper signatures, etc.) and the block’s proof-of-work meets the required difficulty . They then append this block to their copy of the chain and will begin working on the next block, chaining from this latest one . In the event that two different blocks are found at nearly the same time by different miners (a fork in the chain), some nodes will receive one block first and some the other. This results in a temporary divergence – two chains of equal length. The protocol handles this by having nodes temporarily accept both but continue mining on the one they received first . If the other chain later becomes longer (e.g., the other branch’s miner finds a second block, making that branch longer), nodes will switch to the longer chain and abandon the shorter one . This way, consensus will eventually coalesce on one branch – the one with more work – and the fork will be resolved. Honest nodes never outright discard work; they keep orphaned blocks in case they resurface as part of a longer chain. But generally, forks are short-lived and rare relative to the time to find blocks.
The proof-of-work requirement makes it extremely difficult for an attacker to alter history. If a dishonest node (or group) wanted to change a transaction that is already buried under z blocks in the chain (e.g., to double-spend coins it sent to someone), it would have to recompute the proof-of-work for that block and all subsequent blocks and then catch up to and surpass the length of the honest chain . Suppose the attacker controls a fraction q of the total computational power (and honest nodes have fraction p = 1 - q). The probability that the attacker can ever catch up from z blocks behind is vanishingly small if q < 0.5. In fact, one can show that this probability decreases exponentially with z: specifically, if honest nodes have majority (p > q), the probability an attacker eventually overtakes a z-block lead is approximately $(q/p)^z$ . For example, if the attacker has 10% of the network hash power (q=0.1), the chance of them reversing even 5 blocks is on the order of $(0.1/0.9)^5 \approx 1.2\times10^{-3}$ (0.12%); for 10 blocks it’s $(0.1/0.9)^{10} \approx 5\times10^{-5}$ (0.005%) – effectively infeasible . As long as honest nodes collectively hold the majority of CPU power, an attacker’s best strategy is futile beyond perhaps one or two blocks, and any double-spending attempt will be quickly self-defeating. We will analyze this more formally in the security section.
To maintain a stable rate of block creation (say, one block every 10 minutes on average), the network adjusts the difficulty of the proof-of-work dynamically . If blocks are being found too quickly (because more mining power has joined), the required puzzle target is tightened (more leading zeros required), and if blocks slow down, the target is loosened. This difficulty adjustment happens periodically (e.g. every two weeks) based on recent block timestamps, ensuring that the supply of new blocks (and thus new coins, if block rewards exist) follows a predictable trajectory.
Peer-to-Peer Network Operation:
The network itself is an unstructured peer-to-peer network of nodes with equal roles – there is no central node or hierarchy. New nodes may join at any time, and nodes may leave (go offline) at any time. All communication is based on a simple broadcast paradigm (implemented, for efficiency, as random flooding to peers). The fundamental steps each node follows are:
Transaction Relay: New transactions are broadcast to all peers . Each node that receives a valid transaction (correct signatures, not already spent) will forward it to others. Through this, transactions quickly propagate to every active node.
Block Assembly: Each node independently collects received transactions into a candidate block. Typically, a node will put as many pending transactions as can fit (up to a size limit) into a block. It also adds a special coin-based transaction that creates new coins payable to itself (this is the mining reward, providing incentive). The node then begins working on the proof-of-work for this block.
Mining (Proof-of-Work): The node searches for a nonce that makes the block’s hash satisfy the current difficulty target . This involves potentially billions of hash computations, trying different nonce values (and possibly tweaking the block’s coinbase transaction if more space is needed for extra nonce). While mining, the node continues to listen for new transactions (which it can add to its block if not already included) and for new blocks found by others.
Block Broadcast: When a node finally finds a valid proof-of-work for its block, it immediately broadcasts the new block to all its peers . Peers check the block’s validity: they verify the proof-of-work, verify that all transactions in the block are valid and not already spent, and that the block’s timestamp/hash links properly to the last block they consider part of the longest chain.
Chain Extension: If the new block is valid, nodes accept it and append it to their chain . They then mark the transactions in that block as confirmed (and not pending anymore). Crucially, they will stop working on their old candidate block (since it has been succeeded by the new block) and start a new mining process for a subsequent block, using the hash of the received block as the previous hash . In doing so, they are effectively voting with their CPU power that this new block is the rightful next entry in the ledger . If a node had another candidate block it was mining concurrently (in case of a fork), that block is now stale unless it also found a solution at nearly the same time (in which case a fork persists temporarily).
Fork Resolution: If a node receives a block that conflicts with its current chain (i.e., it has the same parent as a block the node has already accepted), this indicates a fork. The node will keep both branches but prefer the one with more cumulative work (initially, tie-break by whichever it received first). As soon as one branch becomes longer than the other by an additional proof-of-work, the node will switch to that branch as the main chain and abandon the shorter fork . Any transactions in the abandoned block that are not in the main chain are returned to the pool of pending transactions (since they may still be valid and should be mined in a future block).
Through this process, the network achieves a robust form of distributed consensus. Blocks act as votes for ordering of transactions, weighted by the CPU effort behind them . Honest nodes extend whichever chain has the most work, and any breakaway attempt by a malicious node either fails (if it lacks majority power) or, if it momentarily succeeds, is quickly obvious to all (because it had to expend extraordinary effort and still cannot sustain a lead if honest nodes outpace it). The system’s security now reduces to an economic question: as long as the majority of computational power is controlled by nodes who follow the protocol (and presumably seek the block rewards and transaction fees legitimately), the ledger will reflect only valid transactions and no double-spends.
Importantly, the network requires minimal coordination and no identities. Nodes do not need to know who each other are – there’s no central registry or authority assigning roles. Messages (transactions, blocks) are sent on a best-effort basis; it’s okay if some nodes are temporarily unreachable or if messages get delayed, because the protocol can tolerate propagation delays and still eventually reach consensus (with probabilistic finality – deeper blocks in the chain become exponentially less likely to be reversed). Nodes can leave and rejoin the network arbitrarily . A node that reconnects after some time will simply download the longest chain (it can get the chain of block headers from peers and then fetch any blocks it’s missing) and catch up with the current state, treating the longest chain as the authoritative history of what occurred while it was offline . This property ensures that the system is highly fault-tolerant and decentralized – no central uptime or synchronization is required.
To summarize, our protocol creates an ever-growing, append-only public ledger (the block record) where trust is replaced by computation. Double-spending is prevented by the collective agreement on a single history, secured by the costliness of producing that history. Next, we analyze the security of this scheme and discuss how close it comes to solving double-spending completely, as well as what issues remain.
Security Analysis
The security of the system rests on the assumption of an honest majority of CPU power. We assume attackers cannot command more computational resources than the combined honest participants indefinitely. Under that assumption, we argue that the protocol is resilient against double-spending and a variety of attacks, providing a degree of security that is “good enough” for practical use, though not absolute.
Transaction Finality: In traditional terms, our ledger offers probabilistic finality. That is, when a transaction is buried under enough blocks in the chain, the probability of it being reversed becomes negligibly small (though never strictly zero). For example, once a payment to you has, say, 6 blocks mined on top of it, an attacker would need to redo those 6 blocks and race past the current chain tip to overturn your payment. If the attacker has significantly less hashing power than the rest of the network, this scenario has astronomically low probability. Let’s derive the probability more formally:
Let q be the fraction of total mining power controlled by an attacker, and p = 1 - q be that of honest nodes. Suppose the attacker is z blocks behind the main chain (e.g., you wait for z confirmations of your transaction). The chance that the attacker will ever catch up and overtake the honest chain is roughly $(q/p)^z$ if p > q . If q < 0.5, this decays exponentially in z. (If q ≥ 0.5, the attacker would eventually reach parity and overtake with probability 1 – but that’s the scenario we seek to avoid by assuming honest majority.)
This formula comes from modeling block races as a binomial random walk (or Gambler’s Ruin problem). Intuitively, each block found by honest miners extends the honest lead by 1, each block found by the attacker reduces the lead by 1. We refer to standard probability texts for detailed derivation; a similar result appears in the literature on random Poisson processes . The key takeaway is that, for realistic parameters, waiting for a modest number of confirmations makes double-spending infeasible. For instance, with q = 0.1 (10% attacker power), z = 6 confirmations yields a catch-up probability on the order of $10^{-6}$ (one in a million) . Even if q = 0.3 (30% attacker), 6 confirmations give ~$0.177^6 \approx 0.00018$ (0.018%) chance, and 8-10 confirmations drive this below 0.001% . Thus, honest payees can be virtually certain of a payment’s finality after a small number of blocks.
Majority Attack Scenario: The most critical attack against our system is the 51% attack, where an attacker amasses more computing power than the rest of the network combined (q > 0.5). In this case, the attacker essentially controls the consensus. They could produce blocks faster than honest nodes and therefore monopolize the longest chain. This would allow them to rewrite history at will – for example, to double-spend by paying someone in block 100 and then secretly mining an alternative chain from block 99 onward that excludes that payment, eventually releasing a longer chain that orphaned the honest blocks 100+ and reversed the transaction. Our system, as designed, cannot prevent a 51% attacker from succeeding. The security model explicitly relies on p > q. However, it’s worth noting that achieving 51% of the global hash rate would require enormous resources in practice, and any attacker with such resources has a strong disincentive to destroy confidence in the system (since they would profit more from mining honestly and earning block rewards than from attacking the currency and undermining its value). Nonetheless, the possibility exists, especially in the early phase when the total network hash power is low or concentrated.
51% Attack and Race Attacks: In a scenario short of 51%, an attacker might attempt an attack wherein they mine a block privately that contains a double-spend and then release it at an opportune moment to override a transaction. This is essentially a race condition attack: the attacker convinces a vendor to accept an unconfirmed transaction (say, 0 confirmations, which is not recommended), and simultaneously mines a private block where that coin is spent differently. If the attacker finds the block quickly and broadcasts it, the vendor’s transaction will be invalidated. The defense here is straightforward: do not accept transactions until they have a few confirmations. Our protocol’s design expects users to wait for blocks to confirm their transactions, precisely to avoid race attacks. For high-value transactions, waiting for multiple confirmations (deep inclusion in the chain) makes these attacks impractical.
Network Partitioning: Another concern is if the network is split or partitioned (e.g., due to networking issues or an attack that isolates nodes). In such a case, two disjoint groups of miners might both build their own chains. When the partition heals, one chain will be longer and prevail. Transactions on the losing chain would be rolled back. Our consensus mechanism will still eventually converge (the longest chain wins), but in the interim, double-spends could occur across the partition. This is an inherent risk in any distributed system without synchronous guarantees. We mitigate this by the fact that blocks take some time (e.g. minutes) to mine, so even if a partition occurs, it is unlikely to go unnoticed for many blocks – nodes will see that something is wrong (no new blocks or conflicting longer chain) and network operators can work to restore connectivity. Also, an attacker who cannot muster majority hash power on bothsides of a partition cannot permanently fork the system; at worst they cause a temporary confusion that is resolved when connectivity returns.
Cryptographic Primitives: Our security also depends on the cryptographic primitives being unbroken. We rely on ECDSA (elliptic curve digital signature algorithm, or potentially RSA) for signatures – these are assumed unforgeable without the private key. We rely on SHA-256 (or a similar secure hash) for both proof-of-work and block hashing – it must behave like a random oracle (preimage resistant, etc.) such that finding a hash with d leading zeros indeed requires about 2^d hashes of brute force. A breakthrough in hash algorithms or a new attack (like a faster way to compute partial preimages) could upset the proof-of-work fairness. Quantum computing, for instance, poses a theoretical long-term risk to signature algorithms (Shor’s algorithm could break ECDSA) and possibly offers quadratic speedups for brute-forcing hashes (Grover’s algorithm). In 2006 these are mostly speculative; we assume no such breaks occur or that algorithms can be switched if needed (we can design the system to be algorithm-agile via versioning new blocks).
Under the stated assumptions, our protocol is secure against double-spending and tampering. The probability of a fraudulent fork overtaking the honest chain is negligibly small if honest miners control the majority of CPU power. The system’s decentralized consensus model greatly raises the cost of fraud: an attacker must literally re-do the accumulated work of the network. Unlike centralized systems where a single database breach or insider fraud could wreak havoc, here an attacker faces the combined heft of all honest participants’ computing power.
Limitations and Open Challenges
While our peer-to-peer block record ledger nearly solves the double-spending problem, we acknowledge a few important limitations and unresolved issues. These mean the solution is not entirely airtight, especially in its initial deployment and against certain attack scenarios:
Initial Distribution and Coin Issuance: The mechanism for introducing new coins is through mining rewards for proof-of-work. This ensures coins are earned by expending resources, aligning with earlier ideas (like b-money’s costliness of creation ). However, the integrity of this initial issuance depends on the software rules being correctly followed by all and not subverted. We assume the software is open source and deterministically defines that, for example, each new block creates a fixed reward (which could be constant or perhaps diminishing over time to eventually cap the money supply). If there were a bug or if early miners collude to change this rule, it could undermine the currency (e.g., creating more coins than intended or biasing issuance). Our approach lacks a governance mechanism beyond the consensus itself to adjust monetary policy; it is “baked in” from the start. This is mostly a social issue – users must agree on the monetary parameters – but it’s worth noting as a limitation: there is no central authority to correct course if the issuance model has a flaw. Additionally, the initial coins will tend to accumulate to early adopters (the first miners). This could raise questions of fairness or concentration of wealth, although one could argue any new currency, like any startup, rewards its pioneers by design.
51% Vulnerability in Early Phase: Perhaps the most significant practical concern is the network’s strength when it is small. In the very beginning, the total hash rate might be low – maybe just a few hobbyists mining. During this period, the cost for an attacker to gain majority mining power is low, making the system vulnerable to majority attacks. For example, a single entity or organization could quietly accumulate more CPU power (or specialized hardware) than all honest miners and then carry out double-spends or block censorship. Once the network grows large (say, comparable to supercomputer levels of hash power), this attack becomes extremely expensive (and easily noticeable if someone buys up that much hardware). But reaching that scale requires time and participation. We thus face a bootstrapping paradox: the system is most vulnerable precisely when confidence in it is still forming. If an attack were to succeed early on (for instance, double-spending some high-value transaction and undermining trust in the currency), it could stifle adoption. In this sense, our solution “nearly” solves double-spending – it does so probabilistically and economically, but it doesn’t offer a 100% guarantee, especially in the face of a determined well-resourced adversary. One mitigation is transparency: because block history is public, any reorganization or orphaned blocks are visible. If a deep reorg happened (say 6 blocks got replaced), everyone would know, and this could be addressed socially (nodes might choose to reject an attacker’s chain if identified – but that introduces a trust decision outside the protocol). Ultimately, the hope is that economic incentives (the value of the block rewards and coins) align such that attacking the system is against the attacker’s own financial interest. Still, the early-phase weakness remains an open challenge.
Transaction Throughput and Latency: Our design, as presented, assumes a certain target block rate (e.g., one block every 10 minutes) and a block size limit (e.g., a few hundred kilobytes of transactions). These parameters mean that the system can only process on the order of a handful of transactions per second globally, which is modest compared to, say, credit card networks. We choose conservative parameters to ensure propagation and verification can keep up with mining – every node must receive each block in time to incorporate it into their chain before the next one arrives (to avoid excessive orphaning). In 2006, typical broadband can handle this easily, but if the system were to become extremely popular, scaling to thousands of transactions per second would be problematic. There is a trade-off between decentralization and throughput: raising the block size or frequency too much could lead to centralization (only very powerful nodes could process all transactions). This is a known limitation; we anticipate further research into second-layer protocols or other techniques to enhance throughput without sacrificing the trustless nature.
Partial Anonymity and Privacy: Our block record ledger is public by design – all transactions are visible to anyone. While we identify users only by public key addresses (pseudonyms), the flow of funds is completely transparent. This means the system is pseudonymous, not anonymous. Users’ privacy is protected only until their pseudonym is linked to their real identity. Once, for example, Alice’s public key is associated with her (perhaps through an IP address leak or an exchange that knows her identity), all her past and future transactions under that key (and any keys it can be linked to via graph analysis) become visible . The public and permanent nature of the ledger raises obvious privacy concerns: transaction patterns can reveal who is paying whom, how much they have, etc., especially with advanced analytics. In Section “Surveillance and Co-option Risks” below, we discuss how this could allow total surveillance if the system were subverted. For now, it’s a limitation that users must manage (e.g., by using a new key pair for each transaction to increase anonymity, and perhaps through mixing services to break linkages – though those come with their own trust issues).
Finality and Irreversibility: While irreversibility is a goal (to prevent fraud chargebacks), it is also a limitation in cases of accidental loss or theft. If a user’s private keys are stolen or coins sent to the wrong address, there is no recourse – no “undo” button – absent a centralized authority. This is not a flaw per se (it’s inherent to a cash-like system), but it means the ecosystem may need to develop contract protocols (escrow, multi-signature, etc.) to handle disputes or accidents. We enable these at a basic level (scripts could be used for multi-sig transactions, though that is beyond our current scope), but they are not yet fully explored.
Despite these limitations, we believe the benefits of a decentralized, trust-minimized currency are compelling. Most of the challenges are extrinsic (economic, social, or usability concerns) rather than intrinsic flaws in the cryptographic protocol. The double-spending problem is addressed to a very high degree of confidence, barring edge cases like an overwhelming majority attack. In the next sections, we will delve into some broader societal implications – including potential misuse of this technology – and conclude with thoughts on future work and why openness is essential.
Parallel Efforts and Open Development Imperative
It is noteworthy that a project of this nature does not develop in isolation. Through community discussions and private communications, the author has become aware of a parallel effort to implement a similar peer-to-peer electronic currency. This effort appears to be spearheaded by a pseudonymous individual ostensibly representing a group of developers or sponsors. Unconfirmed information suggests that this group’s motivations might not align with the ideals of openness and decentralization that drive our work. There is speculation that they intend to patent certain techniques or maintain tight control over the protocol, possibly to leverage it for influence or profit in a less-than-transparent manner.
The existence of such a parallel project – especially one cloaked in secrecy – is a key reason we are publishing our design at this time (2006). We strongly believe that a technology as impactful as a global decentralized currency should be developed openly, with peer review and public collaboration. The risk of a closed-source or proprietary implementation is that it could contain hidden pitfalls, backdoors, or economic biases that serve the interests of a few. For example, an individual or group with a private digital coin system could manipulate the initial coin distribution or insert surveillance hooks that users are unaware of. If the project is presented as a fait accompli to the world, with questionable motives (say, a state actor or corporate entity aiming to dominate digital currency under the guise of anonymity), it could co-opt the narrative and deployment of this technology.
By contrast, our aim is to place this proposal into the public domain, inviting cryptographers, computer scientists, and the broader cypherpunk community to scrutinize, test, and improve it. In publishing early, we sacrifice the opportunity to perfectly “finish” the system in private, but we gain the collective wisdom of many. We also hope to preempt any attempts at proprietary control. If an individual (or cabal) is indeed on the verge of releasing a similar system for less altruistic purposes, an open alternative can undermine that agenda. Consider it an open-source countermeasure: much like strong cryptography was made public in the 1990s to prevent its monopolization by governments, we publish this protocol now to ensure it grows as a commons, not a monopoly.
This paper therefore serves as both a technical proposal and a call to action for open collaboration. We welcome contributors who share the vision of a free and private electronic cash to join in refining the design, solving the remaining issues, and building implementations. The author has no intention of anonymity or secrecy beyond what is necessary for personal privacy; the focus is on the technology, which we hope will stand on its merits. History has shown that technologies which start open have a better chance at resisting capture by narrow interests.
While some may attempt to develop digital coin systems behind closed doors – possibly as an agent for unknown sponsors – our approach is to “go public” first. Doing so ensures that the ideas are available to all of humanity, and any party that comes later with a similar system will face pressure to explain why theirs isn’t simply using or building on the already-public design. We believe this transparency is the best defense against any group with “questionable public motivations” trying to dominate a revolutionary financial technology. We encourage the community to engage, critique, and improve upon this work, such that the eventual deployed system (be it ours or an improved variant) truly embodies the ethos of open development and decentralized trust.
Surveillance and Co-option Risks
While our proposed block record-based coin system is designed to empower users by removing centralized control, it is important to acknowledge a paradoxical risk: such a system could be turned into a tool of surveillance and control if appropriated by powerful entities (e.g., government intelligence agencies). In this section, we explore how a technology touted as libertarian and privacy-enhancing might be co-opted, and discuss the implications.
Public Ledger = Public Data: By design, every transaction in the block record is visible to anyone who examines the chain. Identities are hidden behind public keys (pseudonyms), but as discussed, the pseudonymity can be brittle . Once any linkage to the real world is made, the entire transaction history becomes traceable. Agencies with vast resources could deploy network analysis, clustering algorithms, and correlate blocks visible on chain activity with network traffic (e.g., observing the timing and origin of transaction broadcasts) to map who is who. Already today (2006), we see law enforcement adapting to new technologies; one can imagine them eagerly exploiting an open ledger of all transactions. The “public-but-pseudonymous” nature of the system means that it paradoxically provides total transparency over financial flows . In the wrong hands, this could enable a surveillance regime more penetrating than any current banking system (which at least has some legal hurdles for access).
Intelligence Agency Interest: It is plausible that intelligence agencies or other government units might quietly support or even initiate a project like this under the guise of an anti-establishment, privacy-focused endeavor. The motive? To lure those seeking privacy or engaging in illicit trades into using a system that, unbeknownst to them, provides a permanent record of their activities. The agencies wouldn’t need to break encryption or anonymity in real-time; they could simply let users incriminate themselves on an immutable ledger and perform analysis at leisure. The scenario might go as follows: A pseudonymous developer (or developers) releases a cryptocurrency promising freedom from banks and government control. It gains popularity among dissidents, hackers, black-market dealers, etc. Meanwhile, behind the scenes, the developer is either an agent or has been co-opted by an agency that monitors the network. Over time, they deanonymize key users (perhaps by running a large number of network nodes to observe connections, or by exploiting IP address leaks). The ledger’s longevity means that even years later, historical transactions can be analyzed as new clues (exchange records, deanonymized addresses) come to light. In effect, the very tool meant to sidestep surveillance could become the ultimate financial panopticon.
This is not mere paranoia. History provides precedents: The Tor network, widely used for anonymous communication, was originally developed by the U.S. Naval Research Lab and has received substantial government funding . Tor’s technology was openly released, yet its origins illustrate that governments may seed ostensibly anti-censorship tools that also serve their intelligence interests. Similarly, cryptography itself was once classified; when strong crypto became public, governments shifted to a strategy of embracing and subverting – for instance, NSA’s involvement in setting cryptographic standards that might contain backdoors (as alleged with the Dual_EC RNG). It is conceivable that a state actor might prefer a world where all financial transactions are on a public ledger (even if pseudonymous), rather than today’s world of cash and closed bank ledgers, because at least the ledger provides a starting point for tracking.
Co-option Scenarios: There are multiple ways a block record system could be co-opted:
Direct control of mining: A government could allocate massive computing resources (perhaps commandeered botnets or specialized hardware) to dominate the mining process. By controlling most blocks, they could influence the protocol’s evolution (through majority votes on consensus rules), deanonymize users (by observing transaction propagation patterns more closely as the miner), or selectively censor transactions from targets (although outright censorship would be noticeable, so more likely they’d just watch).
Forcing integration with identity: Authorities could regulate exchanges and businesses to require KYC (Know Your Customer) linking of addresses to real identities whenever cryptocurrency touches the traditional economy. This is already how banks handle cash: once you deposit, the cash’s anonymity is lost. If block coins become widespread, laws might require that, say, any transaction above $X or involving certain services includes an attached identity proof. Intelligence agencies wouldn’t need to break the crypto; they could gather data from these required checkpoints, then track funds on the chain between checkpoints. The ledger never forgets, so they can retroactively follow the money through dozens of hops. The end result could be total transaction surveillanceunder the banner of “preventing criminal use.”
Promotion of a state-friendly fork: If an open community version exists, a state or large corporation might promote an “improved” version (a fork) with subtly enhanced tracking features (for instance, tagging coins or addressing “AML/KYC compliance”). They could lobby for this version, offering incentives for its adoption (maybe even airdropping coins to citizens or using state power to prefer it). The public might adopt it for convenience, not realizing they are accepting a more centralized or traceable variant of the currency.
Big Brother and the Ledger: David Chaum warned decades ago that without careful design, computerization of payments could lead to unprecedented surveillance and loss of liberty . Our system, ironically, might fulfill part of that dystopia if abused: by interlinking transactional relationships openly, it creates a rich data source that could “become unacceptable” if used for mass surveillance . Some might argue that at least the surveillance is symmetric (everyone can see, not just governments). But realistically, the average person lacks the means or interest to analyze the blocks on the chain in detail, whereas well-funded entities can invest heavily in block reviews on the blocks via their associated chain analytics. Indeed, one can foresee an entire industry of “blocks on the chain intelligence” emerging (companies analyzing flows, scoring addresses for risk, etc., to sell to banks or law enforcement), something that is already beginning in nascent form. Transparency for the people can inadvertently become transparency of the people to those in power.
The False Promise of Anonymity: It is worth dispelling any notion that the system as described provides anonymity comparable to cash. It does not. As an example scenario: suppose a democracy activist in a repressive regime uses the cryptocurrency to receive donations and purchase resources. All their transactions are on the ledger. The government might not know the activist’s addresses initially. But if they ever arrest an accomplice or seize one computer, they could extract a single address, then immediately query the entire ledger to find every transaction that ever involved that address, uncovering the activist’s funding sources, allies (addresses that sent funds), and spending targets. Even without arresting anyone, intelligence units could run analysis to cluster addresses (identifying which addresses likely belong to the same user by looking at co-spending in one transaction, timing patterns, etc.). Over years, these techniques can map a large portion of the network. In short: participants must operate under the assumption that someone is watching, because if not now, eventually someone can . As one industry motto might put it: “Crypto isn’t a mask, it’s a mirror” – you’re not invisible, you’re transacting in a transparent arena visible to all .
Mitigations: What can be done? At the protocol level, some improvements could enhance privacy – for instance, mixing protocols or confidential transactions that hide amounts. Those are beyond our scope here but are areas for future research. On the user side, practices like generating new key pairs for each transaction and using anonymizing networks (e.g., Tor) to broadcast transactions can help, but they are not foolproof if an adversary can correlate activities. Ultimately, the community must be vigilant. The best defense against co-option is open development and public awareness. If the community suspects a certain mining pool or entity is trying to dominate, they can rally others to increase hash power or even change the proof-of-work algorithm (a drastic measure) to level the field. If new features are proposed that could undermine privacy, the open-source nature allows experts to scrutinize and object. This ties back to why openness is critical: a closed project could much more easily introduce surveillance backdoors; an open one at least provides a fighting chance to resist them.
Plausible Narrative – “Embrace, Extend, Extinguish”: As a thought experiment, consider how an intelligence agency might strategize around cryptocurrency. Initially, they might fear it (as it enables anonymous trade outside their control). But then they realize its traceability is actually a gold mine of data if people can be nudged to use it widely. So they tacitly encourage its adoption – maybe by not cracking down too hard, or even by using it for their own operations to provide liquidity and legitimacy. They ensure key off-ramps (exchanges) come under regulated frameworks, giving them entry points for information. As digital currency usage grows, cash usage diminishes (cash is truly anonymous and hence a bigger thorn for surveillance). In a possible future, the majority of commerce flows through block reviews (via their chains), and at that point, privacy is effectively gone unless strong safeguards are built-in from the start. A society could sleepwalk into a financial panopticon under the banner of technological progress and freedom. This is a double-edged sword inherent in our design that the community must acknowledge.
Thus, our system empowers individuals by removing central control and enabling direct asset ownership. But it simultaneously creates a public record of economic activity. Intelligence agencies and other actors could exploit this, especially if users are careless or the community is not vigilant. We strongly advocate ongoing research into privacy enhancements (such as zero-knowledge proofs for transactions) to counteract this risk. Additionally, we emphasize user education: participants should understand that pseudonymity is not absolute and take measures to protect their identity if needed. By highlighting these risks in our 2006 paper, we hope to preempt naiveté; the community should enter this new paradigm with eyes open to both the freedoms and the potential for Big Brother if we are not careful .
Conclusion on the Blueprint (so far)
In this paper, we have presented a blueprint for a decentralized peer-to-peer digital coin system that uses a block record ledger to record transactions in a chain of blocks secured by proof-of-work. Our design draws on prior ideas (digital signatures, distributed timestamping, Hashcash-style PoW, Merkle trees, etc.) and synthesizes them into a unified protocol that greatly mitigates the double-spending problem without requiring a trusted authority. Each transaction is authenticated by the owner’s digital signature, and double-spending is prevented by the collective agreement of a network of nodes on a single transaction history. Transactions are grouped into timestamped blocks; each block reinforces previous ones, forming an ever-growing chain that an attacker cannot alter retroactively without expending prohibitive computational effort . Honest nodes always extend the longest (most-work) chain, and any conflicting forks are resolved in favor of the longest chain, ensuring eventual consistency across the system.
Our analysis shows that as long as a majority of the computing power is controlled by honest participants, the system is secure against tampering and fraudulent transactions . We provided a quantitative argument for how the probability of an attacker catching up declines exponentially with each additional confirmation block , giving users confidence to treat transactions as final after a small number of confirmations. In this sense, our protocol nearly solves the double-spending issue that has plagued digital cash proposals: it makes double-spending computationally infeasible in practice (below any desired probability threshold) without central coordination.
However, we have also been candid about the limitations and the fact that “nearly solved” is not “fully solved.” The system is not magically secure if attackers command overwhelming resources; it simply changes the security assumption from trusting a central authority to trusting the majority of a distributed community. We discussed the particular concerns in the early stages (when the network is small and vulnerable) and emphasized the need for ongoing vigilance and refinement. Economic and game-theoretic considerations will play a large role in the system’s real-world robustness – miners must have incentive to act honestly (the block reward and the value of the currency), and users must remain watchful for potential consolidation of mining power or other systemic risks.
One novel aspect of our contribution is highlighting the social and geopolitical context around such a currency. We analyzed the contemporary financial climate – notably the impending U.S. housing market collapse – to illustrate why a decentralized currency could be timely and desirable. The subprime mortgage crisis (brewing in 2006) exemplifies how opaque, centralized financial engineering can lead to catastrophic outcomes . A transparent, math-based currency is not directly a solution to bad loans or regulatory failure, but it provides an alternative that is free from certain human foibles (e.g., it cannot inflate away debt, and it operates on rules rather than discretion). Moreover, trust in central institutions tends to erode in the wake of crises; an independent digital coin could serve as a hedge against such institutional failures.
We also confronted the ironic possibility that a tool intended for individual liberty could be subverted into a surveillance mechanism. The block record ledger, if widely used, creates a permanent public history of transactions that could be harvested for intelligence on citizens’ economic activity . This dual-use nature means that we as a community must be proactive in building in privacy protections and resisting efforts to co-opt the system for monitoring or control. Our paper doesn’t solve that outright, but by explicitly acknowledging it, we hope to set a tone of cautious awareness as this technology moves forward.
Closing Note
In closing, this proposal is a starting point, not a final product. We expect, and indeed encourage, rigorous discussion, peer review, and experimentation. There are engineering challenges ahead: implementing the system, optimizing it, dealing with parameters (like block size, frequency, reward schedule), and responding to any issues that arise in practice. There are also philosophical and policy discussions to be had, because a successful deployment would intersect with law, economics, and society in unpredictable ways.
The author publishes this work with humble recognition of those who came before – the cypherpunks, cryptographers, and computer scientists whose ideas we have woven together – and with hope that the community will carry it forward in the same spirit of open innovation. Should a similar system emerge from other quarters with less openness, we trust that the existence of this paper will empower the public to question and, if needed, fork or improve upon that system to keep it aligned with the public interest.
In 2006, the pieces are in place for a revolution in finance: ubiquitous networks, strong cryptography, and growing disenchantment with legacy institutions. The peer-to-peer electronic coin described here is one attempt to seize that moment. It nearly solves a longstanding problem in computer science and finance, and with further refinement, it could provide the foundation for a new era of secure, decentralized commerce on the Internet. We invite the world to scrutinize our proposal, test its soundness, and join in building a future where individuals can transact freely without unwarranted interference – all while collectively safeguarding the system from both technical threats and the threat of human misuse.
References
W. Dai, “b-money,” 1998. (Available at http://www.weidai.com/bmoney.txt)
H. Massias, X. S. Avila, and J.-J. Quisquater, “Design of a secure timestamping service with minimal trust requirements,” 20th Symposium on Information Theory in the Benelux, May 1999.
S. Haber, W. S. Stornetta, “How to time-stamp a digital document,” Journal of Cryptology, vol. 3, no. 2, pp. 99–111, 1991.
D. Bayer, S. Haber, W. S. Stornetta, “Improving the efficiency and reliability of digital time-stamping,” in Sequences II: Methods in Communication, Security, and Computer Science, 1993.
S. Haber, W. S. Stornetta, “Secure names for bit-strings,” Proc. of the 4th ACM Conference on Computer and Communications Security, pp. 28–35, April 1997.
A. Back, “Hashcash – a denial of service counter-measure,” 2002. (Hashcash.org whitepaper)
H. Finney, “Reusable Proofs of Work (RPOW),” 2004. (Online: finney.org/RPOW – RPOW system description)
R. C. Merkle, “Protocols for public key cryptosystems,” Proc. 1980 Symposium on Security and Privacy, IEEE, pp. 122–133, April 1980.
D. Chaum, “Security without identification: transaction systems to make Big Brother obsolete,” Communications of the ACM, vol. 28, no. 10, pp. 1030–1044, Oct. 1985
