BOLT 11 - Is `n` mandatory or not? \ stacker news ~lightning

pull down to refresh

BOLT 11 - Is `n` mandatory or not?bitcoin.stackexchange.com/questions/129316/bolt-11-is-n-mandatory-or-not

1321 sats \ 3 comments \ @ek 2h lightning

I have read the following in the BOLT 11 specification:

[a writer] MAY include one n field. (Otherwise performing public-key recovery is required)

[a reader] MUST fail the payment if any mandatory field (p, h, s, n) does not have the correct length (52, 52, 52, 53).

This is confusing to me because it sounds like n is mandatory for the reader, but not for the writer.

Is what this wants to say this: IF n exists, THEN parsing the public key correctly is so important that we MUST fail the payment if the length is wrong, since the public key will be used to verify the signature?

Is that also the correct rationale?

Should this be clarified in the specification?

I tried to look through the commit history, but I only found this ¹ regarding n (and the answer to a different question I had: why is a description required? ²).

view all related items

222 sats \ 2 replies \ @endothermicdev 1h

This piqued my curiosity so I hand decoded a bolt11 to check - it had s, p, d, x, c, r, and 9 tagged fields. I guess n is not typically included because you can calculate the public key from the message (bolt11) along with the signature. Omitting it saves space.

Of the tagged fields, only d or h should be included (a description or a hash of the description if it's too long to fit.) p and s are required for payment hash and payment secret, but n is optional. Those still have a mandatory length (even though they have a length field in the invoice) otherwise the reader wouldn't know what to do with them and shouldn't proceed. Keeping these fields with a data length parameter leaves some flexibility for future spec changes I suppose.

Is what this wants to say this: IF n exists, THEN parsing the public key correctly is so important that we MUST fail the payment if the length is wrong, since the public key will be used to verify the signature?

That's my interpretation as well.

100 sats \ 1 reply \ @ek OP 32m

Thanks for looking into it!

Do you think this deserves to be clarified? I have some ideas on how and could draft a PR, but I’m honestly a bit intimidated by proposing something to the lightning specification; it feels like a big deal, haha

I also considered that I could “just” look into how other implementations handle this, but I thought this would bias me too much toward just reading an implementation of the spec instead of the spec itself. The purpose of a spec is that one can implement it without referencing existing code, right?

Edit: I'll draft a PR and explain what motivated it. Doesn't mean it needs to get merged!

100 sats \ 0 replies \ @endothermicdev 12m

It's really just this line that's confusing, right? Because n isn't really mandatory.

A reader:

MUST fail the payment if any mandatory field (p, h, s, n) does not have the correct length (52, 52, 52, 53).

Because later it's more clear with:

A reader: ...

if a valid n field is provided:

MUST use the n field to validate the signature instead of performing public-key recovery.

If the signature is not compliant with the low-S standard rule<sup>low-S</sup>:

MUST fail the payment

If it confused you, I'm sure it's confused others. I think it's worthwhile to fix unclear wording in the spec.

Footnotes