feat: splicing, peerswap, and/or liquidity ads as an alternative to channel opens/closes/swaps

[chrisguida]

would be epic

[ksedgwic]

Can you give an example of what you mean? Which current operations can we replace?

[chrisguida]

Apologies for the sparse issue.

Currently CLBOSS uses Boltz to swap in and swap out liquidity. Seems we could easily replace that with splicing in some cases. It would be great not to have to rely on a centralized swapping service for off-chain/on-chain liquidity exchange, and we could potentially save a lot on fees.

Additionally, CLBOSS can only open or close channels currently, not make them larger or smaller. It would probably be a lot more efficient to adaptively increase/decrease liquidity in channels as profitability varies, rather than simply closing the channel and opening a new one.

We could probably gather much better data this way (e.g., by tesing different pricing theories in the same channel before and after a splice, to see what the effect is on our profitability).

In addition, gossip delays mean that other nodes may still try to use old channels for a period after a channel is closed; splicing could allow them to continue using channels that are simply smaller than before rather than closed.

I suppose this is more of a discussion topic than a specific feature request, but it does seem to me like CLBOSS could benefit a lot from leveraging splicing.

[chrisguida]

Basically, splicing allows you to have much more fine-grained control on how much exposure you have to your channel partners. Right now CLBOSS is limited to sort of a "hammer" approach: opening a channel for a more-or-less arbitrary amount (some large percentage of your on-chain tank) and keeping the channel until it's deemed unprofitable, then closing it (if closes are enabled). Splicing seems like a much more elegant tool.

[ksedgwic]

Is there a way to acquire inbound liquidity w/ splicing instead of using Boltz? This would be really great, but I don't see how to do it yet ...

[chrisguida]

Hmm, good point, I guess swapping using splicing would be limited to only swapping out, unless paired with something like liquidity ads. Which, come to think of it, would also be a great thing to incorporate in CLBOSS.

Though perhaps I'm missing something?

Seems like there should be some kind of protocol where I trustlessly pay my channel counterparty on-chain for some inbound liquidity? I believe LND can do this using BOS...

[ksedgwic]

Agree about liquidity ads! Seems like a natural (and powerful) extension of CLBOSS features to both offer and acquire liquidity this way.

[chrisguida]

By the way, LND cannot do this with BOS; I was thinking of the "dual-fund" feature where you can interactively fund a channel open with another peer who also has BOS.

However, I heard from @niftynei that the above swapping process is basically an exact description of the PeerSwap protocol. Perhaps the missing piece of the puzzle.

[chrisguida]

The PeerSwap docs don't mention that splicing doesn't work for inbound liqudity. This implies that it does work for inbound??

[ZmnSCPxj]

Please note that using a remote swap service like Boltz or Loop is superior as a method of getting inbound liquidity than liquidity ads, peerswap, OR inbound liquidity marketplaces like Magma. See: https://github.com/ZmnSCPxj-jr/sidepool/blob/master/doc/00-sidepools-are-awesome.md#the-real-solution-offchain-to-onchain-swaps

TLDR: Remote swap services must first actually have inbound liquidity to sell before the swap will work with them, and the proof of having inbound liquidity is atomic to buying inbound liquidity from a remote swap service; all other methods of selling inbound liquidity DO NOT actually need to have inbound liquidity to sell to you, meaning you could potentially buy inbound liquidity from a node that itself lacks inbound liquidity and would not be able to forward to you anyway. You would be unable to know this fact until you have already paid them for the inbound liquidity, at which point they have already taken your money. There are also no good reputation systems for this, as they can always claim that the problem is with your customers specifically not having good liquidity to them, not them having a general lack of liquidity from anyone.

[niftynei]

you would be unable to know this fact until you have already paid them for the inbound liquidity

iiuc you could probe the public channel of a candidate inbound sale partner for relative balances before agreeing to a contract with them; it's not as self-contained as an atomic swap contract but it's not "unable to know" merely "more difficult to know".

[chrisguida]

@ZmnSCPxj thanks for the heads up. I've read the link you shared and I have a few questions:

1) When you select a random node R through which to buy inbound liquidity from a swap provider S, it sounds like you must build the route to do the swap making sure to include R in your route. You didn't explicitly state this, but it seems like a requirement, correct? Then the "proof" of inbound liquidity comes in the form of the outbound liquidity you send to S to buy the on-chain funds, right?

• If so, this only "proves" inbound liquidity along the actual route from A->R->S, at the moment of the swap, which is useful as long as S or R are well connected enough to be able to route payments from your customers. It sounds like you're assuming S is well connected since it's a centralized swap service?
• Also, can't any inbound liquidity "proved" by performing such a swap be pretty much immediately negated by payments flowing the opposite direction along the route, but not to your node (A)? In this case isn't the "proof" of inbound liquidity not worth much?
  2) It seems like your argument as to why centralized providers are superior to your direct peers (as in peerswap) or random other nodes (as in liquidity ads) hinges upon the assumption that swap providers must have plenty of inbound liquidity otherwise they wouldn't be able to conduct business. This seems like a fairly reasonable assumption, but I'm wondering if simply connecting to any large LN sink would have the same guarantees, and whether there wouldn't be ways of probing your candidate peers for inbound liquidity (as @niftynei notes) before committing to buying inbound liquidity.

Thanks again for your insight here; let me know if I'm missing anything :)