<p>There's some history when it comes to ETH/ETC replay protection.</p>

<blockquote>
  <p>How was this problem resolved for Ethereum? </p>
</blockquote>

<p>Initially when ETH hard-forked to invalidate the DAO contract, both ETC/ETH networks did not implement replay protection for transactions. Instead, a <a href="https://etherscan.io/address/0xaa1a6e3e6ef20068f7f8d8c835d2d22fd5116444#code" rel="nofollow noreferrer">split contract</a> was written instead which relies on a split oracle built in Ethereum to identify if the contract was called on the hard-fork (i.e. ETH chain). </p>

<p>The contract logic is quite simple as you can see for yourself, it basically splits the original tokens and sends them into two different addresses depending on which chain the contract is called. </p>

<p>Nowadays, the ETH (hard-forked) chain has effectively <a href="https://github.com/ethereum/eips/issues/155" rel="nofollow noreferrer">implemented replay protection</a>. So transactions executed on the ETC network will not be valid on the ETH network and vice-versa.</p>

<blockquote>
  <p>Does Ethereum still have possibility of replay-attack if transaction is to be made from the very old wallet (the wallet which have no associated transaction after the fork)?</p>
</blockquote>

<p>No.</p>

CC BY-SA 3.0
2017-11-06T08:30:57.320Z
2017-11-06T08:30:57.320Z
rny
<p>Two things are important:</p>

<ol>
<li><p>The Ethereum foundation actually like the idea of forks, allowing different views in the community to co-exist. The Foundation only support one chain (ETH in this case).</p></li>
<li><p>Ethereum is a different type of Blockchain from Bitcoin at the moment. It contains contracts that could be automated to perform specific task. Which makes it easier to automate solutions for forks.</p></li>
</ol>

<p>This post will be help explain how it was solved at the time <a href="https://blog.ethereum.org/2016/07/26/onward_from_the_hard_fork/" rel="nofollow noreferrer">https://blog.ethereum.org/2016/07/26/onward_from_the_hard_fork/</a></p>

CC BY-SA 3.0
2017-11-06T08:14:18.190Z
downvoted as the response does not answer the question.
rny
CC BY-SA 3.0
2017-11-05T20:32:00.310Z
2017-11-05T20:32:00.310Z
DaJudge
<p>On etherum, there was a hard fork which resulted in ETH and ETC.  My reading indicates that <a href="http://www.coindesk.com/rise-replay-attacks-ethereum-divide/" rel="nofollow noreferrer">it suffered problem of replay-attack</a>.</p>

<p>Question:</p>

<ul>
<li>How was this problem resolved for Ethereum?  In my understanding, replay-attack protection requires another hard fork, because replay-protection inherently requires making transaction incompatible among the 2 chains.  Was such fork operated?  Or does Ethereum still have possibility of replay-attack if transaction is to be made from the very old wallet (the wallet which have no associated transaction after the fork)?</li>
</ul>

<ethereum><replay-attack>
How was Ethereum hard fork's replay attack was handled?
Yuki Inoue
# How was Ethereum hard fork's replay attack was handled?

(Asked by: username_0 on 2017-07-22)

On etherum, there was a hard fork which resulted in ETH and ETC. My reading indicates that [it suffered problem of replay-attack](http://www.coindesk.com/rise-replay-attacks-ethereum-divide/).

Question:

* How was this problem resolved for Ethereum? In my understanding, replay-attack protection requires another hard fork, because replay-protection inherently requires making transaction incompatible among the 2 chains. Was such fork operated? Or does Ethereum still have possibility of replay-attack if transaction is to be made from the very old wallet (the wallet which have no associated transaction after the fork)?

**Tags:** ethereum, replay-attack


---

## 2 answers

### Answer by username_1 on 2017-11-06. Score: 0 | Accepted answer

There's some history when it comes to ETH/ETC replay protection.

> How was this problem resolved for Ethereum?

Initially when ETH hard-forked to invalidate the DAO contract, both ETC/ETH networks did not implement replay protection for transactions. Instead, a [split contract](https://etherscan.io/address/0xaa1a6e3e6ef20068f7f8d8c835d2d22fd5116444#code) was written instead which relies on a split oracle built in Ethereum to identify if the contract was called on the hard-fork (i.e. ETH chain).

The contract logic is quite simple as you can see for yourself, it basically splits the original tokens and sends them into two different addresses depending on which chain the contract is called.

Nowadays, the ETH (hard-forked) chain has effectively [implemented replay protection](https://github.com/ethereum/eips/issues/155). So transactions executed on the ETC network will not be valid on the ETH network and vice-versa.

> Does Ethereum still have possibility of replay-attack if transaction is to be made from the very old wallet (the wallet which have no associated transaction after the fork)?

No.


---

### Answer by username_2 on 2017-11-05. Score: -1

Two things are important:

1. The Ethereum foundation actually like the idea of forks, allowing different views in the community to co-exist. The Foundation only support one chain (ETH in this case).
2. Ethereum is a different type of Blockchain from Bitcoin at the moment. It contains contracts that could be automated to perform specific task. Which makes it easier to automate solutions for forks.

This post will be help explain how it was solved at the time <https://blog.ethereum.org/2016/07/26/onward_from_the_hard_fork/>

> **Comments:**
> **username_1**: downvoted as the response does not answer the question.  

---

