On Wed, 3 Apr 2019, 05:42 ZmnSCPxj via Lightning-dev < lightning-dev@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 :-) >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
