Vector76 — The Trojan Horse in Blockchain

Photo by Michael Geiger on Unsplash

Many of us who have been sold on blockchain, or specifically Bitcoin, probably got attracted to the value propositions it proclaimed.

Bitcoin is pseudonymous, decentralised, trust-less & immutable. Nobody can have access to your crypto assets, if they don’t have your private keys.

In brief, I learnt that Bitcoin is a decentralised immutable digital ledger where every node on the network will have a copy of the same ledger and that all blocks on the chain are tied to its predecessor, up to the first block, also known as the genesis block. And, according to the Bitcoin whitepaper, it is “computationally impractical for an attacker to change the (public history of transactions on the network) if honest nodes control a majority of CPU power.”

But how many of us are truly aware of the risks and potential security gaps within a proof-of-work blockchain. Since Bitcoin’s inception and the boom of the alts, we witnessed numerous occasions of centralised exchanges getting hacked. Some of the notable cases can be found here.

As I dived deeper into the world of blockchain, I realised that blockchain isn’t as picture perfect as it may seem on theory. Previously, it was theorised that it will require an attacker to command majority of the CPU power on the Bitcoin network (ie. more than 50%) in order to launch a successful attack (ie. double-spending).

However, in reality, attackers do not require majority of the CPU power to launch a successful attack. There are research papers and discussions on forums to support the case. Just to name a few, some of the known attack schemes are the Race attack, Finney attack and Vector76 attack.

The Vector76 attack

Here, I like to share briefly how a Vector76 attack is possible.

The scheme of this attack was originally suggested by a user named Vector76 in the bitcoinTalk forum to explain a possible double-spending attack on an e-wallet service provider, such as MyBitcoin,

Before diving into how the attack works, here are some pre-context about proof-of-work protocols to have a better understanding.

1. Not everyone participating in the network, or using the network to perform a transaction is required to have a full copy of the digital ledger. As of Apr 2021, the size of the Bitcoin network is 333.87 GB. Imagine that if it was the case, you will need to have a smartphone with enough storage space just to make a transaction. That is rather impractical. Participants can interact with the network as a lightweight client, without having a full copy of the ledger.
2. Propagation of information (ie. publishing of a new block) across the network is not an instant affair. Information is relayed from nodes to nodes and the propagation of information from one node to the rest of the network depends on the degree of connectedness of one node to the network. There can be significant delays for an information to be propagated throughout the network, which is one of the inefficiencies that attackers can leverage on.
3. It is possible whereby two or more competing blocks are published onto the network, resulting in a fork event. In such an event of dispute, the longest chain will be determined as valid and all the other shorter chains will be invalidated.
4. For a miner to mine a new block, it has to find the latest block that was published on the network to work on and miners will mine on the first published block they find on the network. Note, as mentioned in point 3, it is possible to have two different miners connected to different parts of the network to assume that the blocks that they find are the latest block. Both of them can be mining on different chains.
5. Miners can choose to withhold publishing the fact that they have successfully mined a new block and choose to continue mining on their own block without the network knowing, resulting in a fork. This way the network and the miner will be working on separate chain of blocks. And when the miner choose to publish, the longer chain will be considered as valid.

We shall term the chain worked on by honest miners as the honest chain and the chain done by the attacker as the secret chain. With the above mentioned in mind, a generalised Vector76 attack is as follows:

Illustration of a Vector76 Attack by Yonatan Sompolinsky & Aviv Zohar — Bitcoin’s Security Model Revisited

1. The attacker finds the latest block on the honest chain to mine on. At this point, it starts working on a secret chain with the first block containing the transaction, tx1, she wishes to revert later.
2. If the attacker realises that her secret chain is shorter than the honest chain, she will abandon the operation and find the next latest block on the honest chain to restart the operation.
3. When the attacker successfully built a chain longer than the honest chain, she will publish her secret chain to the victim’s node. At this point, the victim’s node will believe that the attacker’s chain is valid as it is the longest chain and will honour the transaction.
4. The attacker then submits a conflicting transaction, tx2, whereby the source of funds is the same as tx1, to the honest network. As the honest chain is not aware of the attacker’s chain, the honest chain will grow long enough (it is safe to assume that the honest network has a significantly higher combined hashrate power as compared to the victim’s node) for tx2 to be accepted by the network and termed as valid. This will result in tx1 being invalidated.
5. The attacker has successfully receive a promised value from the victim without sending anything in exchange.

For such an attack, the crucial step for success is to publish a secret chain that is longer than the honest chain (in Step 2), beyond that point the probability of success is guaranteed.

Measures to mitigate risk of attacks

However, it is not all doom and gloom for merchants or recipients of a transaction on the network. We don’t have to be at the mercy of these attackers. There are varying degree of measures that can be taken to mitigate the risk of being a victim of such attacks.

Running a full-node with good connectivity to the network

By running a full node, you will have the latest full digital ledger for you to fact-check the validity of blocks that you are made aware of on the network. With good connectivity to the network, the likelihood that you are ‘listening’ to the latest and true block available on the network is higher, which reduces your likelihood of being manipulated because of information gaps between yourself and the network.

Setting a reasonable confirmation policy

Confirmation is the number of successful blocks that follows after a block with the transaction embedded in it. You can choose to honour the transaction after a set number of confirmations.

Screenshot of BTC deposit on Binance

Take for example depositing BTC on Binance, Binance will only honour the transaction after 1 network confirmation and only until 2 confirmations are made, an equivalent amount can be withdrawn.

You may determine the number of required confirmations according to the value of the transaction. The more confirmation required, the less likelihood that the transaction can be reversed. But with more confirmations required, the waiting time will be longer as well, which will affect user’s experience. Hence, there need to be a balance between user experience and security.

Take command of the time of transaction

Lastly, you can choose to decide the time of transaction, such that it is seemingly random to the sender. That way, this can prevent attackers from timing their transactions, allowing them to publish a secret chain only when they manage to have a longer chain than the honest chain.

Conclusion

The battle between attackers and those against attackers is a dynamic affair which will constantly evolve like a game of chess. What I have shared is only the tip of the iceberg and there is so much more to know about.