[Lightning-dev] Outsourcing route computation with trampoline payments
ZmnSCPxj at protonmail.com
Wed Apr 3 03:41:53 UTC 2019
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.
More information about the Lightning-dev