[Lightning-dev] "Trustless" Pathfinding Service

ZmnSCPxj ZmnSCPxj at protonmail.com
Fri Nov 9 12:02:21 UTC 2018


Good morning list, especially, Takaya Imai and the other representatives from Nayuta,

I was asked directly by Nayuta representatives, about "trustless" pathfinding service.  While I gave an idea that was satisfactory initially, when I consider again, it is actually very bad.

The scenario is the below:

1.  A paying Lightning node is a "light" client that is so light, it cannot keep a complete routemap.
2.  There exists a service that can contain the complete routemap.
3.  The paying Lightning node does not want the service to know the payer and payee.

The solution I gave before was below:

1.  The paying Lightning node provides several nodes in an ordered list.  It includes itself and the destination in that list.  The only constraint is that the payer must precede the payee, but, they may be anywhere on the list as long as they are not more than 10 nodes or so from each other in this long list.
2.  The routing service creates a single very long (potentially >20 hops) route, which passes through all nodes in the specified order.
3.  In order to get paid, the routing service maintains one or more Lightning nodes with higher than typical fees.  It biases pathfinding towards those nodes.
4.  The paying Lightning node receives the very long route, and cuts it from paying node, to the destination.  If this subsection of the route is < 20 hops, it can be used to attempt the payment.
5.  The routing service cannot be sure precisely, who is payer and payee.
6.  The routing service is incentivized to behave properly (i.e. give valid route). If it gives valid route, there is possibility that its nodes happen to be on the route from payer to payee and possibly earn fees.  If it gives invalid route, it earns no fees.

However, issues are below:

1. If the routing fails, or the subsection from payer to payee is too long, how can we re-query the same routing service safely, without leaking what the source and destination truly have?  This seems to be similar to the Bloom Filter issue for SPV bitcoin nodes (I believe, Imai-san also mentioned this...)
2. How does the Lightning node learn of other nodes it can use to increase its anonymity set?  If it keeps some node ids, then how is that so different, from saving more of the routemap (potentially, node IDs stored without channel information take only 33 bytes; but channel objects and pointers between node objects and channel objects could be quite small also).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/3f50fb89/attachment.html>


More information about the Lightning-dev mailing list