add deterministic NUT-20 quote locking derivation

[Egge21M]

Summary

Adds deterministic wallet seed derivation guidance for NUT-20 quote locking keys using the Cashu SLIP-0044 coin type and a NUT-20-specific BIP32 path.

Updates the NUT-20 test vectors with the first five derived compressed secp256k1 public keys for the documented mnemonic.

Validation

• Compared Egge21M:nut-20-locking against cashubtc/nuts:main with the GitHub connector: 1 commit ahead, 0 behind
• Reviewed the local diff for 20.md and tests/20-test.md
• No local test runner or workflow config is present in this checkout

[callebtc]

wut

[Egge21M]

Fixed :)

[robwoodgate]

As per my comment on the related deterministic P2PK key spec ( #331 ), unless there is an overwhelmingly strong reason to use BIP32, then a HMAC-SHA256 KDF is much faster, unless BIP-32 is carefully handled.

Pattern                                          Cost/key   vs HMAC
HMAC-SHA256                                       ~165 µs    1.0×
BIP-32 parent-cached, HDKey.publicKey             ~172 µs    1.0×    natural restore-loop code
BIP-32 master-cached, full path per derive        ~862 µs    5.2×    natural single-derive code
BIP-32 cold, no caching                          ~1216 µs    7.4×    worst case

[robwoodgate]

I have proposed a HMAC-SHA256 KDF derived alternative, which would close this PR

[Egge21M]

I have proposed a HMAC-SHA256 KDF derived alternative, which would close this PR

Iirc this has been discussed in the past in Leitos original PR for P2PK locking keys. Using BIP32 might be a tad slower, but it leaves the possibility to build something with the extended public keys. Imagine a watch-only wallet for mint quotes

[robwoodgate]

I have proposed a HMAC-SHA256 KDF derived alternative, which would close this PR

Iirc this has been discussed in the past in Leitos original PR for P2PK locking keys. Using BIP32 might be a tad slower, but it leaves the possibility to build something with the extended public keys. Imagine a watch-only wallet for mint quotes

Yeah, am not convinced it would not be a huge linkability issue compromising privacy. I mentioned it in my replacement pr

[Egge21M]

Yeah, am not convinced it would not be a huge linkability issue compromising privacy. I mentioned it in my replacement pr

This is both a bug and a feature. I think we have general consensus about a quote-lookup-by-pubkey API, so this would literally allow watch-only / notification / aggregation services.
Putting that aside: The performance gain is marginal. Alignment with the spec is given, as P2PK keys are already BIP32. CDK and Coco both already ship BIP32 derivation for P2PK locks.

[robwoodgate]

Yeah, am not convinced it would not be a huge linkability issue compromising privacy. I mentioned it in my replacement pr

This is both a bug and a feature. I think we have general consensus about a quote-lookup-by-pubkey API, so this would literally allow watch-only / notification / aggregation services.

Putting that aside: The performance gain is marginal. Alignment with the spec is given, as P2PK keys are already BIP32. CDK and Coco both already ship BIP32 derivation for P2PK locks.

Yeah, unfortunately that was kind of a premature shipping before spec sign off.

We moved away from bip32 for keysets v2+. Baking that dep into future stuff means apps will have to carry it a long time more.

The performance gain is only marginal if you are batch deriving. If you have to derive sporadically for any reason performance drops off a cliff

[robwoodgate]

Following offline discussion, and the fact this is already live, I've closed #384.