The Double Spending Problem, Explained

The double spending problem is a security concern specific to digital cash and cryptocurrency projects. In particular, the double spending problem means that the developers of a virtual currency must prevent users from being able to spend their funds more than once. This security concern is akin to the problem of counterfeit currency that governments and traditional financial systems must address.

The solution to the double spending problem is quite easy to implement on networks that use a centralized database. At the same time, the presence of a single point of failure leading to other security vulnerabilities and other concerns, such as censorship.

In contrast, the double spending problem is more difficult to solve for decentralized networks that use a group of distributed nodes (e.g. computers or other physical devices) to verify transactions. But, if an effective solution is implemented, it becomes infinitely more difficult for a malicious actor or a group of malicious actors to attack the network and spend funds twice.

In this article, we’ll go over an easy-to-understand example of the double spending problem. We’ll look at a few of the early attempts to solve this issue through centralized and decentralized networks. We’ll also dissect three specific types of double spending attacks that can occur on blockchain networks.

What Is The Double Spending Problem?

The double spending problem is a security challenge that has existed for several decades. Let’s look at a basic example to get a better understanding of this challenge.

Let’s imagine that Alice has $100 in her account and wants to send $30 to Bob through a digital cash network such as a central bank or a decentralized blockchain network.

Scenario 1: If the network functions as it should, the double spending problem will be avoided. Alice will have $70 remaining in her account after the transfer. Bob will have an additional $30 in his account.

Scenario 2: If the network doesn’t function properly, Alice is able to spend the same funds twice (better known as double spending). In this scenario, Alice will still have $100 remaining in her account after the transfer. Meanwhile, Bob will have an additional $30 in his account.

If Scenario 2 occurs, it’s easy to see why the digital cash network is basically worthless. Because of the double spending problem, Alice was able to easily create money out of thin air.

In most non-monetary applications, this would be perfectly fine. For example, Alice could have one copy of a digital file (e.g. an MP3 or a PDF) and Bob could have another copy. They could share the digital file 100 times or 1,000 times. With each time they share the digital file, there are more copies in existence, but this doesn’t create any problems for the file or for its users.

However, if they want to transfer digital cash, funds can’t simply be copied and pasted, or recreated in any other way. In a secure digital cash network, the net value of all transfers needs to be equal to $0. As we see in Scenario 1, Alice should lose $30, and Bob should gain $30. This same principle applies no matter whether digital cash represents digital fiat currencies, cryptocurrencies, or any other types of virtual currency.

Does your project need security against double spending caused by 51% attacks? Contact our team anytime at partners@komodoplatform.com to request a free assessment and quote.

Early Solutions For The Double Spending Problem

A wide array of solutions for double spending emerged throughout the 1990s. Some were merely proposals, while others became working protocols that gained some traction. While all of them ultimately failed to gain widespread adoption or completely solve the double spending prevention, they each contributed to future solutions.

David Chaum’s eCash

In 1982, David Chaum published a research paper titled, “Blind Signatures For Untraceable Payments” that proposed a solution for the double spending problem. This system, known as eCash, allowed users to store digital cash on a local computer. eCash solved the double spending problem through blind signatures, which made use of RSA encryption. In 1989, Chaum started a company called DigiCash, which fully implemented eCash technology in 1990.

The biggest obstacle to the adoption of eCash was that it relied upon banks, which created a single point of failure. Before an eCash payment could be deposited into a bank account, a user had to inform their bank. It was possible (if not highly likely) that a recipient’s bank wouldn’t accept eCash deposits. If a user couldn’t find a bank to accept the payment, the funds essentially became worthless. eCash was successful in gaining adoption from banks based in Australia, Austria, Germany, Sweden, and Switzerland. However, the system was unable to gain widespread adoption, and DigiCash went bankrupt in 1998.

Adam Back’s HashCash

