Shrike Bitcoin Wallet

A full desktop Bitcoin wallet: hardware wallets, PSBT, multisig and airgapped signing, connecting to your own node. Shrike follows Bitcoin's change of proof-of-work algorithm to BLAKE2b.

It signs with SIGHASH_UNIFIED, so the transactions it builds cannot be replayed onto the SHA256d chain.

Download Replay protection

What it does #

Shrike builds on Sparrow, so the wallet itself is a mature one.

Single signature and multisig wallets across the common script types
Hardware wallets over USB and in airgapped modes
Full PSBT import and export, and a transaction editor that shows the bytes before you broadcast
Replay protection marked per keystore, with the send screen reporting what each transaction actually got
Connects to your own node: Bitcoin Knots directly, or your own Electrum server indexing one
Tor built in, and fee rates, broadcast and explorer links pointed only at services that kept up
Installs alongside an existing Sparrow without sharing wallets, settings or state
Reproducible release binaries, with the proof of work and the signature hash checked against a live forked regtest node

What Shrike changes #

Everything not listed here is Sparrow: the same wallet model, the same hardware wallet support, the same PSBT workflow.

BLAKE2b proof of work #

Validates the 164 byte v2 block header and takes the BLAKE2b hash as the block id past activation. The work itself lives in the drongo submodule.

Unified opt-in signature hash #

Past activation, signs with SIGHASH_UNIFIED: the 0x20 flag set on the base hash type, 0x21 by default. The pre-fork rules reject that hash type, which is what the protection rests on.

Per-keystore opt-in #

Nothing a hardware device or watch-only keystore reports tells the wallet what firmware will sign for it, so you mark each one by hand. One marked signer in a quorum is enough. The device side lives in the lark submodule.

Only services that kept up #

Fee rates, explorer links and broadcast go to mempool.guide. The preconfigured public Electrum servers are gone, because they stopped at the activation height.

Separate application identity #

Installs alongside an existing Sparrow without sharing state: its own ~/.shrike folder, packages, desktop entries, MIME types and macOS bundle identifier.

Verified end to end #

The proof of work and the signature hash are both checked against a live forked regtest node, not just unit tested. The release binaries are reproducible.

Activation #

Past these heights, Shrike validates BLAKE2b work and opts in when it signs.

Network	Height	Activated
mainnet	`961,640`	30 August 2026
testnet4	`150,308`	30 August 2026

Below these heights nothing changes: the same chain, the same coins, the same history. Past them, blocks carry BLAKE2b work and signatures opt in.

The compiled-in height is cross checked against the connected node wherever the node reports one. If the two disagree, Shrike declines to opt in rather than picking a side. Only Knots reports the height, through getdeploymentinfo; behind anything else the wallet still opts in and tells you the height went unchecked.

Check the send screen #

A signature that does not opt in is valid under both rule sets. Where the coins it spends also exist on the SHA256d chain, that makes the transaction replayable there. Shrike selects the opt-in by default and says plainly what each transaction got.

The send screen reporting a transaction as replay protected — Where the status reads otherwise, hovering it names what is refusing and what to do about it.

Anyone Can Pay is the exception. It commits only to its own input and the outputs, so that input can be lifted out and spent on the SHA256d chain even though the whole transaction cannot. Shrike names such signatures and never selects that mode on its own.

Read the full replay protection guide →