René Pickhardt [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-29 📝 Original message: Dear Pierre-Marie and ...
📅 Original date posted:2019-03-29
📝 Original message:
Dear Pierre-Marie and fellow lightning developers,
I really like that suggestion. In the context of JIT routing I was
tinkering about the same idea (is it possible for sending nodes to only
know a small part of the network - for example the friend of a friend
network - to save Hardware / gossip bandwidth requirements) but I was
thinking about a different solution which I want to drop in here. (I
believe yours is better though)
My thought was to use rendez-vous routing. This would mean the sender would
have to provide a rendez vous point from his local (friend of a friend?)
network and the recipient provides a route to him/herself. Only the
recipient has to know the entire network topology.
One problem with rendez vous routing is of course that the routing fails if
the route from the rendez vous point does not work. This again could be
mitigated with JIT routing.
In the context of JIT routing it also makes sense to "overpay" fees so that
JIT nodes could rebalance without loss. Making my solution also
probabilistic with the fees. The fact that this pattern of probabilistic
fees occurs for the second time now leads me to the following 2 more
general ideas (maybe we should start a new thread if we discuss them to
stay on topic here) that might help with routing.
1.) A different fee mechanism. Let us (only as a radical thought
experiment) assume we drop the privacy of the final amount in routing. A
sending node could offer a fee for successful routing. Every routing node
could decide how much fee it would collect for forwarding. Nodes could try
to collect larger fees than the min they announce but that lowers the
probably for the payment to be successful. Even more radical: Nodes would
not even have to announce min fees anymore. Turning routing and fees to a
real interactive market
2.) A virtual hierarchical address space. Maybe we should start thinking
about the creation of a semantic overlynetwork / address space for nodes
similar to IP. This would allow any node to just have a pruned network view
but still make smart routing decisions. Obviously we would have to find a
way to assign virtual network addresses to nodes which might be hard.
The second suggestion would be of particular interest in your case if N
also did not know the entire network and has to decide to whom to to
forward for the final destination D.
Sorry for "hijacking" your suggestion and throwing so many new ideas but in
my mind this seems all very connected /related.
Best Rene
Pierre <pm+lists at acinq.fr> schrieb am Do., 28. März 2019, 23:25:
> Hello List,
>
> I think we can use the upcoming "Multi-frame sphinx onion format" [1]
> to trustlessly outsource the computation of payment routes.
>
> A sends a payment to an intermediate node N, and in the onion payload,
> A provides the actual destination D of the payment and the amount. N
> then has to find a route to D and make a payment himself. Of course D
> may be yet another intermediate node, and so on. The fact that we can
> make several "trampoline hops" preserves the privacy characteristics
> that we already have.
>
> Intermediate nodes have an incentive to cooperate because they are
> part of the route and will earn fees. As a nice side effect, it also
> creates an incentive for "routing nodes" to participate in the gossip,
> which they are lacking currently.
>
> This could significantly lessen the load on (lite) sending nodes both
> on the memory/bandwidth side (they would only need to know a smallish
> neighborhood) and on the cpu side (intermediate nodes would run the
> actual route computation).
>
> As Christian pointed out, one downside is that fee computation would
> have to be pessimistic (he also came up with the name trampoline!).
>
> Cheers,
>
> Pierre-Marie
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-February/001875.html
> _______________________________________________
> 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/20190329/b604fc57/attachment.html>;
📝 Original message:
Dear Pierre-Marie and fellow lightning developers,
I really like that suggestion. In the context of JIT routing I was
tinkering about the same idea (is it possible for sending nodes to only
know a small part of the network - for example the friend of a friend
network - to save Hardware / gossip bandwidth requirements) but I was
thinking about a different solution which I want to drop in here. (I
believe yours is better though)
My thought was to use rendez-vous routing. This would mean the sender would
have to provide a rendez vous point from his local (friend of a friend?)
network and the recipient provides a route to him/herself. Only the
recipient has to know the entire network topology.
One problem with rendez vous routing is of course that the routing fails if
the route from the rendez vous point does not work. This again could be
mitigated with JIT routing.
In the context of JIT routing it also makes sense to "overpay" fees so that
JIT nodes could rebalance without loss. Making my solution also
probabilistic with the fees. The fact that this pattern of probabilistic
fees occurs for the second time now leads me to the following 2 more
general ideas (maybe we should start a new thread if we discuss them to
stay on topic here) that might help with routing.
1.) A different fee mechanism. Let us (only as a radical thought
experiment) assume we drop the privacy of the final amount in routing. A
sending node could offer a fee for successful routing. Every routing node
could decide how much fee it would collect for forwarding. Nodes could try
to collect larger fees than the min they announce but that lowers the
probably for the payment to be successful. Even more radical: Nodes would
not even have to announce min fees anymore. Turning routing and fees to a
real interactive market
2.) A virtual hierarchical address space. Maybe we should start thinking
about the creation of a semantic overlynetwork / address space for nodes
similar to IP. This would allow any node to just have a pruned network view
but still make smart routing decisions. Obviously we would have to find a
way to assign virtual network addresses to nodes which might be hard.
The second suggestion would be of particular interest in your case if N
also did not know the entire network and has to decide to whom to to
forward for the final destination D.
Sorry for "hijacking" your suggestion and throwing so many new ideas but in
my mind this seems all very connected /related.
Best Rene
Pierre <pm+lists at acinq.fr> schrieb am Do., 28. März 2019, 23:25:
> Hello List,
>
> I think we can use the upcoming "Multi-frame sphinx onion format" [1]
> to trustlessly outsource the computation of payment routes.
>
> A sends a payment to an intermediate node N, and in the onion payload,
> A provides the actual destination D of the payment and the amount. N
> then has to find a route to D and make a payment himself. Of course D
> may be yet another intermediate node, and so on. The fact that we can
> make several "trampoline hops" preserves the privacy characteristics
> that we already have.
>
> Intermediate nodes have an incentive to cooperate because they are
> part of the route and will earn fees. As a nice side effect, it also
> creates an incentive for "routing nodes" to participate in the gossip,
> which they are lacking currently.
>
> This could significantly lessen the load on (lite) sending nodes both
> on the memory/bandwidth side (they would only need to know a smallish
> neighborhood) and on the cpu side (intermediate nodes would run the
> actual route computation).
>
> As Christian pointed out, one downside is that fee computation would
> have to be pessimistic (he also came up with the name trampoline!).
>
> Cheers,
>
> Pierre-Marie
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-February/001875.html
> _______________________________________________
> 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/20190329/b604fc57/attachment.html>;