In 1997, Adam Back proposed a Proof of Work algorithm called HashCash that aimed to reduce denial-of-service attacks and email spam. Proof of Work is one variety of consensus protocol (also known as consensus mechanism). Contrary to its name, HashCash didn’t involve any sending and receiving of digital cash. Nonetheless, it introduced an important double spending solution which influenced the creation of future digital cash systems. Unlike eCash, HashCash attempted to solve the double spending problem without the need for a central administrator.

HashCash used the SHA-1 cryptographic hash function. Users who wanted to send an email were required to solve a cryptographic puzzle that would create a unique stamp. Since this process took a length of time, receivers could assume that the sender was less likely to be a spammer. Whenever someone wanted to send a new email, they were required to generate a new stamp.

To enforce this rule, HashCash used a double spend database. If an email included a stamp that was used previously, it would be rejected. In other words, the email wouldn’t reach the recipient. A spam filter service called SpamAssassin and an email client called Mozilla Thunderbird used HashCash. Additionally, Microsoft temporarily used a version of HashCash in an email postmark designed for spam prevention.

Decentralized Virtual Currencies

There were many attempts to create a decentralized digital cash system based on HashCash’s Proof of Work consensus protocol. In 1998, Wei Dai proposed an anonymous, distributed electronic cash system called B-Money. In that same year, Nick Szabo designed a mechanism for a digital currency called Bit Gold. In 2004, Hal Finney introduced a digital token system called Reusable Proof of Work (RPoW). Generally speaking, these solutions solved the double spending problem but did so with such significant trade-offs or other limitations that they all failed to gain widespread adoption. Nonetheless, they provided both the ideas and technical foundation that led to the creation of Bitcoin— the world’s first blockchain network.

How Bitcoin Solved The Double Spending Problem

With the launch of the Bitcoin protocol in January 2009, a decentralized digital cash network that efficiently solved the double spending problem was finally born. There are a range of innovative features that enable this system to function smoothly.

Blockchain Security And Confirmations

The Bitcoin protocol is a blockchain, which is one variety of distributed ledger technology (DLT). In a blockchain, there is no need for a central administrator or intermediary. Every BTC transaction is publicly broadcast to a peer-to-peer network of distributed nodes. These nodes then perform independent verification and communicate among themselves to come to agreement on whether transactions are valid or invalid.

Bitcoin, as well as other blockchain networks, use a system known as blockchain confirmations to ensure that transactions have been thoroughly verified on the network. If someone attempts to make two transactions nearly simultaneously, nodes will check to see which transaction has more blockchain confirmations. The transaction with more confirmations will be validated, meaning that funds can be spent. Meanwhile, the transaction with fewer confirmations will be invalidated, meaning that funds which were already spent and can’t be spent again.

Timestamp Server

Building upon the timestamp server design of digital cash projects like HashCash and Bit Gold, Bitcoin implements a highly secure timestamp server. This helps to ensure that a majority of nodes in the peer-to-peer network agree on a single transaction history.

The timestamp server works through generating a cryptographic hash for a block of transactions and publicly broadcasting that hash to the entire network. Additionally, each timestamp of a given block contains the timestamp of the previous block, providing proof that a block of transactions was generated at a specific point in time. Furthermore, Bitcoin implements security measures to prevent nodes on the network from being able to lie about when transactions have been processed.

Proof of Work Mining

In the original Bitcoin whitepaper, Bitcoin creator Satoshi Nakamoto cites the importance of Adam Back’s HashCash Proof of Work system. While previous implementations of PoW like HashCash were innovative, Bitcoin still needed to resolve a few security challenges related to consensus.

First, due to numerous security concerns with SHA-1, the Bitcoin network had to implement a newer hashing algorithm called SHA-256. Additionally, Bitcoin needed to be able to ensure that transactions could still be processed by honest nodes, even if dishonest nodes existed on the network. Known as the Byzantine Generals Problem, this had been one of the most difficult security challenges in computer science for decades. If the Byzantine Generals Problem couldn’t be solved, the double spending problem couldn’t be fully solved either.

