Shrike 2.5.4-blake2b.5 - block headers past the BLAKE2b fork

Superseded by v2.5.4-blake2b.6. This build carries the rc3 schedule and cannot opt in against an rc4 node: testnet4 activation moved from 150027 to 150308, so this build and the node disagree about the height and the wallet signs the legacy way on every connection. It also carries no mainnet activation height, and pins a mainnet header from above the fork. 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.knots20260508rc3 defines it, on upstream Sparrow 2.5.4.

Builds published before this one cannot verify a confirmation above height 149183 on testnet4 and must be replaced. A transaction confirmed above the last compiled-in checkpoint is reported with no confirmations and raises a verification refused dialog naming the connected server, which is not at fault.

Changes since .4

Block headers are read at the length each one carries. A header is 164 bytes from the fork on, not 80. The response check rejected any range spanning activation outright, the chunk split read every header after the first from the middle of its predecessor, and the header store wrote 164 bytes into an 80 byte record. Since the forward sync asks for a full difficulty period at a time, a single chunk spanning the crossing left the store empty and every height above the last pin unprovable.

A v2 block is identified by the BLAKE2b hash the chain links on. The fork replaces the block identifier along with the proof of work, so a v2 header's SHA256d is not a block id at all. Computed the old way, no header past activation links to its parent.

An existing header store is re-verified from the pinned checkpoint on load and truncates at the first record that no longer links, so it repairs itself on first run at the cost of a re-download. Wallet files are not touched.

Verified

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

Against a live testnet4 server. The 1191 header response that was being refused now splits into its 843 v1 and 348 v2 headers, links from the pinned checkpoint at 149183 through to the tip, and reconstructs the merkle root of the block whose proof was refused. The first v2 header lands at height 150027, the activation height this build ships.

Against a node built from rc3. All 121 headers of a regtest chain crossing activation hash to the identifier getblockhash reports, where 11 of them did not before. On the 105 archived testnet4 v2 headers, every consecutive pair links.

Carried forward from .4, unchanged by this release: Knots' own feature_unified_sighash; 166 cross-implementation vectors across all four script types; an opted-in send accepted and mined; a pre-activation input spent after activation; an early opt-in refused where the fork is unscheduled; CVE-2020-14199 blocked under the opt-in and reproduced without it. A node at /Knots:20260508rc3/ reports blake2b {height: 150027, active: true}, matching the height this build ships.

309 wallet and 596 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.5.

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.

Do not use on mainnet

No build carries a mainnet activation height, so past activation the wallet declines to opt in and signs the legacy way, as it does anywhere if even one keystore is hardware-held. 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. Opting in is what prevents that. The wallet says so in its status; it does not stop you.

Built from privkeyio/sparrow@fe6dfbff with privkeyio/drongo@69ecf14, on upstream Sparrow 2.5.4.

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.