4

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?

Murch
  • 71,155
  • 33
  • 180
  • 600
Sergei Tikhomirov
  • 1,430
  • 7
  • 17

1 Answers1

5

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.
Rene Pickhardt
  • 11,670
  • 8
  • 35