Shrike 2.5.5-blake2b.9 - replay protection status and taproot fee estimates

Shrike signing with the unified opt-in signature hash as Bitcoin Knots v29.4.1.knots20260508rc4 defines it, on upstream Sparrow 2.5.5. First build published as a release rather than a prerelease.

Fixed

A watch only wallet is told something it can act on. It reported that a signer was not marked as supporting the opt-in, and sent the reader to a Replay protection control the keystore tab only draws for hardware sources. A watch only keystore has no device to mark, so it now says that and points at re-importing with the signing device as an airgapped hardware wallet.

Signatures are attributed to the keystores that made them. Signed keystores were determined against an assumed SIGHASH_ALL, so a finalized transaction signed with the unified hash type showed no signing keystore. From upstream Sparrow.

An opt-in with nothing to corroborate it says so. An Electrum server reports no activation height, so the cross check against the connected node cannot run and the opt-in rests on the height compiled into this build alone. That read identically to a confirmed one. It is now distinguishable in the send screen tooltip and logged once per connection. Signing is unchanged: an Electrum connection still opts in, because declining when a server cannot answer would forgo the protection on every Electrum setup.

Taproot fee estimates cover the signature actually made. There is no opted-in form of SIGHASH_DEFAULT, so an opted-in taproot signature is 65 bytes rather than 64 and the estimate was one weight unit an input short. Unrelated to a node refusing a transaction for insufficient relay fee: that is the node's mempoolminfee, which rises above minrelaytxfee as the mempool fills.

Bitcoin Knots is named where Bitcoin Core was, in the Taproot backend message and the descriptor export text.

Known limitation: multisig

The opt-in is all or nothing across a wallet's keystores. A 2-of-3 holding one signer that cannot opt in declines on every transaction, even where the other two would have been enough.

The protocol is more permissive. SIGHASH_UNIFIED is opted into per signature, so one opted-in signature is enough to make a transaction unreplayable: it does not verify under the pre-fork rules, which drops the input below its threshold.

Until the wallet matches that, mark every keystore and sign with the capable ones. The wallet then holds something false about the lagging signer, so a later transaction that needs it fails to sign rather than falling back. Upgrading its firmware is the better fix.

Verified

Reproducible: this commit built locally with Eclipse Temurin 25.0.2 produces an application tree in which all 171 paths hash identically to CI's, covering the .tar.gz and .zip contents rather than the installers.

Each fix above was checked by reverting it and confirming the test covering it fails, then restoring.

328 wallet and 610 drongo unit tests. Activation heights and the target shift are unchanged and still match the rc4 tag.

Downloads

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

Verify before running:

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.

The macOS builds are not code signed or notarized, so macOS will report the app as damaged or from an unidentified developer on first launch. That means it is unsigned, not that the download is bad:

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

Verify SHA256SUMS first, because clearing quarantine removes the check that would otherwise stop a tampered download. The Windows installer is not Authenticode signed either, and SmartScreen will warn accordingly.