How vDice handles Ethereum Classic and Replay Attacks
So Ethereum Classic is a thing now. Never a dull moment in the crypto-sphere, hey?
This question has come up a lot in the last 48-hrs.
In short, at the moment we don’t support Ethereum Classic. And we’ve already implemented a solution for Replay Attacks.
Our site and Smart Contracts are still live, processing bets.
We use an Oracle to process bets. With them we have already implemented a solution.
Allow us to explain…
What is Ethereum Classic?
So essentially now we have 2 different chains; ETC and ETH. They split at a given point in time.
This means that they were exactly cloned (other than for the DarkDAO emptying Tx), at a single point in time.
So if you had an ETH wallet with, let’s say, 100 ETH in it, at the time of the hardfork, today you have 100 ETH on both the ETC and ETH chains.
Now, as an example, let’s say that you transfer 10ETH from your wallet A to another wallet B on the ETH network.
You will have 90ETH in A and 10ETH in B on the ETH network. but still 100ETH in wallet A and 0ETH in wallet B on the ETC network.
Remember, these are now 2 completely different networks; different nodes, different miners and different blocks.
What is a Replay Attack?
The issue is that now anybody could potentially make your ETH transaction (A -> B) valid on ETH and re-broadcast it on ETC, where it’s valid as well!
This is a replay attack.
It’s very easy to do. A single party could listen to all Tx on ETH and replay all of them on ETC at ~0 cost.
One solution is to use some special contracts (Hard-Fork-‘Aware’) which split your funds to a new network specific address.
— vessenes (@vessenes) July 25, 2016
So that from A you move your funds to A1 on ETC and to A2 on ETH. Still, for already deployed contracts it’s not trivial.
But vDice is relaying on Oraclize query IDs to identity queries. And Oraclize did take action before the Hard Fork to address the above issue.
Oraclize query IDs on ETC and ETH are different.
Anybody could replay an Oraclize Tx on ETH and send them to ETC. But because the Oraclize query IDs on ETH and ETC are different it wouldn’t do much.
How vDice Deals with Replay Attacks
Let’s take an example, to illustrate.
Let’s say I am an attacker and I want to steal some funds from a vDice contract. And let’s call vDice on ETH; vDice1 and vDice on ETC; vDice2.
The attacker could place a small bet on vDice1, wait for the oraclize callback Tx and see if it’s a win or loss.
If it’s a loss, the attacker just sends to vDice2 the same small bet, replays the Oraclize response and tries again.
If the attacker wins on vDice1, they can place a big bet on vDice2 knowing they will win by replaying Oraclize response to this second query. So they will make more money.
However, the above works only if Oraclize queries are the same on both ETH and ETC, which they aren’t.
So what would happen on ETC in reality is that bets can be placed anyway, unless you stop the contract there!
But the replayed Oraclize Tx wouldn’t do anything because they refer to different query IDs (which exist on ETH but not on ETC).
Ethereum Classic and the Future
We have worked with our Oracle to take actual action against such issues.
I believe we are addressing it in the right way, while not causing a mess on both chains.
Oraclize has also separated IDs, so that we could potentially support both chains if we want: https://github.com/oraclize/ethereum-api/commit/1cb43793db66d747cc21b3c5de6544254cf4973a
These are interesting times. And it is just something we will have to continue to monitor.
In the meantime, feel free to enjoy the vDice betting experience.