pull down to refresh

323 sats \ 4 replies \ @endothermicdev 10 Dec \ on: BOLT 11 - Is `n` mandatory or not? lightning
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.
write
preview
100 sats \ 2 replies \ @ek OP 10 Dec
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!
reply
122 sats \ 1 reply \ @endothermicdev 10 Dec
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.
reply
100 sats \ 0 replies \ @ek OP 10 Dec
Yes, exactly! Created a PR.
reply
0 sats \ 0 replies \ @ek OP 6h
Another interesting observation: you basically immediately replied to me here on SN, but on Bitcoin Stack Exchange, nobody replied yet :/
reply