How was FORKID used in Bitcoin Cash at the original fork point and in all upgrades since?

3

1

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?

pinhead

Posted 2018-11-22T19:47:53.100

Reputation: 2 356

Answers

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.

MCCCS

Posted 2018-11-22T19:47:53.100

Reputation: 5 827

>

  • Do you mean May 2019? (not 2019)
  • Has BCH incremented the FORKID with every hard fork? There have been a few already and I don't think they have.
  • 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?
  • I do not understand the logic with 0xdead, what it happening there?
    • < – pinhead – 2018-11-24T18:45:23.457

    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 – 2018-11-24T19:36:04.383

    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 – 2018-11-25T00:02:06.390

    Asked: 2018-11-22T19:47:53.100

    Viewed: 220 times

    Active: 2018-11-24T17:56:16.947