[Lightning-dev] Forwarding hints in channel update messages

Joost Jager joost.jager at gmail.com
Wed Nov 14 08:17:14 UTC 2018

Hello all,

I'd like to bring up an idea that builds on top of "non-strict" forwarding.
I commented about this on conner's non-strict forwarding lightning-rfc pr,
but it is probably better to discuss it on its own in this list.

A node that forwards non-strictly, is using any of its channels to carry
the payment to the next hop. It is ignoring the actually requested channel
in `update_add_htlc`, except for determining the next hop pubkey.

When forwarding fails, a `channel_update` msg can be returned to the
sender. This brings up the question for which channel to return a
`channel_update` in case of failed non-strict forwarding.

If the htlc didn't satisfy the policy of the requested channel, the
sender's view on the graph is not up to date and it makes sense to return a
`channel_update` for the requested channel.

However, if the htlc did satisfy the policy, sending back a
`channel_update` does not provide the sender with any new information. In
case of TemporaryChannelFailure, the update is optional. But leaving it out
does not save any bytes because of padding (as pointed out by pierre in the

The idea is to repurpose the `channel_update` message in this case as a
'forwarding hint'.

When non-strict forwarding fails, the intermediate node iterates over all
its channels to the next hop and determines what would be the 'best'
channel to use from the sender point of view. Best could be defined as a
trade off between minimum fee and time lock delta, similar to the weight
function used during path finding. Only channels that have enough balance
for the amount requested in the htlc are considered in this process.

If there is no best channel (for example when none of the channels have
enough capacity), the node just returns a `channel_update` for the
requested channel as usual.

If there is a best channel, a `channel_update` is returned for that channel
instead of the requested channel. Senders that are aware of this behavior
will recognize this when reading the failure message and interpret the
`channel_update` as a forwarding hint.

Senders not aware of the forwarding hint will either just apply the channel
update to the graph or reject it. Both are fine, because their copy of the
policy for the requested channel was already up-to-date. This makes this
idea backwards compatible.

What this forwarding hint signals is that an htlc with a fee and time lock
delta that satisfies the policy of the hinted channel will likely be
forwarded successfully. Of course if something changes at the intermediate
node (channel balance) in the mean time, the hint may not be valid anymore.

With the hint in hand, the sender can adjust the route to satisfy the
hinted policy and try again. Alternatively, it could first try a route
through other nodes because the hinted policy increases the total fee
and/or time lock too much. How to exactly integrate this in path finding is
something to work out further. The sender should be aware that an
intermediate node may try to maximize its earning by handing out
'expensive' forwarding hints and therefore should not blindly apply the new
policy to a route.

The advantage of having the hint is that the sender likely needs fewer
payment attempts to complete the payment. For the intermediate node, it is
a way to increase its earnings. It gives the sender more certainty about
the parameters that lead to successful forwarding and the sender may choose
to just go with those instead of trying out many other routes, even if one
of those routes could be better. In case the sender wants the absolute best
route, the forwarding hint may still be beneficial to the intermediate
node. When there are multiple routes with identical total fees and time
locks, a sender will likely choose the route for which it has received
forwarding hints.

In case the intermediate node can only forward the payment over a private
channel, it could hint the policy of a public channel with a policy that
also satisfies the private channel's policy. It doesn't matter if this
public channel doesn't have enough balance, because non-strict forwarding
will also be applied on the next attempt. Or maybe just returning a
`channel_update` for channel id 0 with the private channel's policy.
Senders aware of forwarding hints may just as well interpret this properly.

To implement this, no onion packet changes are required. An intermediate
node could advertise that it provides forwarding hints through a global
feature bit, but that is optional. The forwarding hints can also be
recognized in the `channel_update` message itself.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181114/7ffeb2df/attachment.html>

More information about the Lightning-dev mailing list