Replay protection
Making a transaction valid on only one side of a chain split, so that spending coins on one chain cannot be replayed on the other.
The wiki's angle: replay protection is how a fork says it intends to be a separate coin. On the podcast, its absence in 2018 was cited as a sign of which side expected the split.[5][1]
The Bitcoin Cash approach
The Bitcoin Cash specification introduced a new signature digest that is used when the SIGHASH_FORKID bit (0x40) is set, and the reference implementation rejects such signatures before the UAHF activates[1]. The sighash type is altered to include a 24-bit fork ID in its most significant bits[1].
Later forks
Bitcoin Gold used two-way SIGHASH_FORKID replay protection with fork ID 79[2]. Bitcoin Diamond's README claims an anti-replay function in both directions, and Bitcoin Interest listed “Replay Protection (v2)” among its features[3][4].
When it is missing
On S17 E39, Kurt Wuckert Jr. said the SV node “didn't have replay protection” at the November 2018 split, which forced the SV side to scramble because wallets stopped working[5].
References
- primarybitcoincash.org, “BUIP-HF Digest for replay protected signature verification across hard forks” (SIGHASH_FORKID) [archived]
- btkBitcoin Gold: One GPU, One Vote (BTCTKVR: Forks!) [archived]
- primaryeveybcd/BitcoinDiamond README (GitHub) [archived]
- primaryBitcoinInterestOfficial/BitcoinInterest README (GitHub) [archived]
- episodeS17 E39: Kurt Wuckert Jr. — the SV node had no replay protection▶ listen at 1:06:55timestamp transcript-derived, pending a listen [archived]