Shrike 2.5.5-blake2b.17 - superseded by blake2b.19

Superseded by blake2b.19. The unified sighash capability moved from 28 to 29 in firmware unified-sighash.2, and this build still looks for 28, so on that firmware it refuses every opt-in. The firmware release this one paired with has been withdrawn. If you installed this version, reflash to unified-sighash.2 and take .19. The files below are left in place for anyone already on it. A mismatch refuses to sign rather than producing a signature without the protection it claims.

Shrike signing with the unified opt-in signature hash as Bitcoin Knots v29.4.1.knots20260508 defines it, on upstream Sparrow 2.5.5. Everything in 2.5.5-blake2b.16, plus the Trezor path.

If you do not use a Trezor

Nothing changed in this release, and nothing below applies to you. It was the Trezor path only. Take .19 instead.

If you use a Trezor

Required Trezor Model One firmware 1.14.2-unified-sighash.1 on the device, which has since been withdrawn.

Shrike could already build a PSBT declaring hash type 0x21. Nothing carried that request to a Trezor. The protobuf had no field for it, the Trezor path never read the hash type the PSBT declared, and every signature that came back was stamped SIGHASH_ALL regardless of what the device had actually done.

So a device that implements the opt-in would have signed the legacy message and handed back a transaction the wallet labeled as replay protected. That is what this closes: the request reaches the device, and the hash type recorded on the signature is the one the device really used.

Each of these is refused rather than signed, because the alternative is a transaction that looks protected and is not. Only a transaction that asks for the opt-in is affected; ordinary signing on any of these devices is unchanged.

• The device's firmware does not implement the opt-in. Checked before signing rather than discovered afterwards, because firmware without the field ignores it silently. KeepKey and OneKey Classic devices take this same path and will never report the capability, so they are refused here too, and the message now names whichever device is in hand rather than always saying Trezor.
• Any unified hash type other than 0x21. Trezor signs SIGHASH_ALL and nothing else, so the other five have no counterpart to ask for. They are refused rather than quietly downgraded.
• An input the device cannot sign sitting alongside an opted-in one. The unified message commits to every input's script, and an unsignable input is handed a stand-in, which would corrupt every opted-in signature in the transaction.

After signing, the PSBT is re-parsed with verification, which a legacy-digest signature fails.

Verification

Twenty end to end checks against a Bitcoin Knots v29.4.1.knots20260508 regtest node, every transaction judged by the node rather than by an assertion in the harness: each script type opted in and mined carrying 0x21, the legacy controls mined carrying 0x01 and taproot 0x00, a 2-of-2 with the second key on the device, all six non-ALL unified types refused, the wallet's own decision path across marked, unmarked and fork-inactive, and a quorum wallet producing one input carrying 0x01 and 0x21 side by side.

Refusal was verified against a stock Model One emulator, which is the case that matters: refused before signing, and ordinary signing on it still works.

The firmware has been flashed to a real Model One and used to sign a mainnet transaction with the opt-in confirmed present. That is one device and one signing session.

The lark change had three independent review passes. The first found that the original guard was tautological: it read the hash type off the returned signature, a field the wallet stamps itself, so stock firmware produced a transaction labeled 0x21 that was invalid under both rule sets.

Builds are reproducible: on a second machine with the same JDK, every file this project produces is byte-identical, the only difference being five bytes in the bundled Java runtime image that jlink itself varies.

No warranty

This is unofficial, unaudited software provided as is, with no warranty and no liability, under the same Apache 2.0 license it inherits. It is not a Sparrow release and is neither affiliated with nor supported by the Sparrow project, nor by Trezor, KeepKey or OneKey. Using it is entirely at your own risk, and you alone bear any loss of funds.

Verifying this release

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 notarized and the Windows installer is not Authenticode signed. Reproducible: see reproducible.md.