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 rulelow-S:
    • 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

Yes, exactly! Created a PR.

reply