NUT-11 uses compressed pubkeys where xonly is called for

[conduition]

NUT-11 says:

The recipient who owns the private key of the public key Secret.data can spend this proof by providing a signature on the serialized Proof.secret string that is then added to Proof.witness.signatures

We use libsecp256k1's serialized 64 byte Schnorr signatures on the SHA256 hash of the message to sign.

However, in the examples, the pubkey specified in the Secret.data field is a 33-byte compressed key. The schnorr signature verification function of libsecp256k1, as with any BIP340 implementation in general, requires a 32-byte x-only public key.

I suggest either:

• We modify the spec to use x-only public keys for the P2PK Secret.data field
• We specify explicitly that NUT-11 public keys must always be even parity (leading 02 byte)
• We specify explicitly that NUT-11 public keys can be either parity, and implementations must chop off the leading byte before verifying signatures.

[callebtc]

It seems odd to me that your secp implementation requires an x-only key. The libsecp256k1 Schnorr signature verification in the Python interface does not assume any parity and requires the public key to be either 33 or 65 bytes.

Could you confirm that your lib is not able to verify signatures with an odd parity (03)?

[conduition]

I'm not using any specific library for anything at the moment. The BIP-340 specification - which libsecp256k1's schnorr signatures are based on - takes an xonly key as input to the verification algorithm:

libsecp256k1 specifically takes an xonly key as input when verifying schnorr sigs.

I'm assuming you're using the secp256k1 package from PyPi? That library only allows schnorr verification after parsing an xonly key as a point, but internally it passes the xonly representation of the key to libsecp256k1, so the parity bit is not necessary information.

Some libraries do this same thing, accepting a Point-like type:

• https://pkg.go.dev/github.com/btcsuite/btcd/btcec/v2/schnorr#Signature.Verify
• https://docs.rs/musig2/0.0.11/musig2/fn.verify_single.html

Others like libsecp256k1 expose a separate type for xonly keys or simply require an untyped 32-byte array as input. References:

• https://docs.rs/secp256k1/0.29.0/secp256k1/struct.Secp256k1.html#method.verify_schnorr
• https://github.com/paulmillr/noble-curves/blob/e14e37ae3415b634d1fc7d751ea8b11a59dda35d/src/secp256k1.ts#L186

Verification works regardless of the points' parity, because fundamentally BIP340 verification only uses the X-coordinate of the pubkey and signature nonce as input.

My point is that in the cashu spec, we should reference upstream specs (BIP340), not upstream implementations (secp256k1-py). The input we're providing to BIP340 signature verification in NUT-11 doesn't match the upstream spec. It leaves the cashu implementation to decide how to fix the ambiguity.

Speaking of ambiguity: A signature issued by 02xxxx... will also verify under the pubkey 03xxxx.... I don't think this is a problem for NUT-11, but for future NUTs which use NUT-11 as precedent, it could be.

If you want to keep the status quo without changing the spec too much, i'd suggest we go this route.

We specify explicitly that NUT-11 public keys can be either parity, and implementations must chop off the leading byte before verifying signatures.

But going forward with new NUTs if we use BIP340 signatures again, we should use the spec as intended, and use xonly pubkeys to avoid potential unforeseen bugs.