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
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
