Shrike 2.5.4-blake2b.6 - the rc4 schedule and mainnet activation

Superseded by v2.5.5-blake2b.7. This build cannot connect to a node behind a TLS terminating proxy, which covers most self hosted setups: an entered https scheme is overwritten based on the port, and the resulting failure reports Cannot invoke ErrorMessage.toString() because <parameter1> is null rather than the cause. Its replay protection status can also go stale after a node upgrade. Kept here so the files already downloaded can still be verified against its signed manifest.

Shrike signing with the unified opt-in signature hash as Bitcoin Knots v29.4.1.knots20260508rc4 defines it, on upstream Sparrow 2.5.4.

Builds published before this one carry the rc3 schedule and must be replaced. testnet4 activation moved from 150027 to 150308, so an earlier build and an rc4 node disagree about the height and the wallet declines to opt in on every connection. The chain above the old height was replaced along with it.

The schedule

• testnet4 activates at 150308, moved from 150027.
• Mainnet activates at 961640. No previous build carried a mainnet height, so none of them opted in there. This one does, once the chain reaches it and the connected node agrees.

Upgrade the node before the wallet. While a node still reports the rc3 height the cross-check reads a disagreement and signs the legacy way, which is correct but looks like a fault.

Header verification across the fork

The one-off difficulty shift is applied. At the activation height the required target moves left by Blake2bTargetShift, which mainnet pins at 22, capped at the proof of work limit. Without it the header at that block is refused and the sync stops there, leaving every height above it unprovable, which shows as confirmed transactions with no confirmations.

A pinned header above the activation height has been removed. The checkpoints are inherited from upstream, which follows the chain that kept the old proof of work, so above the fork its hashes are not the ones this wallet verifies against. Mainnet pinned 961631 and 963647; the second is 2007 blocks past activation and carries an ordinary pre-fork target where the shift puts the forked chain three exponents easier. Anchoring there would have linked every mainnet height to a block a Knots node does not have. The last pin is now nine blocks below activation, on history that predates the fork, so the store syncs forward across it.

Hardware signers can opt in

A device is no longer refused outright. Mark it under Replay protection in the keystore tab, or from the send screen where the wallet says it is not replay protected. Off by default: nothing a device sends says which firmware it runs, and one asked for a hash type it does not implement adds no signature at all and reports a failure of its own, which an airgapped device gives the wallet no way to notice.

Measured against stock embit, a PSBT this build produces for a marked device is signed with hash type 0x21 by firmware that implements the opt-in, and skipped entirely by firmware that does not.

Also

• The server settings and connection errors name Bitcoin Knots, which is the only node this build can use: it reads the schedule from getdeploymentinfo, which Bitcoin Core does not report.
• The udev rules dialog names the directory this build installs to. It named /opt/sparrowwallet, which no build here creates, so the install failed and USB devices did not connect.
• New application artwork throughout, and the About dialog describes this wallet rather than Sparrow.

Verified

Reproducible. Building this commit locally with Eclipse Temurin 25.0.2+10 produces an application tree byte-identical to the one CI published. As upstream notes, this covers the .tar.gz and .zip contents, not the installers.

Against the rc4 tag. The mainnet height, the testnet4 height and the shift are read from v29.4.1.knots20260508rc4 rather than a branch. The signature hash message is unchanged from rc3: the vectors and the specification are byte-identical between the two tags, and the copies in drongo and embit match them.

320 wallet and 600 drongo unit tests.

Downloads

Platform	File
Windows	Shrike-2.5.4.msi, or .zip for a portable copy
macOS	Shrike-2.5.4-arm64-unsigned.dmg, or -x86_64-unsigned.dmg for Intel
Linux x86_64	shrike_2.5.4-1_amd64.deb, or -x86_64.tar.gz
Linux aarch64	shrike_2.5.4-1_arm64.deb, or -aarch64.tar.gz
Headless	the shrikeserver-* files

The macOS builds are not code signed or notarized. Notarization needs a paid Apple Developer account this project does not have. macOS will refuse to open the app on first launch, reporting it as damaged or from an unidentified developer; that means it is unsigned, not that the download is bad. To run it:

xattr -dr com.apple.quarantine /Applications/Shrike.app

Verify SHA256SUMS before doing that. Clearing quarantine removes the check that would otherwise stop a tampered download, so the signature is the only assurance left.

The Windows installer is not Authenticode signed either, and SmartScreen will warn. Upstream Sparrow does not sign its installer either.

Installs to /opt/shrike with its config in ~/.shrike, alongside an existing Sparrow rather than over it. The app reports its version as 2.5.4-blake2b.6.

gpg --import privkeyio-signing-key.asc
gpg --verify SHA256SUMS.asc SHA256SUMS
sha256sum --ignore-missing -c SHA256SUMS

Signed by Kyle Santiago kyle@privkey.io, key A47D99B6DB0D715D40C59A2023AE8A8EA7E24E38. All files come from one packaging workflow run and one manifest.

Still to check yourself

A signature that does not opt in is valid under the pre-fork rules as well as the new ones, so it can be replayed against nodes that have not adopted the fork. The wallet reports which it did, per transaction, and signs the legacy way wherever the chain, the node or a keystore does not allow the opt-in.

No warranty

This is an unofficial, unaudited build provided as is, with no warranty and no liability, under the same Apache 2.0 terms as the LICENSE it inherits. It is not a Sparrow release and is neither affiliated with nor supported by Sparrow Wallet. Running it is entirely at your own risk, and you alone bear any loss of funds.

This is a fork built to exercise a consensus change. Do not point it at a wallet holding funds you cannot afford to lose.

Built from privkeyio/sparrow@cbcc0e9a with privkeyio/drongo@96454e22, on upstream Sparrow 2.5.4.