user31712: 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?

user81940: 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. 

We would have to make a backward compatible change to the onion format
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) 
Short channel ids can be verified in case of private channels. I can check the blockchain for an unspent funding transaction. 


31712: <p>The onion packets in Lightning, as described in <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md" rel="nofollow noreferrer">BOLT 4</a>, include <code>short_channel_id</code>'s of the channels along the route constructed by the sender. But according to <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#non-strict-forwarding" rel="nofollow noreferrer">the same spec</a>, the forwarding is <em>non-strict</em>, 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).</p>

<p>Isn't the <code>short_channel_id</code>'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?</p>
 81940: <p>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. </p>

<p>While working with node ids would work it has some drawbacks. </p>

<ol>
<li>We would have to make a backward compatible change to the onion format</li>
<li>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) </li>
<li>Short channel ids can be verified in case of private channels. I can check the blockchain for an unspent funding transaction. </li>
</ol>
