ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-04-03 📝 Original message: Good morning Pierre and ...

📅 Original date posted:2019-04-03
📝 Original message:
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