Repository navigation
Multi-LSP support #529
Description
Activity
I can see this has been implemented here:
Line 1031 in ddd1768
One thing to think about -- to my knowledge, in any instance where multiple LSP offers are actually being used currently on the Lightning Network -- for example, Amboss Magma, or Alby Hub -- if a user were to always choose the "cheapest" liquidity offer, that user would end up with a channel with a LSP that exhibits one or all of the following characteristics:
- The LSP would lack inbound liquidity and would often fail payments
- The LSP would have intermittent connectivity to the internet, so payments would often fail (A major seller on Amboss Magma actually just went down due to a power outage for several days last week.)
- The LSP would practice aggressive "liquidity reuse", whereby the LSP would often rebalance "outbound heavy" channels, turning them into "inbound heavy", in order to re-use the outbound liquidity for other LSP channel sales
All to say: I'm not sure that "automatically choose the cheapest LSP" will be a great user experience, in practice.
I can see this has been implemented here:
No, the line you're citing is referring to choosing one offer from the multiple the (single) configured LSP might provide. Issues like the one described is why we didn't go for the multi-LSP setting from the start, but rather left the choice of (single) LSP to the user.
Ah, I see, the cheapest offer from the SINGLE configured LSP. Got it.
Currently, we only allow to set a single LSP for each protocol (i.e., bLIP-51/bLIP-52). We however got users requests for the ability to configure multiple LSPs at the same time.
While the technical change to do this is trivial, we'll need to figure out a good API design to allow for this. In case of bLIP-52 / LSPS2 we could actually request fee params from all LSPs in parallel and choose the cheapest one. For bLIP-51/LSPS1 it's however not quite so clear how we can handle multiple LSPs in parallel in the API.