pull down to refresh

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!
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