Author: Johan Torås Halseth 2019-04-03 08:27:13
Published on: 2019-04-03T08:27:13+00:00
In a Lightning-dev mailing list, Johan commented on the proposal of implementing trampoline payments in the network. Johan thinks that the high-level direction of the proposal is good and it ties together several concepts proposed earlier. The correct design could give the sender all the flexibility needed to craft payments according to its own reliability/privacy/fee tradeoff. In an ideal world, multi-hop locks, packet-switched routing, rendezvous routing, and fees would be implemented. Johan admitted that he hasn't thought about the technical implications of all this and it would require a lot of work to get this actually implemented.On the same thread, ZmnSCPxj brought up an unrelated issue with trampoline nodes creating overlapping routes unintentionally. For example, when 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 the 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. There was also a suggestion to switch to payment points/scalars soon.
Updated on: 2023-06-02T18:03:59.196775+00:00