<p>The purpose for "after certain time, set FORKID to 0xSMTHNG" is to keep the old chain alive but separate, in case of a bug in hard fork. After a Bitcoin Cash hardfork, let's say November 2018, if you're using an incompatible client, a client that complies with May 2018, it'll make transactions with a FORKID that starts with <code>0xFF00</code>, and those transactions will be invalid in the new chain. Wallets shouldn't enforce this rule, as it is assumed that they're not nodes and they are not interested in (some of) the new consensus rules, which are usually little changes, like new opcodes.</p>

<p>Trivia: Bitcoin SV was derived from Bitcoin ABC complying with May 2018. If they didn't commit <a href="https://github.com/bitcoin-sv/bitcoin-sv/commit/446b66ec3555f1e1e304c3f8a93a3e893896355b" rel="nofollow noreferrer">this</a>, there would be replay protection.</p>

CC BY-SA 4.0
2018-11-24T18:45:23.457Z
1. Do you mean May 2019? (not 2019)
2. Has BCH incremented the FORKID with every hard fork? There have been a few already and I don't think they have.
3. Aren't wallets literally the thing that USES SIGHASH? Do we just mean SPV wallets here? Wouldn't they need to follow the FORKID rule to get tx included in the chain?
4. I do not understand the logic with `0xdead`, what it happening there?
pinhead
CC BY-SA 4.0
2018-11-24T19:36:04.383Z
1) No, may 2018 2) No, ForkId is changed if a client that supports current consensus rules but not the rules of next consensus is running after the next fork date comes. It’s always been 0 on main Bitcoin Cash (not the dead forks) 3) Yes, that rule is confusing and illogical. It assumes that wallets dont need to upgrade for hard forks and only their backends do. 4) Nodes change the valid forkid value in case of a hard fork they don’t support, to keep that old chain alive and with 2way replay protection. Don’t hesitate to ask more questions if something’s unclear.
MCCCS
CC BY-SA 4.0
2018-11-25T00:02:06.390Z
Got it thank you. My misunderstanding was that FORKID is switched in by non-upgrading nodes on the fork time. I had that backwards :-)
pinhead
CC BY-SA 4.0
2018-11-24T17:56:16.947Z
2018-11-24T17:56:16.947Z
MCCCS
<p>References:</p>

<p><a href="https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/replay-protected-sighash.md" rel="nofollow noreferrer">https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/replay-protected-sighash.md</a></p>

<p><a href="https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2018-nov-upgrade.md" rel="nofollow noreferrer">https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2018-nov-upgrade.md</a></p>

<p>It looks to me like at the original fork point, Bitcoin-ABC added an extra value <code>0x40</code> called <code>SIGHASH_FORKID</code> that is xor'ed with the standard SIGHASH flags to produce a SIGHASH byte that is incompatible with Bitcoin Core. This provides replay protection for all transactions that are signed with ECDSA pubkeys.</p>

<p>Questions:</p>

<p>Is the <code>FORKID</code> updated with each "protocol upgrade" for example the recent "Magnetic Anomaly" upgrade? If not, why not?</p>

<p>It looks like the May 2019 upgrade will change the <code>FORKID</code> to <code>0xFF0001</code> but the spec mentions "Wallets that follow the upgrade should not have to change anything." -- how is that possible?</p>

<p>Did Bitcoin-SV change its <code>FORKID</code> for its recent hard fork away from Bitcoin-ABC? Is there any replay protection at all between those two chains?</p>

<bitcoin-cash><blockchain-fork><sighash-flags>
How was FORKID used in Bitcoin Cash at the original fork point and in all upgrades since?
pinhead
# How was FORKID used in Bitcoin Cash at the original fork point and in all upgrades since?

(Asked by: username_0 on 2018-11-22)

References:

<https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/replay-protected-sighash.md>

<https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2018-nov-upgrade.md>

It looks to me like at the original fork point, Bitcoin-ABC added an extra value `0x40` called `SIGHASH_FORKID` that is xor'ed with the standard SIGHASH flags to produce a SIGHASH byte that is incompatible with Bitcoin Core. This provides replay protection for all transactions that are signed with ECDSA pubkeys.

Questions:

Is the `FORKID` updated with each "protocol upgrade" for example the recent "Magnetic Anomaly" upgrade? If not, why not?

It looks like the May 2019 upgrade will change the `FORKID` to `0xFF0001` but the spec mentions "Wallets that follow the upgrade should not have to change anything." -- how is that possible?

Did Bitcoin-SV change its `FORKID` for its recent hard fork away from Bitcoin-ABC? Is there any replay protection at all between those two chains?

**Tags:** bitcoin-cash, blockchain-fork, sighash-flags


---

## 1 answers

### Answer by username_1 on 2018-11-24. Score: 2

The purpose for "after certain time, set FORKID to 0xSMTHNG" is to keep the old chain alive but separate, in case of a bug in hard fork. After a Bitcoin Cash hardfork, let's say November 2018, if you're using an incompatible client, a client that complies with May 2018, it'll make transactions with a FORKID that starts with `0xFF00`, and those transactions will be invalid in the new chain. Wallets shouldn't enforce this rule, as it is assumed that they're not nodes and they are not interested in (some of) the new consensus rules, which are usually little changes, like new opcodes.

Trivia: Bitcoin SV was derived from Bitcoin ABC complying with May 2018. If they didn't commit [this](https://github.com/bitcoin-sv/bitcoin-sv/commit/446b66ec3555f1e1e304c3f8a93a3e893896355b), there would be replay protection.

> **Comments:**
> **username_0**: 1. Do you mean May 2019? (not 2019) 2. Has BCH incremented the FORKID with every hard fork? There have been a few already and I don't think they have. 3. Aren't wallets literally the thing that USES SIGHASH? Do we just mean SPV wallets here? Wouldn't they need to follow the FORKID rule to get tx included in the chain? 4. I do not understand the logic with `0xdead`, what it happening there?  
> **username_1**: 1) No, may 2018 2) No, ForkId is changed if a client that supports current consensus rules but not the rules of next consensus is running after the next fork date comes. It’s always been 0 on main Bitcoin Cash (not the dead forks) 3) Yes, that rule is confusing and illogical. It assumes that wallets dont need to upgrade for hard forks and only their backends do. 4) Nodes change the valid forkid value in case of a hard fork they don’t support, to keep that old chain alive and with 2way replay protection. Don’t hesitate to ask more questions if something’s unclear.  
> **username_0**: Got it thank you. My misunderstanding was that FORKID is switched in by non-upgrading nodes on the fork time. I had that backwards :-)  

---

