<p>It's true that what you propose would effectively split the coins and prevent further replays, if it succeeded.</p>

<p>However, it suffers the following problems:</p>

<ul>
<li><p>Every person who wants to split their coins has to create an additional transaction to do so (and pay a transaction fee).  Presumably nobody really wants to be subject to replay attacks, so everyone is going to want to do this.  That's costly for users, and it's a huge number of transactions.  For instance, Bitcoin currently has about 50 million utxos; splitting all of them would require enough transactions to fill some 5000 blocks, so the entire network would be bogged down for several weeks, and transaction fees would skyrocket.</p></li>
<li><p>Some people may not know about this requirement, and may unwittingly subject themselves to such attacks.  Even if it's done automatically by software, they may still be using old LegacyCoin software that doesn't do it.  That's not very user friendly.</p></li>
<li><p>An attacker can defeat it, at least temporarily.  Suppose Alice broadcasts her A->B and A->C transactions as you propose.  Mallory, an evil NewCoin miner, sees the A->B transaction on the LegacyCoin network, and decides to try to replay it on the NewCoin network.  He puts A->B in his candidate block (which he can do because it is replayable!) and is lucky enough to mine it before anybody else confirms the A->C transaction.  Now Alice's coins live in utxo B on both networks, which is exactly what she is trying to avoid.  Best case, she notices this happens and has to start over (and pay another transaction fee), until she succeeds in having honest miners confirm the right transactions on both networks.  Worst case, she doesn't notice and is unknowingly vulnerable to future replays.  </p></li>
</ul>

CC BY-SA 3.0
2017-10-10T03:05:20.113Z
2017-10-10T03:05:20.113Z
Nate Eldredge
<p>The LegacyCoin network and NewCoin network are not distinctly separate from each other. Unless network magic and ports are changed, LegacyCoin nodes will be able to connect to NewCoin nodes and likely many will be connected to each other. So if you broadcast transaction <code>A-&gt;B</code>, on the LegacyCoin network, it will likely reach a NewCoin node which then causes the transaction to also be relayed on the NewCoin network.</p>

<p>Furthermore, even if the networks are distinctly separate, people can operate a node on both the LegacyCoin network and NewCoin network. Without replay protection, someone can take transactions that they are hearing on the LegacyCoin network and broadcast them through his NewCoin node and vice versa.</p>

<p>Lastly, two way replay protection should be mandatory because the process of splitting your coins with UTXO tainting is rather difficult. You need to have decent technical knowledge to do it and you will likely need to have modified software in order to do so. It is not something that ordinary users are likely able to do without some very specific instructions and there is a high probability that they will mess it up and possibly lose coins.</p>

