2

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?

3

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.