100 sats \ 3 replies \ @fanis 18 Jan \ on: Scaling LN routing with Chaumian eCash lightning
Interesting idea. I'll add we could preserve the atomicity of the route by adding another spending condition to the ecash that C sends to E, that is revealing the preimage.
What's nice is the rest of the route doesn't need to care about the fact that the payment goes through an ecash custodial mint. The risk is taken by E when it accepts to forward the payment in exchange of ecash tokens (a bit like a hosted channel can be used to route payments.
However, a major pain point is that if there is no channel between C and D (or C and E), the sender is unlikely to pick a route that goes A -> B -> C -> (ECASH FEDERATION) -> E -> D. So in the current state of Lightning this would only work if the ecash part happens at the end of the route (A -> B -> C -> (ECASH FEDERATION) -> D, so that the recipient (D) can add a routing hint in the invoice telling the sender (A) that there is indeed a path from C to D. But then, that's not really routing, but just using a Lightning Gateway (C) inside a chaumian mint.
Nice! Atomicity was one of the first additions I wanted to look in to.
I was also thinking about that pain point, it would likely require an upgraded routing method in order to use one or multiple federations along the route.
Couple of really interesting parts that I’m going to continue looking in to. I’m going to get a Fedimint up and running this evening to play around with.
Really appreciate your input!
reply
I was also thinking about that pain point, it would likely require an upgraded routing method in order to use one or multiple federations along the route.
What's interesting is the twi proposed alternative routing mechanisms that I know of would solve this pain point:
- trampoline routing by having C be a trampoline node,
- ant routing, since every node responds based on their knowledge of their surroundings.