4. Reproducing a signature

A device that makes randomised signatures can leak your private key through valid transactions alone: grind the nonce until chosen bits of the signature encode part of the key, publish, repeat. Every signature verifies, and nothing on the device looks wrong.

nullroute is deterministic instead:

• ECDSA nonces come from RFC 6979
• Schnorr signing uses BIP-340 with aux_rand fixed to 32 zero bytes

So given the seed and the PSBT, the signature bytes are fully determined, leaving no free space to hide anything in.

To check, sign the same unsigned PSBT with the same seed in any independent implementation that does RFC 6979 and BIP-340 the same way, and compare bytes. A difference means the device put something in your signature that it did not have to.

In CI, the test suite signs one p2wpkh PSBT one hundred times and asserts byte-identical output each time, and signs one taproot input three times and compares. The differential suite checks p2wpkh signature bytes against bitcoinjs-lib; no Schnorr signature is compared with another implementation. Neither replaces checking a signature you care about.

This is a trade. BIP-340 permits a randomised aux_rand, which defends against certain fault injection attacks. Fixing it to zero gives that up for verifiability: right for a device you are meant to audit, but a real trade.

---