Ethereum hard fork problem emerges: hard fork may lead to replay attack

Yesterday xETHeREALx posted a thread on Reddit about possible replay attacks on Ethereum hard forks. Some of his/her concerns seem a bit exaggerated, but there are some quality attack vectors worth discussing.

Cross-chain replay

In simple terms, if one fork has a valid transaction, the problem is that this transaction may be 'replayed' to the other fork, thus potentially causing chaos.

We can imagine transactions from the 'main' fork going into the 'old' fork, and vice versa.

In the typical case of a fork, the fork is resolved very quickly. When a hard fork triggers social problems, a small number of people may interrupt the operation of the fork for a period of time, or even interrupt it forever.

Essentially, most people fork, while others choose to stay where they are. Could this happen with Ethereum? xETHeREALx points to some support being expressed for the 'old' chain. If exchanges offer support for the 'old' chain, then there will be liquidity, and that forked coin will have some value, which could drive additional support; maybe people will trade their alt-universe coins for Bitcoin, or at least for 'real' ether.

We are in somewhat uncharted territory here, as to my knowledge there is no expressive transaction language for blockchain forks that supports two chains.

What could possibly go wrong? I look forward to finding out. Here are some of the angles of attack that I'm worried about.

Replay Attack

A replay attack is simple - find a valid transaction on one chain and provide that transaction to another chain. Since there is nothing that can be used to distinguish which chain the transaction came from, in the case of a reversion, both chains will do the same thing.

If an exchange has already paid someone on one chain and then issues a withdrawal command on another chain, it will result in a double payment. Similarly, any function call can be duplicated in this way.

We are now neglecting the issue of trade;

“Exchange Infiltration” Attack

If an exchange wanted to participate in both chains, they would have a real problem: if user A deposited on the 'old' chain, and then withdrew, then they could take the withdrawal payment and use the 'new' chain to withdraw, doubling the funds (waiting for the exchange rate difference between the two ethers to appear). This is the core attack vector mentioned in the Reddit article.

This isn’t the only worrisome move; especially since arbitrary function calls can be replayed, a lot of interesting things could happen to the participants of the two chains.

Nonces

Ethereum doesn't keep track of individual transaction outputs ( txos ), but it does have a special mechanism for identifying transactions: every transaction issued by an address has a 'nonce' - this number increases with each transaction.

If a transaction publishes a nonce that is too low — for example, because a different transaction has already been offered — the transaction is ignored and considered invalid.

If a transaction publishes a nonce that is too high — for example, we haven’t seen some intervening transactions yet — then the transaction will sit in the transaction pool, waiting to be processed.

What does this mean for a cross-chain withdrawal attack?

A working cross-chain attack

So, in order for this to work, we need:

1. A participant participating in two chains at the same time

2. A way to repeatedly attack the victim nonce

3. A good time

Note that we don’t even need an exchange to participate in the “old” chain — only the attacker needs to use two chains. Let’s imagine the following participants:

1. ‘Modern’ exchanges that only run on the main chain

2. ‘Principled’ exchanges that only run on the old chain

3. ‘Attacker’ on two chains at the same time

Now, how do we proceed?

1. The attacker withdrew funds from the ‘Modern’ exchange to an address they controlled on the main chain.

2. The attacker replays the withdrawals, and all withdrawals need to update the nonce to the correct value on the 'Principled' chain.

3. The attacker now has the same amount of ether on both chains.

4. The attacker sent the Ether to the 'Principled' exchange, sold it, and converted it into Bitcoin.

The attacker gains additional value.

Note that nonce management is very complex; if an attacker cannot reach a suitable nonce value, the transaction will be put into the transaction pool. If a 'Modern' exchange participates in the 'Principled' chain, they can increase the nonce and pass the withdrawal .

Worrying about timing in a distributed system is never a good thing, and this complexity is not something that cryptocurrency exchanges are used to worrying about today, they just treat the time delay chain as basically unchanged and go about their business. Needless to say, this is a real concern.

On the other hand, do they need to worry about what happens to their old alt-universe coins ? Probably not - they are committed to the 'Modern' chain. Anything that creates disruption on the 'Principled' chain, creates value for the 'Modern' chain.

If these attacks become widespread, presumably the 'Principled' coin will depreciate and the attacks will take care of themselves to some extent.

Even if it's not, you should care about the 'Principled' chain.

There is a very cheap attack from Principled, which is spam in modern terms. The Principled chain will include a large number of transactions. These transactions can be placed on the main chain, skipping all transactions with consecutive nonces. Since generally speaking, Principled participants will not participate in the Modern chain, these txs will be placed in the tx pool, causing congestion.

This is an incredibly simple and cheap attack; other network participants will create valid transactions for the attacker.

Mitigation 1: Stop accepting future nonce txs

First, stop taking out order txs; that responsibility should be on the client. This equivalent has existed in Bitcoin for a long time. It seems like sensible infrastructure management that can only help.

Mitigation 2: nonce management or cold storage

If exchanges want to reclaim the ability to stake their own ether on the 'Principled' chain someday, it would make sense to drastically increase their nonces, by at least a year, by spending or calling something cheap. This would consume ether, but also leave options open for the future.

Alternatively, exchanges could create a 'Principled' cold storage address and send everything to this address, rendering withdrawal replays invalid.

If you want to use less forks, this seems like a good idea.

There's still a lot to learn

I bet 10 ether that there are a lot of interesting bits and pieces of function calls and cross-chain replays, and things are going to get really interesting and weird.

I have urged the Ethereum community to abandon the failing fork, especially exchanges or other organizations that might offer financial incentives to follow the failing chain.