Docs

Shrike FAQ

Questions specific to this fork. 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 under the old rules 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.

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 under the pre-fork rules, 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 that has adopted the fork. 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 this fork 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 adopted the fork and is not affiliated with Shrike.