Johan Torås Halseth [ARCHIVE] on Nostr: 📅 Original date posted:2019-04-03 📝 Original message: Hi Pierre and list folks, ...
📅 Original date posted:2019-04-03
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190403/24eb7d58/attachment.html>;
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190403/24eb7d58/attachment.html>;