Docs

Replay protection with SIGHASH_UNIFIED

The fork left two sets of nodes running: the ones that took the upgrade, and the ones that did not. Both still recognise the coins you already had.

That creates one risk. If you sign a payment the old way, the very same payment can be copied across to the nodes that did not upgrade and spent there too. You meant to pay once, and you end up paying on both sides.

Shrike signs the new way by default, and the old nodes reject that signature. That is the whole protection, and it does not depend on anyone else cooperating.

So there are two things to do. Before you send, check the send screen says the transaction is protected. And if you were holding coins before the fork, send them to yourself once, because until you do, spending them can still be copied.

The rest of this page is the detail behind that.

How the opt-in works

Replay is the one thing a hardfork of Bitcoin has to handle carefully. The chain, the coins and the history are unchanged; what changes at the activation height is the proof of work and the signature hash, and until your coins have moved under the new rules a transaction you sign can be valid on both sides of that height.

Past the activation height Shrike signs with SIGHASH_UNIFIED, the name the fork uses for this opt-in. It is not a hash type of its own but a flag, 0x20, set on the base type a signature already carries:

None of those are valid under the pre-fork consensus rules, so a node running them rejects the signature outright. Nothing has to cooperate for this to hold: the protection is the old rules refusing the signature, not a policy anyone has to honor.

The compiled-in height is cross checked against the connected node wherever the node reports one, and a disagreement makes Shrike decline to opt in rather than follow either number. Only Knots reports it, through getdeploymentinfo. Behind anything else the wallet still opts in, and tells you the height went unchecked.

Reading the send screen

The opt-in is selected by default, and the send screen reports what the transaction actually got. Check it before you build anything.

Where a signer is the reason, the fix is to mark it, below. Where the wallet cannot opt in at all, it signs the legacy way rather than failing, and says so.

Marking a keystore

Nothing a hardware device reports says which firmware it runs, and a watch-only keystore reports nothing about signing at all. So the wallet cannot detect the opt-in: you tell it. Open the wallet settings, go to the keystore tab, and tick Replay protection for each keystore whose signer you know produces the new hash type. It is off until you say so.

Stock firmware from any manufacturer cannot produce SIGHASH_UNIFIED yet. Where a device needs new firmware to be markable, see hardware wallet firmware for the builds that exist and what flashing one costs you.

Multisig quorums

One marked signer is enough for the transaction to opt in, and unmarked signers still sign: each is handed the hash type it can actually produce.

What that means in practice depends on how many you mark. Mark two of a 2-of-3 and every transaction opts in, because any quorum that forms contains at least one of them. Mark one and it depends on that signer taking part, which is why the wallet reports the result per transaction on the send screen instead of promising anything in advance.

The Anyone Can Pay exception

Anyone Can Pay commits only to its own input and to the outputs. The rest of the transaction is not covered, so that single input can be lifted out of it and spent against nodes that never adopted the fork, even though the transaction as a whole cannot be replayed. The send screen names signatures of this kind, and Shrike never selects the mode by itself.

Community walkthroughs

Bitcoin University has a walkthrough of installing Shrike and connecting it to a node, covering Start9 and Umbrel.

Greg Tonoski recorded a demonstration of a replay-protected transaction made after activation, showing the spend and its result on chain. It was made with an early build, and the send screen has since been reworked to report protection differently, so its screens do not match the ones above.

Both are community recordings rather than documentation for this wallet, and both were made before the current release.

Coins held across activation

Coins that existed before activation are the same coins either way: the fork does not duplicate them or issue anything new. What it does mean is that a spend of them is only bound to the upgraded rules once it carries an opted-in signature, and a spend covers only the inputs it consumes.

So sweep every pre-fork UTXO to yourself before transacting with anyone still on the old rules. Until you do, a transaction spending those coins stays valid under the pre-fork rules as well, and anyone holding a copy of it can submit it there.