You are likely right about Phoenix, it's true I haven't looked into that implementation.

"If the LSP knows the destination node, it knows the destination." Yes, but in the case of all the standards compliant LSPs, we DON'T know the destination. We only know the hop before the LSP and the hop after the LSP. Only the sender knows the actually destination.

"the LSP effectively controls the path because the graph information is fed by the LSP". This is an extreme edge case of a malicious LSP, and to pull this off at scale would be extremely complicated.... and also, the LSP could easily get caught by a savvy Lightning engineer who was troubleshooting payment problems.

Reply to this note

Please Login to reply.

Discussion

So we agree. Effectively the biggest LSP, Phoenix, does know the destination and dies trampoline payments and implementations like LDK use an external graph sync mechanism because regular graph sync doesn't work with mobile clients. There are always trade-offs.

There are some trade-offs, but comparing the tradeoffs you list above -- graph sync & trampoline payments issues-- to the tradeoffs of allowing LightSpark to track the IP address, balances, and transaction details of all of your users -- I don'r think you can honestly put those in the same "ballpark" (as we say in the USA.)

But that's exactly what it is. An LSP can track balances, IPs, transaction details as well. We should be honest about it.