4

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?

Improve this question

1 Answer 1

Reset to default
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, there would be replay protection.

Improve this answer
3
  • 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
    Nov 24, 2018 at 18:45
  • 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
    Nov 24, 2018 at 19:36
  • 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
    Nov 25, 2018 at 0:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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