Docs

Shrike FAQ

Questions specific to Shrike. For how the wallet itself works, upstream's documentation applies unchanged.

Is this a different coin? #

No. The BLAKE2b hardfork is an upgrade to Bitcoin's proof of work, applied to the existing chain at a set height. There is no new chain, no new asset and no distribution of anything: the coins in a Shrike wallet are the Bitcoin that was already there, with the history it always had. What changes past the activation height is how blocks are hashed and how transactions are signed.

Can I run Shrike and Sparrow on the same machine? #

Yes. Shrike has its own home folder, packages, desktop entries, MIME registrations and macOS bundle identifier, so neither installation touches the other's state. Wallet files are not shared between them: a wallet you want in both has to be opened in both.

What happens to coins I held before activation? #

They are the same coins, and the fork neither duplicates them nor issues anything alongside them. But 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 a transaction spending pre-fork coins stays valid on the SHA256d chain too. Sweep every pre-fork UTXO to yourself before transacting with anyone still running them.

What node do I need? #

Bitcoin Knots at v29.4.1.knots20260508 or any later release, either directly or behind your own Electrum server. It is also the only node that reports the activation height, through getdeploymentinfo, which is what lets Shrike cross check its compiled-in height rather than trusting it.

Does my hardware wallet work? #

It signs either way. Whether it can produce the new hash type depends on its firmware, and nothing the device reports says which firmware it runs, so Shrike does not guess: you mark the keystore yourself under Replay protection. An unmarked device still signs, with the hash type it can produce, and the send screen reports what the transaction actually got.

Stock firmware cannot produce it yet. Unofficial builds exist for Coldcard, SeedSigner and every current Trezor, and flashing one voids the manufacturer warranty; see hardware wallet firmware before you consider it.

My signer says signing failed. Are my coins stuck? #

No. A refusal produces no signature, so there is no transaction, nothing was broadcast, and the coins have not moved. Your seed still spends them, and nothing about the wallet or the device has damaged them.

What happened is a mismatch between what the wallet asked for and what the firmware can do. The keystore is marked under Replay protection, so Shrike asked for the new hash type, and the firmware on the device does not implement it. A signer that cannot produce the type it was asked for adds nothing, rather than quietly signing something else, so the device reports that no valid signature was added. SeedSigner words it "Signing with this seed did not add a valid signature". If the same device signed for you before and refuses now, what changed is that the keystore became marked, or the chain reached the activation height.

There are two ways on. Flash a build that implements the opt-in, listed under hardware wallet firmware, and the same transaction signs. Or untick the mark on that keystore in the wallet settings and send the ordinary way, which every stock signer can do. Be clear about what the second one costs: a signature without the opt-in is valid under the pre-fork rules too, so where those coins also exist on the SHA256d chain the transaction can be replayed there, and replay protection is exactly what you are giving up for the convenience.

Why can I not pick a public Electrum server? #

Because the ones Shrike inherited from upstream do not follow it. A server that did not take the upgrade stops at the activation height and carries on as the SHA256d chain, so it reports a history that ends there. Connect a Bitcoin Knots node at v29.4.1.knots20260508 or later, or your own Electrum server indexing one. Stock Fulcrum will not work either, for the same reason; builds with BLAKE2b support are available. See connecting a node.

Why are blocks smaller than they used to be? #

The fork carries temporary data storage limits alongside the proof-of-work change: roughly 300 kB serialized, about 800,000 weight units, from the activation height until 1 September 2027 at 00:00 UTC, after which nodes vote on them by median time past. Less space per block means more competition for it, so expect fee estimates to run higher than the pre-fork norm and size a transaction accordingly.

Why is only mempool.guide offered? #

mempool.guide is the one fee, explorer and broadcast service still on the current chain. A fee estimate 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, so the alternatives are removed rather than left in place to mislead.

Is a transaction replay protected if only one signer in my multisig is marked? #

Only when that signer takes part. One marked signer in the quorum that actually forms is enough, which is why the wallet reports the result on the send screen per transaction instead of promising it in advance. Marking two of a 2-of-3 makes it unconditional.

Why does the wallet say the activation height went unchecked? #

Because the node you are connected to does not report one. Only Knots does, through getdeploymentinfo. Shrike still opts in, and says the cross check did not happen rather than implying it did. Where a node does report a height and it disagrees with the compiled-in one, Shrike declines to opt in instead of following either.

Has this been audited? #

No. It is not audited and carries no warranty of any kind. Read the Apache 2.0 license.

Where do I report a problem? #

Problems specific to Shrike go to the issue tracker here. Anything that would also happen in Sparrow belongs upstream. The log file in the configuration directory is usually where the useful detail is.

Who wrote this? #

The v2 block header, the BLAKE2b proof of work, the separate application identity and the packaging were written by AcesHigh70, and are no longer maintained there. This fork continues that work and adds the unified opt-in signature hash. Sparrow itself is the work of the Sparrow project, which has not added support for it and is not affiliated with Shrike.