[Lightning-dev] Outsourcing route computation with trampoline payments

[ZmnSCPxj]

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