When 1 equals 2
Blockchain and the double spending problem
The digital world is full of mysteries. What you see on the internet with every site, search, and download is just the 4% that isn’t the dark web. Funny how the thing that gave access to “everything” is really just 4%.
The point I’m getting at, is that the digitization of everything made the world more opaque and less transparent. Internet juggernauts and Dotcom goliaths just take advantage of that obscurity and feed us applications and info that we think are making the net transparent. Recently though, we’ve started to pick up on their gimmicks.
Blockchain can be the windex of the internet, allowing for transparency which leads to accountability which leads to trust. Trust was and is the first and foremost element of mutual growth. After all, how could the first money ever be used if the receiver didn’t trust that it represented value? Eventually this went a step further and invented credit; now, you can trust somebody by creating value out of thin air. Spending money or credit is easy; we debit our balance by the agreed upon amount and credit the merchant’s balance by the agreed upon amount. It’s this step that digital money is struggling to keep up with.
But when you share or exchange value online, there is no debiting of anything, there is only crediting. Why? Because sharing or exchanging anything digital just means taking a copy of said value, and giving the copy to said creditor. Instead of just Bob having a copy of my favorite book saved on my computer, Alice also has a copy. Instead of Bob owning just 1 dollar, Alice also owns 1 dollar.
Now it gets problematic. Items retain value from scarcity among other variables, but if all of a sudden I can subvert this scarcity by creating a copy of said item, how could it sustain its value? This artificially inflates the market with value items that did not previously exist eventually causing the demise of its system.
This is the double spending problem.
How to make 1 equal 2
There are different ways to achieve this in every system, but in Bitcoin’s Blockchain, there are a couple known ways.
- Majority Attack
- Race Attack
- Finney Attack
- Alternative Facts Attack
- Vector76 Attack
- …
A while ago, I wrote an article on LinkedIn outlining the possible attack vectors and weaknesses of Blockchain in general. I basically realized what I wrote was totally misleading to the point where it’s borderline wrong. I made it seem as if 51% attacks and Double spending are two different attack vectors when in fact, they are both very related. 51% attacks are actually a subset of Double spending problems.
The whole point of a double spend is to spend money that doesn’t actually exist, thereby creating value from nothing. You can think of it like taking a dollar bill and photocopying it. You now have two (albeit questionable) dollars.
1. 51% Attack
Actually even the title 51% attack is misleading; a more accurate title that is used quite often is >50% attack or the Majority Attack. It’s a lot easier to read and say isn’t it? Majority Attack is a better name because Bitcoin’s protocol isn’t the only Blockchain vulnerable to this kind of attack. Some protocols can survive only a mere 1/3 of maliciously collaborative nodes, while others can handle upwards of 2/3 of bad actors. Even 50% isn’t the minimum requirement for a successful attack. Vitalik thinks a more accurate number is 49.5% due to propagation error.
Someone who successfully controls 51% of a network then has power to do more than just double spend. The perpetrator could double spend, isolate other nodes, create a false-chain, or spam the network. This just defeats the protocol and renders the entire system, including its currency or token useless.
2. Race Attack
The Race Attack essentially forces the receiver or merchant to accept unconfirmed transactions as payment. The attacker sends unconfirmed transactions to pay the victim simultaneously broadcasting a conflicting transaction to the network. The receiver, who would have seen the reception of funds is under the illusion of getting paid, while the rest of the network predominantly saw the false broadcasting transaction first. Thus the receiver or merchant is unlikely to actually get paid.
This attack is much more effective if the attacker has a direct connection to the victim’s node, or the attacker deposits the conflicting transaction directly to miners.
3. Finney Attack
Infamously named after the proposer of the attack (Who is also rumored to be Satoshi Nakamoto in disguise), the Finney attack is a an unpreventable risk every receiver has to face when being sent value from a potentially malicious actor. This type of attack requires surgical level precision and timing.
Essentially, say the attacker, Sam, controls two nodes with two addresses; A and B. Sam would commit to a transaction from address A to address B (both of which is owned by the attacker), but he doesn’t broadcast the transaction to the rest of the network. Instead, Sneaky Sam uses address A to pay for your goods, services, etc.
At this point, all you, the good guy vendor, can do is wait for any double spend potential (Hint: you won’t hear any) before sending the goods. The attacker can now broadcast his transaction A — B, which will be be accepted into the new block before yours.
4. Alternative Facts (History or Transaction) Attack
Ok It’s not actually called Alternative Facts Attack reminds me of Trump so I’m going to coin it. One can think of this attack like a Dragon Ball Z Kamehameha
The attacker uses a transaction address which pays the merchant, simultaneously private mining an alternative blockchain fork in which a fraudulent double-spending transaction is included instead. In this scenario, the attacker is preparing the attack while in the middle of a transaction, like a Kamehameha being prepared in the middle of a fight.
The merchant might wait a bit before sending the product to check for double spends. If the attacker happened to mine more blocks than the number of blocks the merchant waited for, he releases his fork and regains his coins.
If the attacker can’t mine enough, he or she can always try to continue extending his fork with the hope of being able to catch up with the network. If the attacker is smart, he’ll cut his losses and give up on trying to outpace the rest of the network, because the longer he tries to drag this out, the theoretical probability of success is diminished over time. The opportunity cost of electricity and money probably isn’t worth a shot.
5. Vector76 Attack
It’s too expensive and difficult, don’t bother trying or knowing about it.
TLDR
The attacker has to put a lot of effort first into monitoring the propagation rates of an off-chain application before setting up a connection with a mining pool. The attacker then mines a block with a deposit of some money correctly but withholds the broadcast (similar to the Finney attack). The attacker then waits to match his block broadcast with that of a mining pools. The two correct blocks create a fork in the network. At this point, the attacker’s block has been confirmed by the pool’s block as well. The attacker then withdraws the amount he originally deposited. The chain network will interpret this as valid because the pool had also broadcasted the correct block and the chain can continue on this fork. The attacker wins in either case; if the pool’s block path is continued, the attacker loses nothing. If the attacker’s block path is continued, he successfully withdraws twice the sum of money he originally invested in the attack.
Thankfully, there has only been one notable attack in the history of Bitcoin, and the developers are working to ensure another doesn’t happen again. As with any technology, Blockchain needs time not only to build a stronger defence against attack vectors, but for people to adjust and accept it as well.
