Why do Lightning packets include channel ids if forwarding is non-strict?

Question

The onion packets in Lightning, as described in BOLT 4, include short_channel_id's of the channels along the route constructed by the sender. But according to the same spec, the forwarding is non-strict, meaning that if the payment is meant to be forwarded from an intermediary node X to an intermediary node Y, X is free to choose any of the channels between itself and Y (a pair of nodes may have multiple channels).

Isn't the short_channel_id's in onion packets excessive? Could we just specify a list of nodes along the suggested route and let each node choose the best channel to the next one?

Answer 1

I guess this has historical reasons. The short channel ids where there first in the onion format. C Lightning even today does not support multiple channels between 2 nodes. Lnd on the other hand does. That is why lnd developers started to switch the channel if a second channel with enough balance between the nodes existed. Later on it was agreed to add the statement about non strict forwarding - which you referenced - to the spec.

While working with node ids would work it has some drawbacks.

1. We would have to make a backward compatible change to the onion format
2. Short channel ids consume less space I think 8 byte in comparison to 33byte of nodeids (remember the onions only have 65 byte per hop payload)
3. Short channel ids can be verified in case of private channels. I can check the blockchain for an unspent funding transaction.