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+li...@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@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
