pull down to refresh
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
nfield is provided:- MUST use the
nfield 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
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!