Double spending is a term that is familiar in the world of digital currency. It simply refers to situations where a certain amount of digital currency is used twice. Double spending is unlikely when physical cash is used to make transactions.
What’s double spending?
It is essential that any digital currency system has mechanisms to prevent double-spending. Without such protocols, entire systems could be destroyed.
If the protocol is followed, Bitcoin is well-designed to protect against double-spending attacks. Bitcoin transactions are stored in blocks. The network uses Proof of Work to consensus its consensus mechanism. To be able to record the transaction, recorders (also known as miners) must complete a hash computing process. Once transactions have been recorded, they will be distributed among different nodes.
What does double spending mean for Bitcoin?
If miners wish to have recording rights, they must have access to more computing power than the rest. It would be very difficult for other miners, once a transaction has been successfully recorded and confirmed in the block, to alter this record.
However, this mechanism does not guarantee that double spending will be prevented. Double spending can still occur even though transactions are recorded successfully in Bitcoin. This is especially true if transactions involve small amounts of Bitcoin.
Bob, for example, orders one hamburger and then pays with Bitcoin. The restaurant is too busy to record every transaction, so they give Bob the burger immediately without waiting.
Bob can send the same amount of Bitcoin immediately to another address, but the transaction amount will be higher. This will cause the transaction to become invalid.
There are many types of double spending
- 51% attacks: An attack in which a single entity or organization controls more than half of the chain’s hash computing power. This allows them to modify the transaction sequence, or delete transactions. Although it is almost impossible to have such an event on Bitcoin, it has been seen on other blockchain networks.
- Race attacks: The double spending case of Customer A, which was mentioned above, is a typical example of a race attack. In this instance, a user broadcasts two transactions with the exact same amount and attempts to get the first confirmed to invalidate the second. Race attacks exploit the time difference to require the receiver to confirm the transaction before it is recorded on blocks.
- Finney attacks: An attacker premises a transaction into a block and does not broadcast it to the network immediately. Instead, he will spend the same amount in another transaction, and then broadcast his block. This could invalidate the previous payment. Finney attacks are dependent on the recipient accepting unconfirmed transactions.
How can you prevent double spending?
1: Wait until the block confirmation
To solve double spending, the best way to resolve the problem is to close the deal once the transaction has been confirmed by blocks. The transaction has been confirmed and coins cannot be double-spent. Ownership is transferred to a new user, which can be verified by the whole network. This solution is used for transactions with large amounts.
2 – Increase 51% Attacker’s Costs
It is theoretically possible to cancel transactions that have been verified by blocks if attackers hold more than half of a blockchain network’s hash computing power. In reality, however, such an outcome would be almost impossible because 51% of the network’s computing power is under attack and would incur a significant financial cost.
Sometimes transactions may be deemed sufficient to allow attackers to purchase the necessary computing power. To increase attackers’ costs, users may need to wait until there are more blocks before verifying the validity of transactions.
Hacker B, for example, spends large amounts of resources to obtain 51% of the blockchain network’s computing capacity and thus has a 51% chance of invalidating a transaction. His change would be reduced to 26% if he had to invalidate two blocks. He would then have to spend more to get the computing power he needs.
These scenarios are only hypothetical. Dealers will need to decide how many blocks are required for a transaction to be validated. Block confirmations may not be required if a transaction is small. If a significant amount is involved, however, it might be prudent to wait for additional block confirmations before proceeding with a deal.
