Attack the Block

Jeevan Pillay
4 min readAug 28, 2019

Bitcoin, very conventionally, employs a decision that the miners adopt the longest chain rule, which states that the greatest proof of work effort invested in a chain must be chosen as the valid chain. This means that an eventual agreement must be reached by all nodes, whereby, nodes decide on the longest chain to be the ONLY valid chain.

Picture by mangoresearch.co

When a block is transmitted onto the Bitcoin network by a miner, it is said that that block has a depth of 1 block. Therefore, with each subsequent block, the number of blocks deep is increased by one. This forms the basis of what we now know as confirmations.

In an optimal environment, Bitcoin’s transaction layer on the blockchain is said to be irreversible and final. With that, the entire structure of the blockchain actually exists to produce a history of transactions that is computationally impractical to modify [2]. Transactions can also be final, whereby, merchants do not need to collect personal information from users as it is pretty much computationally impossible to reverse (or double spend) a transaction provided that the business enforces strict payment rules like >6 confirmations before accepting a payment. However, in practice as miners can reorganize the block structure depending on the computational power that they control.

Therefore, it’s very important for merchants and traders to wait for confirmation before accepting payments from users. However, the amount of confirmations that are chosen by merchants is very much dependent on the risk management of the business, the blockchain architecture and the relationship of availability against consistency.

DOUBLE SPENDING ATTACKS

Defintion
The ability of a malicious user to successfully spend some amount of money more than once.

In the Bitcoin network, we tend to wait for a certain amount of confirmations before validating a transaction (or payment). This ensures that it becomes computationally impossible to revert or double-spend some amount of money.

How many confirmations then?

Well, in the bitcoin community, we generally accept 6 confirmations (or 6 blocks deep) which approximates to 60 minutes before validating a transaction.

Wait, 60 minutes? What! How am I going to buy coffee then? Maybe we should look at Bitcoin as a store of value instead of a currency?

RACE ATTACK

This attack occurs when traders or merchants accept a payment immediately without taking confirmations into account. In other words, accepting payment with 0 confirmations.

An attacker may create two same transactions and broadcast one to the merchant and another to the network.

Transaction 1: Send 1 BTC to Merchant A
Transaction 2: Send 1 BTC to Himself

It’s quite likely that the second transaction, Tx2, might be mined before the first and accepted as the final transaction. Merchant A, on the other hand, has accepted an unconfirmed transaction as payment.

This kind of attack is very easy to perform if the attacker has a direct connection to Merchant A’s node.

FINNEY ATTACK

This attack also occurs when merchants or traders accept payments with 0 confirmations.

An attacker must be able to generate blocks of his own and control two addresses in the bitcoin network, Address A and Address B.

The attacker mines a new block and includes a transaction, Tx1, from Address A to Address B. But, the attacker doesn’t broadcast the block.

Instead, he makes a new transaction, Tx2, from Address A to the merchant or traders’ address. Since the merchant or trader doesn’t wait for any confirmations, he accepts the attackers’ transaction.

Now, the attacker will broadcast the block with Tx1 to the network.

However, this attack is pretty difficult to use in practice as it requires the attacker to have a high hash rate (since he creates his own blocks), and most merchants now tend to require a few confirmations.

VECTOR76 ATTACK

It is a combination of Race Attack and Finney Attack that also occurs when merchants or traders accept payments with 1 confirmation.

Prerequisites: 2 Full Nodes.

Node A: Connected to Merchant A’s node
Node B: Connected to the rest of the network

It starts off very similar to Race Attack, whereby an attacker may create two transactions that spend the same coin.

Tx1: Send 50 BTC to Merchant A
Tx2: Send 0.1 BTC to Himself

However, neither transactions are broadcasted yet.

The attacker begins hashing the transaction into a new block till he is able to mine the block. Once that happens, he runs these two operations concurrently.

On Node A: The 50 BTC is sent to Merchant A’s node
On Node B: The 0.1 BTC is sent to the rest of the network

Chances are the rest of the network solves the puzzle first and creates a new block, thereby, accepting the block with the 0.1 BTC as a valid transaction. Basically, rejecting the 50 BTC transaction.

At that instant, the attacking miner then broadcasts the previously withheld block from Node A to the Merchant.

Merchant A will then deposit the 50 BTC into the attackers’ wallet. The attacker immediately withdraws the 50 BTC (Note, Merchant A will send BTC from another unspent coin).

Eventually, the Bitcoin mining network will solve yet another block and that blockchain (most likely) knows of the 0.1 XBT and thus rejects the 50 XBT transaction.

ALTERNATIVE HISTORY ATTACK

This is the most probable attack in blockchains, however, it requires very high computational power, therefore becoming very costly.

The attacker basically creates a transaction to a merchant, then he creates a new fork on that block. Then, the attacker will mine this privately till he gains the longer chain control over the network. He then releases his fork and regains his coins.

This attack is very destructive when more than 51% of the mining power is controlled by the attacker, in other words, 51% attack (or majority attack).

REFERENCES

[1] Nakamoto, S. (2008) Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf

[2] ”Irreversible Transactions — Bitcoin Wiki”, En.bitcoin.it, 2019. [Online]. https://en.bitcoin.it/wiki/Irreversible_Transactions#Vector76_attack

--

--