<p>Bitcoin Cash (aka Bitcoin ABC aka UAHF) provides two methods of replay protection, both of which are opt in. If you do not create transactions which use these features, then your transactions are vulnerable to replay.</p>
<p>The <a href="https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/uahf-technical-spec.md#req-6-2-mandatory-signature-shift-via-hash-type" rel="nofollow noreferrer">first method</a> is a <a href="https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/replay-protected-sighash.md" rel="nofollow noreferrer">redefined sighashing algorithm</a> which is basically the same as the one specified by BIP 143. This sighash algorithm is only used when the sighash flag has bit 6 set. These transactions would be invalid on the non-UAHF chain as the different sighashing algorithm will result in invalid transactions. This means that in order to use this, you will need to transact on the UAHF chain first and then on the non-UAHF chain second.</p>
<p>The <a href="https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/uahf-technical-spec.md#req-6-1-disallow-special-op_return-marked-transactions-with-sunset-clause" rel="nofollow noreferrer">second method</a> uses an OP_RETURN output which has the exact string:</p>
<pre><code>Bitcoin: A Peer-to-Peer Electronic Cash System
</code></pre>
<p>as the data of the OP_RETURN. Any transaction which contains this string will be considered invalid by UAHF nodes until block 530,000. This means that prior to block 530,000, you can split your coins by transacting on the non-UAHF chain first with the OP_RETURN output, and then transacting on the UAHF chain second.</p>
<p>Update: They Bitcoin Cash specification now requires that all transaction use the redefined sighashing algorithm as explained for the first method. This means that there is now two way transaction replay protection; transactions made on the Bitcoin ABC chain will be invalid on the non-ABC chain and vice versa.</p>

CC BY-SA 3.0
2017-08-02T05:06:04.520Z
2 questions: does the **UPDATE** portion of your answer mean that replay protection is not opt-in anymore? and second: you seem to be speaking in a very theoretical way (referencing to the spec), but do the implementations, as of now, respect this spec?
knocte
CC BY-SA 3.0
2017-08-02T05:07:48.157Z
1. Replay protection is mandatory now and will be enforced by BCC wallets and nodes. 2. BCC wallets have probably implemented all of this now since they have forked off of the Bitcoin network. At the time this was written, many BCC wallets were not complete nor was their spec complete.
Ava Chow
CC BY-SA 3.0
2017-08-02T05:14:52.880Z
in other words, replay protection is not opt-in anymore, right?
knocte
CC BY-SA 3.0
2017-08-02T05:15:34.973Z
Yes, replay protection is not opt-in. Although they have still kept the OP_RETURN thing in for some reason.
Ava Chow
CC BY-SA 3.0
2017-08-02T05:31:44.457Z
Ok two more questions: by this logic, it's not opt-out either, right? And last but not least: does the 530,000 magic number still hold? AFAIU the first exclusive (or divergent, let's say) block of BitCash is 478,559 so do we have to wait to use this automatic replay protection?
knocte
CC BY-SA 3.0
2017-08-02T05:32:49.760Z
No, it is not opt out either. The replay protection with the sighash thing is mandatory. The 530,000 block wait is unrelated to this mandatory replay protection. That only applied to the opt in one with OP_RETURN
Ava Chow
CC BY-SA 3.0
2017-08-02T13:44:01.080Z
@AndrewChow Just confirming "Mandatory" implies that the protocol will reject those or is it just a "recommendation"? Sometimes the two terms are mixed in specs.
Jus12
CC BY-SA 3.0
2017-08-02T16:18:01.480Z
It is mandatory in that any transaction that does not use the redefined sighashing algorithm will be considered invalid and rejected. All transactions must use that sighashing algorithm.
Ava Chow
CC BY-SA 4.0
2017-07-20T02:28:55.703Z
2021-05-09T23:26:21.157Z
2021-05-09T23:26:21.157Z
Ava Chow
<p>Bitcoin Cash says that they are providing replay protection for their fork. How does this replay protection work?</p>

<blockchain-fork><replay-attack><bitcoin-cash>
How does Bitcoin Cash implement replay protection?
Murch
# How does Bitcoin Cash implement replay protection?

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

Bitcoin Cash says that they are providing replay protection for their fork. How does this replay protection work?

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


---

## 1 answers

### Answer by username_1 on 2017-07-20. Score: 45 | Accepted answer

Bitcoin Cash (aka Bitcoin ABC aka UAHF) provides two methods of replay protection, both of which are opt in. If you do not create transactions which use these features, then your transactions are vulnerable to replay.

The [first method](https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/uahf-technical-spec.md#req-6-2-mandatory-signature-shift-via-hash-type) is a [redefined sighashing algorithm](https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/replay-protected-sighash.md) which is basically the same as the one specified by BIP 143. This sighash algorithm is only used when the sighash flag has bit 6 set. These transactions would be invalid on the non-UAHF chain as the different sighashing algorithm will result in invalid transactions. This means that in order to use this, you will need to transact on the UAHF chain first and then on the non-UAHF chain second.

The [second method](https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/uahf-technical-spec.md#req-6-1-disallow-special-op_return-marked-transactions-with-sunset-clause) uses an OP\_RETURN output which has the exact string:

```
Bitcoin: A Peer-to-Peer Electronic Cash System

```

as the data of the OP\_RETURN. Any transaction which contains this string will be considered invalid by UAHF nodes until block 530,000. This means that prior to block 530,000, you can split your coins by transacting on the non-UAHF chain first with the OP\_RETURN output, and then transacting on the UAHF chain second.

Update: They Bitcoin Cash specification now requires that all transaction use the redefined sighashing algorithm as explained for the first method. This means that there is now two way transaction replay protection; transactions made on the Bitcoin ABC chain will be invalid on the non-ABC chain and vice versa.

> **Comments:**
> **username_2**: 2 questions: does the **UPDATE** portion of your answer mean that replay protection is not opt-in anymore? and second: you seem to be speaking in a very theoretical way (referencing to the spec), but do the implementations, as of now, respect this spec?  
> **username_1**: 1. Replay protection is mandatory now and will be enforced by BCC wallets and nodes. 2. BCC wallets have probably implemented all of this now since they have forked off of the Bitcoin network. At the time this was written, many BCC wallets were not complete nor was their spec complete.  
> **username_2**: in other words, replay protection is not opt-in anymore, right?  
> **username_1**: Yes, replay protection is not opt-in. Although they have still kept the OP_RETURN thing in for some reason.  
> **username_2**: Ok two more questions: by this logic, it's not opt-out either, right? And last but not least: does the 530,000 magic number still hold? AFAIU the first exclusive (or divergent, let's say) block of BitCash is 478,559 so do we have to wait to use this automatic replay protection?  
> **username_1**: No, it is not opt out either. The replay protection with the sighash thing is mandatory. The 530,000 block wait is unrelated to this mandatory replay protection. That only applied to the opt in one with OP_RETURN  
> **username_3**: @AndrewChow Just confirming "Mandatory" implies that the protocol will reject those or is it just a "recommendation"? Sometimes the two terms are mixed in specs.  
> **username_1**: It is mandatory in that any transaction that does not use the redefined sighashing algorithm will be considered invalid and rejected. All transactions must use that sighashing algorithm.  

---

