The term “double spending” is a familiar one in the digital currency world, simply referring to a situation where a certain amount of digital currency is used twice. Double spending is unlikely to happen when physical cash is used for transactions.
What is double spending?
It is crucial that a digital currency system contains mechanisms to safeguard against double spending. Entire systems could collapse should such protocols not be in place.
Bitcoin is well-designed to prevent double-spending attacks, if its protocol is used as intended. Because the transactions on Bitcoin are recorded in blocks and the network uses Proof of Work as its consensus mechanism, recorders (known as miners) have to complete a hash computing process in order to obtain the right to record the transaction. Once the transactions are recorded, it will be distributed to different nodes.
How does double spending affect Bitcoin?
With such a mechanism in place, miners must have access to stronger computing power than others should they wish to be granted recording rights. Once a transaction is successfully recorded and confirmed in a block, it would be extremely challenging for other miners to change this record as massive amounts of computing power would be needed.
This mechanism, however, does not constitute a fail-safe prevention against double spending. As the transaction recording process of Bitcoin is one that takes time, double spending could still occur before transactions are successfully recorded, especially when transactions involve relatively small amounts of Bitcoin.
For example, Bob orders one hamburger and pays for his purchase with Bitcoin. However, as the restaurant is too busy to wait for every transaction to be fully recorded, they give the burger to Bob directly without waiting for the transaction to be complete.
If Bob immediately sends the same amount of Bitcoin to another address with a higher transaction amount attached, the later transaction will likely be recorded and closed by miners – resulting in the invalidity of the previous transaction.
Different types of double spending
- 51% attacks: When a single entity or organization manages to control more than 50% of the hash computing power on a chain, this allows them to change the transaction sequence or even delete the transaction. The occurrence of such a scenario is nearly impossible on the Bitcoin network, but has happened on other blockchain networks.
- Race attacks: Customer A’s double spending case mentioned above is a typical race attack – a user broadcasts two conflicting transactions with the same amount at the same time, and tries to get one confirmed in order to invalidate the other. Race attacks take advantage of the time difference and require the receiver to confirm the transaction before the transaction is recorded on blocks.
- Finney attacks: An attacker pre-mines one transaction into a block without broadcasting it to the network immediately. Instead, he spends the same amount in another transaction and only then broadcasts his previously mined block, which may invalidate the former payment. Finney attacks require a specific sequence of events to occur and are also contingent on the recipient’s acceptance of unconfirmed transactions.
How to prevent double spending?
1: Wait for the block confirmation
The best solution to solve the double spending issue is to finish the deal after the transaction is confirmed by blocks. Once the transaction is confirmed, the coins can’t be double-spent, as ownership is assigned to a new user – and the entire network can verify this. This is a solution adopted by transactions involving large amounts.
2: Increase 51% attacker’s costs
As mentioned above, when attackers control more than 50% of a blockchain network’s hash computing power, it is theoretically possible for them to delete a transaction that has been confirmed by blocks. However in reality, such a scenario would be near impossible as 51% attacks and their required computing power would come at a high monetary cost.
There could sometimes be transactions deemed to be of sufficient value for attackers to invest in the required computing power. In such a case, users should wait for more blocks to confirm the transaction’s validity, in order to increase the cost to attackers.
For example, hacker B spends a large amount of resources to acquire 51% of a blockchain network’s computing power and hence gets a 51% chance to invalidate a transaction. However, should he need to invalidate two blocks, his change would halve to 26% and he would then need to invest in more resources to obtain the required computing power for his purposes.
Of course, the scenarios mentioned above are theoretical. In reality, dealers will have to determine how many blocks a transaction requires in order to be validated. If a transaction involves a small amount, perhaps block confirmations need not be attended to immediately. But if a large amount is involved, it would be prudent to wait for more block confirmations before proceeding with the deal.