CC BY-SA 3.0
2017-10-10T03:35:45.613Z
So to clairfy, your saying the process breaks down at step 4: Alice may not have the ability to chooses that the transactions get broadcast on separate networks because they might not actually be separate networks and even if they are there's still a chance someone can intercept one of her transactions and replay it on the "other" network anyway without Alice's knowledge or permission?
RBF06
CC BY-SA 3.0
2017-10-10T03:36:52.593Z
Yes. That is why it is called a "transaction replay attack"; your transaction is being replayed onto another network possibly without you knowing at all.
Ava Chow
CC BY-SA 3.0
2017-10-10T03:41:08.677Z
Right. I know it's *possible* to defeat this method of replay protection but wouldn't the replay event be unlikely to happen unless there was economic incentive for someone to do it (which presumably wouldn't exist bc Alice still controls private keys to both B and C)?
RBF06
CC BY-SA 3.0
2017-10-10T04:18:53.693Z
It's a more general reason for having replay protection. Those who don't know how to do this sort of splitting will end up having their normal transactions replayed either accidentally or possibly by the person receiving the transaction who wishes to gain coins on the other chain.
Ava Chow
CC BY-SA 3.0
2017-10-10T02:31:36.527Z
2017-10-10T02:31:36.527Z
Ava Chow
<p>I've seen a lot of methods hard forked chains use to provide both strong and opt-in replay protection so that transactions are only valid on one of the chains. Examples of such rules include using a transaction-invalidating output, and using a specific <code>OP_RETURN</code> string. </p>

<p>My question is why are any of these mechanisms neccessary to protect a holder from replay attack? More specifically, why can't a person who holds coins pre-fork protect themselves simply by spending a pair of coin-splitting transactions on each chain like this:</p>

<ol>
<li>Alice has sole knowledge of the private key needed to spend UTXO <code>A</code> which is valued at 1 "LegacyCoin" before the hard fork.</li>
<li>Hard fork creates a new coin called "NewCoin" based on the blockchain history  of LegacyCoin.

<ul>
<li>UTXO <code>A</code> now contains 1 LegacyCoin according to the LegacyCoin network and 1 NewCoin according to  the NewCoin network because that's how hard forks work.</li>
</ul></li>
<li>Alice creates and signs two transactions: one that spends <code>A</code> to <code>B</code> and one that spends <code>A</code> to <code>C</code> (both of which Alice also has sole knowlege of the priavte key). </li>
<li>Alice then simultaneously broadcasts these signed transactions on the two networks: broadcasting the transaction <code>A-&gt;B</code> only on the LegacyCoin network and the transaction <code>A-&gt;C</code> only on the NewCoin network.</li>
<li>Both transactions get confirmed on their respective networks and now Alice has effectively split the original value of UTXO <code>A</code> into the two blockchains in complete absence of any replay protection mechanisms implemented by NewCoin. The coins can now be concidered split because even if she spends <code>B</code>, no one else can spend <code>C</code> (and vice versa) becuase they are different UTXOs and require different signatures to spend. Also, obviously no one can spend <code>A</code> because it is already spent on both chains.  </li>
</ol>

<p>Why is statement in step 5 not true? Where does this logic break down requiring actual replay protection mechanism to be implemented by hard-forked chains? </p>

<blockchain-fork><replay-attack>
Why do hard forks need special rules to allow replay protection?
RBF06
# Why do hard forks need special rules to allow replay protection?

(Asked by: username_0 on 2017-10-10)

I've seen a lot of methods hard forked chains use to provide both strong and opt-in replay protection so that transactions are only valid on one of the chains. Examples of such rules include using a transaction-invalidating output, and using a specific `OP_RETURN` string.

My question is why are any of these mechanisms neccessary to protect a holder from replay attack? More specifically, why can't a person who holds coins pre-fork protect themselves simply by spending a pair of coin-splitting transactions on each chain like this:

1. Alice has sole knowledge of the private key needed to spend UTXO `A` which is valued at 1 "LegacyCoin" before the hard fork.
2. Hard fork creates a new coin called "NewCoin" based on the blockchain history of LegacyCoin.
   * UTXO `A` now contains 1 LegacyCoin according to the LegacyCoin network and 1 NewCoin according to the NewCoin network because that's how hard forks work.
3. Alice creates and signs two transactions: one that spends `A` to `B` and one that spends `A` to `C` (both of which Alice also has sole knowlege of the priavte key).
4. Alice then simultaneously broadcasts these signed transactions on the two networks: broadcasting the transaction `A->B` only on the LegacyCoin network and the transaction `A->C` only on the NewCoin network.
5. Both transactions get confirmed on their respective networks and now Alice has effectively split the original value of UTXO `A` into the two blockchains in complete absence of any replay protection mechanisms implemented by NewCoin. The coins can now be concidered split because even if she spends `B`, no one else can spend `C` (and vice versa) becuase they are different UTXOs and require different signatures to spend. Also, obviously no one can spend `A` because it is already spent on both chains.

Why is statement in step 5 not true? Where does this logic break down requiring actual replay protection mechanism to be implemented by hard-forked chains?

**Tags:** blockchain-fork, replay-attack


---

## 2 answers

### Answer by username_1 on 2017-10-10. Score: 2 | Accepted answer

It's true that what you propose would effectively split the coins and prevent further replays, if it succeeded.

However, it suffers the following problems:

* Every person who wants to split their coins has to create an additional transaction to do so (and pay a transaction fee). Presumably nobody really wants to be subject to replay attacks, so everyone is going to want to do this. That's costly for users, and it's a huge number of transactions. For instance, Bitcoin currently has about 50 million utxos; splitting all of them would require enough transactions to fill some 5000 blocks, so the entire network would be bogged down for several weeks, and transaction fees would skyrocket.
* Some people may not know about this requirement, and may unwittingly subject themselves to such attacks. Even if it's done automatically by software, they may still be using old LegacyCoin software that doesn't do it. That's not very user friendly.
* An attacker can defeat it, at least temporarily. Suppose Alice broadcasts her A->B and A->C transactions as you propose. Mallory, an evil NewCoin miner, sees the A->B transaction on the LegacyCoin network, and decides to try to replay it on the NewCoin network. He puts A->B in his candidate block (which he can do because it is replayable!) and is lucky enough to mine it before anybody else confirms the A->C transaction. Now Alice's coins live in utxo B on both networks, which is exactly what she is trying to avoid. Best case, she notices this happens and has to start over (and pay another transaction fee), until she succeeds in having honest miners confirm the right transactions on both networks. Worst case, she doesn't notice and is unknowingly vulnerable to future replays.


---

### Answer by username_2 on 2017-10-10. Score: 2

The LegacyCoin network and NewCoin network are not distinctly separate from each other. Unless network magic and ports are changed, LegacyCoin nodes will be able to connect to NewCoin nodes and likely many will be connected to each other. So if you broadcast transaction `A->B`, on the LegacyCoin network, it will likely reach a NewCoin node which then causes the transaction to also be relayed on the NewCoin network.

Furthermore, even if the networks are distinctly separate, people can operate a node on both the LegacyCoin network and NewCoin network. Without replay protection, someone can take transactions that they are hearing on the LegacyCoin network and broadcast them through his NewCoin node and vice versa.

Lastly, two way replay protection should be mandatory because the process of splitting your coins with UTXO tainting is rather difficult. You need to have decent technical knowledge to do it and you will likely need to have modified software in order to do so. It is not something that ordinary users are likely able to do without some very specific instructions and there is a high probability that they will mess it up and possibly lose coins.

> **Comments:**
> **username_0**: So to clairfy, your saying the process breaks down at step 4: Alice may not have the ability to chooses that the transactions get broadcast on separate networks because they might not actually be separate networks and even if they are there's still a chance someone can intercept one of her transactions and replay it on the "other" network anyway without Alice's knowledge or permission?  
> **username_2**: Yes. That is why it is called a "transaction replay attack"; your transaction is being replayed onto another network possibly without you knowing at all.  
> **username_0**: Right. I know it's *possible* to defeat this method of replay protection but wouldn't the replay event be unlikely to happen unless there was economic incentive for someone to do it (which presumably wouldn't exist bc Alice still controls private keys to both B and C)?  
> **username_2**: It's a more general reason for having replay protection. Those who don't know how to do this sort of splitting will end up having their normal transactions replayed either accidentally or possibly by the person receiving the transaction who wishes to gain coins on the other chain.  

---

