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. > (maybe private keys?) Do you refer to the changing from "H"TLC to "P"TLC point-locked timelocked contracts? i.e. instead of payment hash / preimage, we use payment point / scalar. I think a few ideas would be improved by this. 1. Trampoline payments, as described above. 2. Offline vending machines - Instead of storing a fixed number of invoices from the always-online payment node, store a HD parent point and derive child points for payments. 3. Enables payment decorrelation. Perhaps we should consider switching to payment points/scalars sometime soon. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightningemail@example.com https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev