bolt04: add explicit requirement for final nodes to reject short_channel_id#1303
Conversation
…nel_id Final nodes should reject payments where short_channel_id is present in their payload, as this field is only meaningful for forwarding nodes. This requirement was implicit but not explicitly documented in the validation rules for final nodes.
|
It does create undefined behavior, but I'm not sure it's much of an issue since this case should never happen with a BOLT-compliant writer and it doesn't hurt the reader? As a general rule of thumb, we must be strict in what we write, but we can be lenient in what we read when it's harmless, which avoids unnecessarily listing every harmless case in the spec to keep it somewhat compact. We have a lot of similar cases for various messages, and it would add a lot of requirements to the BOLTs to "fix" them all, so I'm not really sure we should do it? |
|
Thanks for the review!
Yes.
I'll close this PR. Although I would prefer a more detailed spec that explicitly covers all undefined behaviors, I understand this would add maintenance burden without much practical benefit. |
Final nodes should reject payments that include
short_channel_idin their payload, as this field is only meaningful for forwarding nodes. While BOLT 4 specifies that writers MUST NOT includeshort_channel_idfor the final node, it doesn't explicitly require final nodes to return an error when this field is present.Current spec (writer requirements):
Current spec (reader requirements):
This ambiguity has led to implementation inconsistencies:
This inconsistency was discovered through differential fuzzing (bitcoinfuzz), where the same onion was rejected by LND and rust-lightning but accepted by Core Lightning.
This PR adds an explicit requirement for final nodes to return an error if
short_channel_idis present in the payload, making the validation requirements consistent with the writer requirements.