Double Spending
Last updated
Was this helpful?
Last updated
Was this helpful?
In a digital cash system, double-spending is a possible problem if the same monies are spent to two different beneficiaries at the same time. In the absence of sufficient countermeasures, a protocol that does not overcome the problem is fundamentally compromised — users have no method of verifying that the cash they've received have not already been spent elsewhere.
For digital cash, ensuring that specific units cannot be replicated is of the utmost significance. If Alice received 10 units, copied and pasted them 10 times, and suddenly had 100 units in her control, the entire system would be in jeopardy. She can't do this if she can simultaneously send 10 units to both Bob and Carol. This type of conduct must be prevented if digital money is to work properly.
Double-spending attacks can't happen when the Bitcoin protocol is used as anticipated. Meaning that the sender can't cancel transactions that are waiting to be confirmed in a block. Because of the unreasonably high hashing power required to "reverse" the blockchain, this would be impossible.
Unconfirmed transactions are targeted by a small number of double-spending attacks, but they are rare. An online retailer may not have the patience to wait for a block of transactions for low-value purchases. It's unlikely that a busy fast-food joint can afford to sit idle while the network processes each order. As a result, if a business accepts "immediate" payments, they risk double-spending. A person may place an order for a burger, pay for it, and then transfer the same amount of money to their own bank account. Because of the greater charge, this new transaction is more likely to be validated first, nullifying the validity of the preceding one.
There are three popular methods for performing a double-spend:
when a single entity or organization manages to control more than 50% of the hash rate, which allows them to exclude or modify the ordering of transactions. Such an attack is highly unlikely on Bitcoin, but has happened in other networks.
Race Attacks: two conflicting transactions are broadcast in succession, using the same funds – but only one transaction gets confirmed. The attacker's goal is to invalidate the payment by only validating the transaction that benefits him (e.g., sending the same funds to an address that he controls). Race attacks require the recipient to accept an unconfirmed transaction as payment.
Finney Attacks: an attacker pre-mines one transaction into a block without broadcasting it to the network immediately. Instead, he spends the same coins in another transaction and only then broadcasts his previously mined block, which may invalidate the payment. Finney attacks require a specific sequence of events to occur and are also contingent on the recipient’s acceptance of unconfirmed transactions.