Skip to content

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

Choose a tag to compare

@kwsantiago kwsantiago released this 04 Sep 13:30
· 30 commits to master since this release
4d6523f

Superseded by blake2b.19. Nothing here is wrong: .19 is this release plus upstream's latest fixes and vector artwork in place of the soft bitmap icons. The files below stay in place for anyone already on it, and the Trezor firmware requirement is the same for both.

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.

This replaces 2.5.5-blake2b.17, whose Trezor path cannot opt in against current firmware.

If you do not use a Trezor

Nothing about signing changes, and nothing below applies to you. The one visible difference from .16 is the application icons, which are now independent artwork rather than upstream Sparrow's.

If you use a Trezor

Requires firmware unified-sighash.2 on the device.

A Trezor announces the opt-in by reporting a capability number. Upstream has since assigned 28 to Capability_Ethereum_EIP7702, so the firmware moved the unified sighash capability to 29 rather than leave two meanings on one number. .17 still looks for 28, so on firmware unified-sighash.2 it reads the capability as absent and refuses every opt-in, which is the one thing that release exists to do. This release looks for 29 only.

Shrike could already build a PSBT declaring hash type 0x21, but nothing carried that request to a Trezor: the protobuf had no field for it, the Trezor path never read the declared hash type, and every returned signature was stamped SIGHASH_ALL regardless of what the device had done. The request now reaches the device, and the hash type recorded on the signature is the one the device really used.

Three things are 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 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.
  • 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 at 0x01 and taproot 0x00, a 2-of-2 with the second key on the device, all six non-ALL unified types refused, and a quorum wallet producing one input carrying 0x01 and 0x21 side by side. All twenty pass. Unit suites: drongo 615, Sparrow 383, lark 3, no failures.

Firmware unified-sighash.2 builds all five models; these checks are against the Model One. The opt-in path is not model-specific, so the others take the same code, but were not exercised.

Builds are reproducible: on a second machine with the same JDK, every file is byte-identical apart from five bytes in the bundled Java runtime 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.