To solve both the Byzantine Generals Problem and the double spending problem, Bitcoin adds a competitive aspect to Proof of Work consensus called cryptocurrency mining. On the Bitcoin network, cryptocurrency miners attempt to solve a complex mathematical puzzle as a way to earn block rewards (a payment made in that blockchain's native coin). In the case of the Bitcoin network, miners who generate blocks and verify transactions receive BTC. This provides a financial incentive for nodes (miners in this case) to remain honest. If at least 51% of nodes remain honest, it becomes nearly impossible for any user to spend the same funds twice.

More Blockchain Networks And Consensus Protocols Follow

Although Bitcoin became the decentralized digital cash network to solve the double spending problem, many new blockchain networks began to emerge throughout the 2010s. While most of the fundamental technologies (e.g. distributed ledger, confirmations, and timestamp server) remained the same as Bitcoin, other networks have continued to introduce new approaches to consensus. Blockchain consensus protocols, namely Proof of Stake (PoS) and Delegated Proof of Stake (DPoS), have become viable alternatives to Proof of Work. They have also introduced some improvements for solving the double spending problem and increasing the overall security of blockchain networks.

Common Attack Vectors For Double Spending

Blockchain networks generally offer an extraordinarily high level of security against double spending. Nonetheless, double spending is still possible in a few scenarios. There are three common double spend attack vectors to consider.

51% Attacks

A 51% attack (sometimes called a majority attack) is the most common type of double spending attack. 51% attacks occur exclusively on PoW-based networks, although a similar attack called a Nothing-At-Stake attack occurs on PoS-based networks.

Anytime a miner or group of miners (known as a mining pool) is responsible for generating more than 51% of a PoW-based network’s computational power (also known as hash rate), a 51% attack becomes a possibility. Malicious actor(s) could then use this majority power to try to reorganize a blockchain’s transaction history. Because attackers are able to spend the same coins or tokens twice, they can then sell the counterfeit virtual currency for a profit on a centralized exchange.

In theory, this should be very difficult to accomplish. Indeed, executing a 51% attack is practically impossible on large blockchain networks like the Bitcoin network. That’s because there are so many miners and mining pools that it’s difficult to gain a majority. Additionally, the cost required to gain a majority of computational power is too expensive, making it even more impractical.

However, on smaller networks, 51% attacks are quite common because less coordination between miners and fewer resources are needed for attacks. It’s also easier for malicious actors to rent the necessary computational power from sites like NiceHash, meaning that the costs of launching a 51% attack are greatly reduced.

Race Attacks

A race attack occurs when a recipient accepts a payment before receiving a sufficient number of block confirmations. To execute a race attack, a sender sends two transactions nearly simultaneously. The first transaction goes to the recipient’s public address, and the second transaction goes to another public address that is actually owned by the sender.

If miners in the network validate the second transaction, the first transaction will become invalid. Thus, the recipient won’t actually receive any funds from the sender even though they expected to. The race attack is mainly a potential security issue for in-store transactions (e.g. at coffee shops or restaurants) or other scenarios where transactions need to be processed quickly. For most online transactions or scenarios where the recipient can wait for a few block confirmations, a race attack is not a practical threat. Additionally, blockchains that process transactions more quickly are more likely to avoid race attacks.

Finney Attacks

Similar to a race attack, a Finney attack occurs when a recipient accepts a payment before receiving a sufficient number of block confirmations. However, a Finney attack requires a more unlikely sequence of events to occur, which makes it even less of a practical threat.

To execute a Finney attack, a miner with significant resources or a large mining pool needs to pre-mine one transaction into a block without broadcasting it to the network. The miner must spend those same funds in a second transaction and later broadcast the previously mined block from the first transaction. If the attack is successful, the first transaction becomes invalid.

If you'd like to learn more about blockchain technology and keep up with Komodo's progress, subscribe to our newsletter. Begin your blockchain journey with Komodo today.