Hi Pierre and list folks, I haven't looked at the technical implications of implementing this in detail, but I like the high-level direction this proposal is taking :)
I think it nicely ties together several concepts that have been proposed earlier, and with the correct design could give the sender all the flexibility needed to craft payments according to its own reliability/privacy/fee tradeoff. In an ideal world we would have: - Multi-hop locks: hop decorrelation will be even more important when the sender no longer controls the whole payment path. - Packet switched routing: the sender can choose whether to route purely packet switched (only knowing the destination, no need to keep any routing table) or route purely onion-based (as today), or something in between. As Christian mentions, this is similar to how TOR/TCP works, and I like the flexibility this layering allows. - Rendezvous routing: such a proposal would be nice to combine with rendezvous routing. This way even the sender wouldn't necessarily know if the "destination node" is just another trampoline. Maybe maybe this concern shouldn't be on this layer though? - Fees: (as today) the sender would set the fees it is willing to pay between trampolines, and it could dynamically learn about fee levels needed to reach different parts of the network. Today we know the fee needed to reach the next hop, but here we could start out low (for the trampoline-to-trampoline fee) and let different trampolines return competing fee offers to get to the next hop. As mentioned, I haven't thought about the technical implications of all this, and it would certainly require a lot of work to get this actually implemented. Cheers, Johan On Wed, Apr 3, 2019 at 5:42 AM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > 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 >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
