[Lightning-dev] Outsourcing route computation with trampoline payments

Christian Decker decker.christian at gmail.com
Wed Apr 3 09:01:50 UTC 2019

On Wed, 3 Apr 2019, 05:42 ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Good morning Pierre and list,
> >     There is another unrelated issue: because trampoline nodes don't know
> >     anything about what happened before they received the onion, they may
> >     unintentionnaly create overlapping routes. So we can't simply use the
> >     payment_hash as we currently do, we would have to use something a bit
> >     more elaborate.
> Just to be clear, the issue is for example with a network like:
>     A ------- B -------- C
>              / \
>             /   \
>            /     \
>           /       \
>          D ------- E
> Then, A creates an inner trampoline onion "E->C", and an outer onion
> "A->B->E".
> E, on receiving the inner trampoline onion "E->C", finds that E->B
> direction is low capacity, so routes over the outer onion "E->D->B->C" with
> inner trampoline onion "C".
> This creates an overall route A->B->E->D->B->C.
> When the B->C HTLC is resolved, B can instead claim the A->B HTLC and just
> fail the D->B HTLC, thereby removing D and E from the route and claiming
> their fees, even though they participated in the route.

This is not an issue. Like we discussed for the multi-part payments the
HTLCs still resolve correctly, though node B might chose to short circuit
the payment it'll also clear the HTLCs through E And D (by failing them
instead of settling them) but the overall payment remains atomic and
end-to-end secure. The skipped nodes (which may include the trampoline) may
lose a bit of fees, but that is not in any way different than a failed
payment attempt that is being retried from the sender :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190403/326187f0/attachment.html>

More information about the Lightning-dev mailing list