What is double-spending?
Double spending is a potential problem in cryptocurrency ecosystems, where the same resources are spent by two recipients at the same time. Without adequate countermeasures, there is a fundamentally compromised protocol that will not solve the problem - users have no way of verifying that the resource they received has not been used elsewhere.
As far as cryptocurrencies go, it is extremely important to ensure that specific units cannot be duplicated. The whole system would be disrupted if, let’s say Alice could accept 10 units, copy them and add them 10 times to create 100 units. Such a scheme simply cannot work if it can send the same 10 units to Bob and Carol at the same time. For cryptocurrencies to work, there must be mechanisms in place to prevent this.
How to prevent double-spending?
Centralized approach
Implementing a centralized solution is significantly simpler than decentralized alternatives. This usually means that one supervisor who manages the system manages the issuance and distribution of units. A good example of a centralized solution to this problem is David Chaum's eCash solution.
The bank can use blank signatures to issue users with digitizing assets that mimic cash (capable of anonymous and equivalent exchanges) - as detailed by David Chaum, a cryptographer in the 1982 Blind Signatures for Untraceable Payments.
In this case, if the user (let's call him Bob) wishes to receive $ 100 in digital cash, he is obliged to inform the bank first. If Bob has enough funds in his account, the bank will generate a random number (or more numbers in case of smaller values). Suppose he creates five numbers, each of which is assigned a value of $ 20. To prevent the bank from tracking specific units, Bob obscures random numbers by adding a blind factor to each of them.
He then submits this information to the bank, which posts $ 100 to the account and signs reports confirming that $ 20 can be paid for each of the five pieces of information. Bob can now spend the funds issued by the bank. So he goes to a restaurant and buys a $ 40 meal.
Bob can remove the blind factor and expose a random number associated with each digital cash "receipt" that serves as a unique identifier for each unit (similar to a serial number). Two of these identifiers are revealed to a restaurant, which must immediately present them at the bank to prevent Bob from spending them at another merchant. Subsequently, the bank will check the validity of these signatures. If all goes well, the bank will credit the restaurant with $ 40.
Setting up Chaumov eCash solution can be useful for private transfers. However, it lags behind in terms of flexibility, as the bank is the central point of failure. The bill of exchange issued alone does not cost anything, because its value is derived solely from the bank's willingness to exchange it for dollars. Customers are at the mercy of the bank. This is a problem that cryptocurrencies aim to correct.
Decentralized approach
It is difficult to prevent funds from being spent more than once in the crypto ecosystem. Equivalent participants must coordinate a set of rules that will prevent fraud and motivate all users to act honestly.
The biggest innovation introduced in Bitcoin's white paper was the solution to this problem. Although not stated directly, Satoshi designed a structure that is currently commonly known as a blockchain.
Blockchain is really just a database with certain unique properties. Network participants (called nodes) run specialized software that allows them to synchronize their copy of the database with their peers. As a result, the entire network can audit transaction history extending from the genesis block. Public access to a blockchain makes it easy to detect and prevent fraudulent activities, such as double transactions.
When a user sends a transaction, it is not immediately added to the blockchain. It must first be included in the block through mining. Therefore, the recipient should consider the transaction valid only after it has been added to the chain. Otherwise, there is a risk of losing funds, as the sender can spend the same coins elsewhere.
Once the transaction has been confirmed, the coins cannot be spent twice because the ownership is assigned to the new user and the whole network can verify this. For this reason, many recommend waiting for confirmation from more nodes before accepting payment as valid. Each subsequent block drastically increases the amount of effort required to modify or rewrite the string (which can occur during so-called 51% attacks).
Let's go back to the scenario from the restaurant. Bob returns to the restaurant and this time he notices a "Bitcoin Accepted Here" sticker on the window. He recalls that he had enjoyed eating here last time, so he would order the same meal again. Only this time paying 0.00074 BTC instead of $ 40.
The restaurant will show him the public address to which he must send funds. Bob is sending this transaction, which is basically a signed report stating that the 0.00074 BTC that Bob owned now belongs to the restaurant. Anyone who came in contact with a transaction signed by Bob can now verify that Bob actually owned the coin and was authorized to send it.
As already mentioned, a transaction is valid only if it is included in a block that is confirmed. Accepting unconfirmed transactions is similar to accepting $ 40 in eCash from the previous example, but without immediate payment at the bank - in other words, it allows the sender to spend these funds elsewhere. Therefore, it is recommended that the restaurant waits for at least 6 confirmed blocks (which could take approximately one hour) before accepting Bob's payment.
Double spending and Bitcoin
Bitcoin is meticulously designed to prevent double-spending attacks, at least if the protocol is used as intended. This means that if individuals are waiting for a transaction to be confirmed in a block, there is no easy way for the sender to cancel it. To do this, they would have to "reverse" the blockchain, which requires an unrealistic amount of hashing force.
However, there are several types of double-spending attacks targeting parties that accept unconfirmed transactions. For example, for low-value purchases, the merchant may not want to wait for transactions to be included in the block. A busy fast food restaurant probably cannot afford to halt until the network confirms every purchase. Therefore, if the company allows "immediate" payments, it opens itself to possible double-spending attacks. Someone can order a hamburger, pay for it and then immediately send the same means to their address. With a higher fee, this new transaction is likely to be committed first and will therefore invalidate the previous transaction.
There are 3 types of double-spending attacks
51% attack - once one entity or organization can control more than 50% of the hash value, they are allowed to exclude or change the order of transactions. This attack is very unlikely on Bitcoin, but has happened in other networks.
Race attacks - two opposing transactions are sent sequentially using the same means - but only one transaction is confirmed. The attacker's goal is to cancel the payment only by confirming the transaction from which he benefits (for example, by sending the same funds to the address he is checking). These attacks require the recipient to accept an unconfirmed transaction as payment.
Finney attacks - an attacker extracts one transaction into a block without immediately sending it to the network. Instead, he spends the same coins in another transaction and only then sends his previously mined block, which can invalidate the payment. These attacks require a specific sequence of events and are also conditional by the recipient accepting unconfirmed transactions.
As we can see, a merchant waiting for blocks to be confirmed will significantly reduce the risk of falling victim to double-spending.
Sources: academy.binance.com, investopedia.com, en.bitcoinwiki.org, coinsutra.com
Comments