<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>

CC BY-SA 4.0
2019-07-16T09:24:35.607Z
2019-07-16T09:24:35.607Z
Rene Pickhardt
<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>

<lightning-network><lightning-routing><channels>
Why do Lightning packets include channel ids if forwarding is non-strict?
Sergei Tikhomirov
# Why do Lightning packets include channel ids if forwarding is non-strict?

(Asked by: username_0 on 2019-07-16)

The onion packets in Lightning, as described in [BOLT 4](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md), include `short_channel_id`'s of the channels along the route constructed by the sender. But according to [the same spec](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md#non-strict-forwarding), 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?

**Tags:** lightning-network, lightning-routing, channels


---

## 1 answers

### Answer by username_1 on 2019-07-16. Score: 5 | Accepted answer

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.


---

