Oddbean new post about | logout
 I'm working on a new pay plugin called xpay (working title). It's designed to use the new (very WIP) askrene plugin, which provides routes. Actually, most of the work is there, fixing and enhancing that. Especially diagnosis: *why* did it give a weird/no route? Common issues are: there's a good channel but it's offline, or doesn't have capacity, or you don't have enough capacity at all, or the recipient doesn't. We've had issues where gossip is missing, too: detecting when that happens is an open research question, but we'll start probing more aggressively.

There have been many complaints about pay in the wild, and the code has grown quite complex. I've heard good things about Boltz's mpay, which is far simpler, so I'm inspired to go in that direction. Moving the routing (which *is* complex!) out is the first step. 

To be honest, I should have taken a direct interest in this earlier. I considered pay a simple problem, or at least not one I needed to concern myself with. But better late than never! 
 Hey Rusty, let's chat! We've been working on improved pathfinding at Amboss with an objective to reduce probes and reliance on probes to predict better routes.
Pathfinding at the node level is a good thing to optimize, but it will be inferior to more collaborative/centralized pathfinding simply because it has more data to play with.

We're ready with an endpoint for pathfinding and are benchmarking it against LND in different parts of the network to evaluate our predictions. 
 So, askrene (the routing oracle plugin) has support for layers, each containing information about channels (also, can add/remove channels and nodes, but that's mainly for special-effects for particular payments).

It would not be hard to import/export entire layers: I've speculated that LSPs or large players may want to issue "weather reports" which could be incorporated this way. There are two issues: 

1. Needs a standard format. This is easy, let's come up with something?
2. Privacy of those contributing to the data. This is hard, I don't know how to fuzz/exclude/delay data to avoid revealing the individual payments, but someone surely does? 

This is absolutely a service you could charge for, too. Perhaps a free version with very rough data, and a tier with more complete data? 
 
 It sounds like you're thinking that end devices will do the route calculations. There might be an opportunity here since we can predict all channel states (poorly) using our ML, which is better than the probabilistic pathfinding method from Rene Pickhardt (only since the ML is based off more data). Certainly we can offer the simple graph without predictions as a low cost (or potentially free) option.

We'll start with a generic pathfinding as a service which will accept inputs source, destination, amount.
These can be populated with an invoice directly or can be fuzzed with different amounts for privacy.

We'll be sending out invitations to benchmark test our service against LND's a priori pathfinding in exchange for free use of the advanced service that incorporates our predictions.

If you (or anyone) are keen to help test the PaaS, anyone can sign up at rpo.dev/pathfinding.
 https://rpo.dev/pathfinding