Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2019-04-03 📝 Original message: On Wed, 3 Apr 2019, 05:42 ...

📅 Original date posted:2019-04-03
📝 Original message:
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>;