I accidentally sent ETC to an address that previously only had ETH on it. This was an address created after the DAO hardfork. As far as I understand with EIP 155 I have replay protection from any transactions that I sign with this address on the ETH chain. The address in question is an address that I was using frequently to sign transactions with.

However, at some point I am going to want to move the ETC on this address, and as far as I understand backwards compatibility with EIP 155 is that my ETH address won't be protected. I send my ETC and the tx can be replayed on the ETH chain.

Questions: (1) The replay attack can only be for the amount that was send on the original tx? Or can it be for a larger amount if the the ETH address holds more Ether?

(2) Also what happens to tokens that are on my address? Say the answer to question (1) is that a replay attack from an ETC transaction could drain my entire ETH address. Before I send the ETC tx I send all my ETH to a different address. Then my tokens are still on the ETH address. When I then go and send an ETC tx could someone use that tx to move my tokens to a different ETH address?


The replay attack allows any transaction signed in a way that is valid on both chains to be executed. So, for example, if you have an account with 10 eth in the Classic chain and 1 eth in the Ethereum chain, a pre-EIP155 transaction would allow an attacker to replay any basic balance transfer from the Ethereum chain on the Classic; a balance transfer of >1 eth signed on the Classic chain using a pre-EIP155 wallet could not be replayed on the Ethereum chain until the account balance was large enough. But as soon as the balance on the Ethereum account is large enough, the transaction becomes valid and an attacker can replay it onto the Ethereum chain. Perhaps this attacker received payment for you in ETC and is hoping to get the same amount in ETH as well.

When you sign a transaction, you're saying "I authorize X to happen". As long as the authorization makes sense on a chain, it can be used (once) on that chain. With EIP155, the old way of signing transactions is still permitted along with a new chain-specific signature. Pre-EIP155 wallets can still transact on the Ethereum and Ethereum Classic chains and are subject to the replay attack. Unlike the pre-EIP155 transaction signature which says "I authorize X to happen," EIP155 allows the transaction signature to also include the chain for which the transaction is being signed -- essentially, the signed transaction now says "I authorize X to happen (only) on the Y chain." and the mining nodes will reject the transaction if they are not mining chain Y. Thus, even if the transaction were replayed onto another chain, the authorization is invalid on that chain.

  • So what about tokens? – Mateo M. Aug 9 '17 at 23:42
  • Tokens are an example of a smart contract. Manipulating contracts is an example of a transaction (another type is a balance transfer -- AKA sending ether). Thus, tokens are one of the things covered by the description above. – lungj Aug 10 '17 at 1:31
  • Yes, but I still don't understand from your description if a non EIP 155 transaction on the Classic chain would allow someone to do a replay attack that sends a token on the mainnet. I am referring to tokens that only exist on the mainnet. – Mateo M. Aug 11 '17 at 4:18
  • If the token only exists on the mainnet, then I'm not sure why anyone would be interacting with the token's address on Classic (unless there was an address collision). An alternate reading of your first sentence leads to this answer: no new transactions (anything after the fork) on Classic can have a direct effect on the main net or vice versa. Am I misunderstanding your question/missing a third interpretation? – lungj Aug 11 '17 at 5:08
  • @lungj does the ETC chain understand EIP155 transactions? – knocte Feb 26 '18 at 7:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.