Double-spending

Double-spending is the unauthorized spending of the same money (either digital or conventional) more than once. As with counterfeit money, double-spending leads to supply inflation by creating a new amount of copied currency that did not previously exist. It can also devalue the currency and diminish user trust in the currency.

There are many fundamental cryptographic techniques to prevent double-spending while preserving anonymity in a transaction, including the introduction of a centralized authority (proof-of-authority) for blind signatures and, particularly in offline systems, secret splitting.. Other methods to mitigate the double-spend problem include decentralized consensus protocols such as proof-of-work and proof-of-stake.

Centralized digital currencies

Prevention of double-spending is usually implemented using an online central trusted third party that can verify whether a token has been spent. This normally represents a single point of failure from both availability and trust viewpoints.

Decentralized digital currencies

See also: Blockchain § Finality

In a decentralized system, the double-spending problem is significantly harder to solve. To avoid the need for a trusted third party, many servers must store identical up-to-date copies of a public transaction ledger, but as transactions (requests to spend money) are broadcast, they will arrive at each server at slightly different times. If two transactions attempt to spend the same token, each server will consider the first transaction it sees to be valid, and the other invalid. Once the servers disagree, there is no way to determine true balances, as each server's observations are considered equally valid.

Most decentralized systems solve this problem with a consensus algorithm, a way to bring the servers back in sync. Two notable types of consensus mechanisms are proof-of-work and proof-of-stake.

By 2007, a number of distributed systems for the prevention of double-spending had been proposed.

The cryptocurrency Bitcoin implemented a solution in early 2009. Its cryptographic protocol used a proof-of-work consensus mechanism where transactions are batched into blocks and chained together using a linked list of hash pointers (blockchain). Any server can produce a block by solving a computationally difficult puzzle (specifically finding a partial hash collision) called mining. The block commits to the entire history of bitcoin transactions as well as the new set of incoming transactions. The miner is rewarded some bitcoins for solving it.

The double-spending problem persists, however, if two blocks (with conflicting transactions) are mined at the same approximate time. When servers inevitably disagree on the order of the two blocks, they each keep both blocks temporarily. As new blocks arrive, they must commit to one history or the other, and eventually a single chain will continue on, while the other(s) will not. Since the longest (more technically "heaviest") chain is considered to be the valid data set, miners are incentivized to only build blocks on the longest chain they know about in order for it to become part of that dataset (and for their reward to be valid).

Bitcoin's proof-of-work protocol has probabilistic finality where transactions are never technically "final" because a conflicting chain of blocks can always outgrow the current canonical chain. However, as blocks are built on top of a transaction, it becomes increasingly costly and thus unlikely for another chain to overtake it. Because competing chains and reorgs can arise naturally, it is recommended that participants wait a number of blocks (i.e. "confirmations") before accepting the probabilistic finality of the transaction. If the participant does not wait a sufficient number of confirmations, it risks the chance of a double-spend if the transaction is reversed on the blockchain.

51% attack

Due to the nature of a decentralized blockchain, and in lack of a central authority to do so, the correct succession of transactions is defined only by the dominating consensus. This leads to the possibility of one actor gaining majority control over the entities deciding said consensus, to force their own version of events, including alternative and double transactions. Due to information propagation delays, 51% attacks are temporarily possible for a localized subset of actors too.

The total computational power of a decentralized proof-of-work system is the sum of the computational power of the nodes, which can differ significantly due to the hardware used. Larger computational power increases the chance to win the mining reward for each new block mined, which creates an incentive to accumulate clusters of mining nodes, or mining pools. Any pool that achieves 51% hashing power can effectively overturn network transactions, allowing for the possibility of double-spending.

Examples of double-spending caused by 51% attacks

There are many known examples of double-spending as the result of majority attacks on proof-of-work protocols:

In March 2013, Bitcoin experienced the first known example of a cryptocurrency double-spend when the chain split due to a bug in the Bitcoin 0.8.0 client. While on the 0.8.0 chain, a merchant (OKPAY) confirmed a $10k deposit from a customer. Bitcoin miners then 51% attacked the network, reverting 24 blocks and reversing the transaction leading to the customer's deposit. The customer then double-spent the bitcoin on the canonical pre-0.8.0 chain as an experiment.

One of the Bitcoin forks, Bitcoin Gold, was hit by two double-spending attacks as the result of a 51% attack. This cost exchanges $18M in Sept 2018 and $72k in January 2020.

An Ethereum fork, Ethereum Classic, experienced a 51% attack in 2019, followed by multiple more in 2020, significantly impacting its security and market perception. Attackers attempted a $1.1M double-spend on Coinbase and successfully double-spent $200k on Gate.io. These attacks involved malicious actors reorganizing transactions to double-spend coins, leading to concerns regarding the long-term viability and security measures of the Ethereum Classic blockchain.

Atomic Ownership Blockchains

Atomic Ownership Blockchains achieve a higher degree of decentralization than Bitcoin-style public blockchains through public domain private micro-blockchains, thereby enabling resistance to double-spending attacks at the cryptographic level without relying on ideal economic models or being constrained by the proportion of control over computing power or other resources.

Atomic Ownership Blockchains (AOB) employs multiple micro-blockchains to represent the system, with each blockchain dedicated to describing a single atomic object. Each blockchain operates as a public-domain private blockchain: it is visible and readable in the public domain, but only its owner has the authority to append new blocks. The owner transfers ownership by adding a block that specifies the recipient's public key as the new target. Upon transfer, the recipient becomes the new owner and can subsequently append blocks to pass the blockchain to another party. This process enables rapid circulation of blockchains among participants without requiring any consensus algorithms. The sequence of transfer blocks on the blockchain records its full ownership history, allowing the current owner to be determined from the most recent block.

AOB counters double-spending attacks through the following mechanisms:

Punishing Attackers

As private blockchains, each AOB position allows only one individual to append blocks. Any forks—branches created by the same owner—indicate an attack attempt. The block appender can thus be directly identified as the attacker and added to a global blacklist by all nodes, resulting in the forfeiture of their account balance. If account creation incurs a fee, the attacker also loses that cost. This economic penalty ensures attackers cannot profit, achieving security at the economic level.

Fork Selection

For conflicting blocks at a fork point, the network deems the first-broadcast block as valid. If an attacker broadcasts two conflicting blocks with a sufficiently long interval, the network achieves implicit consensus on their order. If the interval is short, the recipient rejects the payment. The estimated network-wide broadcast time is denoted as t0. Third-party nodes, upon receiving a payment block, wait for 2t0 without detecting a conflicting block, can confirm that—even if a fork emerges later—this block was broadcast first and received by all nodes ahead of alternatives, thereby validating it. For the recipient of the payment, waiting 4t0 without conflicts ensures that all nodes have received the block first and observed the 2t0 window, making acceptance secure.