[Lightning-dev] Forwarding hints in channel update messages

Joost Jager joost.jager at gmail.com
Thu Nov 15 12:37:49 UTC 2018

On Thu, Nov 15, 2018 at 1:53 AM Rusty Russell <rusty at rustcorp.com.au> wrote:

> The decision was made to allow additional channel_update in the error
> reply:
>         DECISION: document that scid is not binding, allow extra
>         channel_updates in errors for “upselling”.

Yes, I read this. What exactly is "upselling" in this context and how were
extra channel_updates in errors intended to be used for this? Is it useful
for non-strict forwarding nodes?

> AFAICT this is a deeply weird case.  If another channel had capacity you
> would have just used it.  If another channel doesn't, sending a
> channel_update doesn't help.  And if there's a channel available at a
> higher feerate or longer timeout, it raises the question of why you're
> doing that rather than just taking the offer in front of you; that value
> clearly used to be acceptable, and now you risk them routing around you.

Good point. If the value is acceptable, but that particular channel happens
to have not enough balance, it is hard to explain why you wouldn't just
accept. Maybe if you have a large capacity channel that you want to reserve
for large amounts at a higher fee and you don't want this channel's balance
to be used up by multiple non-strict forwarded small htlcs? This could also
be realized by setting min_htlc, but then it can never be used for small
htlcs. This admittedly is pretty specific.

Maybe the forwarding hint that could make more of a difference is just the
information that non-strict forwarding was actually applied. Communicate
this as a node property via a global feature bit. If the sender receives a
TemporaryChannelFailure from a non-strict forwarding node, it doesn't need
to bother with trying all other (equal policy) channels from that node to
the next.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181115/90e25246/attachment.html>

More information about the Lightning-dev mailing list