Features

What Shrike changes

Shrike is Sparrow with the changes below carried on top. Anything not listed here behaves as upstream does, and upstream's documentation applies to it.

All of it concerns one thing: the BLAKE2b hardfork is an upgrade to Bitcoin's proof of work, applied to the existing chain at a set height. It is not a new chain, and it does not create a separate coin. Shrike is a Bitcoin wallet holding Bitcoin, and the balances and history in it are the ones that were always there.

BLAKE2b proof of work

Past the activation height, Shrike validates the 164 byte v2 block header and takes its BLAKE2b hash as the block id. Before activation it validates the old header and the old hash, so one wallet syncs the whole chain from genesis across the boundary without a break. The implementation lives in the drongo submodule, which is why the clone has to be recursive.

The fork itself is not this project's work. bitcoin-blake2b.org explains what changed and why, Bitcoin Knots covers it at bitcoinknots.org/learn, and the consensus change is specified in the release notes. Shrike is a wallet that follows it.

Unified opt-in signature hash

Past activation, Shrike signs with SIGHASH_UNIFIED. It is a flag, 0x20, set on whatever base hash type the signature already uses: 0x21 for the default All, 0x22 for None, 0x23 for Single, and 0xA1 to 0xA3 for the Anyone Can Pay combinations. Under the pre-fork rules none of those are valid, so a signature carrying the flag cannot be replayed onto nodes still running them. This is the whole mechanism: the protection comes from the old rules rejecting the signature, not from anything the wallet asks the network to enforce.

Where Shrike cannot opt in, it signs the legacy way and says so on the send screen rather than failing or pretending.

Per-keystore opt-in

Nothing a hardware device reports identifies the firmware that will sign for it, and a watch-only keystore reports nothing about signing at all. So the opt-in is not detected, it is declared: each keystore is marked by hand under Replay protection in the wallet's keystore settings, and stays off until its owner says otherwise. A keystore holding its own key needs no mark.

In a multisig quorum, one marked signer is enough. Unmarked signers still sign: each is handed the hash type it can actually produce. Mark two of a 2-of-3 and every transaction opts in; mark one and it depends on that signer taking part, which the wallet reports per transaction rather than promising in advance.

Only services that adopted the fork

A fee estimate drawn from a mempool you are not broadcasting into prices the transaction wrongly, and an explorer that stopped at the activation height shows a history that ends there. Fee rates, explorer links and broadcast all go to mempool.guide, over Tor where a proxy is configured. The public Electrum servers Sparrow ships with are removed, because none of them follow the fork. Connect a Bitcoin Knots node at v29.4.1.knots20260508 or later, or your own Electrum server indexing one.

Separate application identity

Shrike installs and runs alongside an existing Sparrow without touching its state. It has its own home folder (~/.shrike), its own packages and desktop entries, its own MIME type registrations and its own macOS bundle identifier. Wallets are not shared between the two, and neither installation can overwrite the other.

Inherited from Sparrow

The wallet model, the transaction editor, hardware wallet support, PSBT import and export, the airgapped workflows, Tor support and the server settings are all upstream's work, unchanged except where the items above required it. Shrike tracks upstream and carries these changes on top.

For problems specific to this fork, use the issue tracker here. Anything else belongs upstream.