Good morning list,
I've been thinking a lot about liquidity ads recently, and I want to
highlight some subtleties that should be taken into account in the
protocol design. This is a rather long post, but I believe this is
important to make sure we get it right and strike the right balance
between protocol complexity and incentives design. Strap in, grab a
coffee, and enjoy the ride.
First of all, it's important to understand exactly what you are buying
when paying for a liquidity ad. There are two dimensions here: an amount
and a duration. If Alice buys 100 000 sats of inbound liquidity from Bob
for one month, what exactly does that mean? Obviously, it means that Bob
will immediately add 100 000 sats (or more) to his side of the channel,
and Alice will pay a fee proportional to that amount *and* that duration
(because locking funds for one month should cost more than locking funds
for one day). But is that really the only thing that Alice is buying?
The current spec proposal adds a CLTV of one month to the seller's
output in the commitment transactions. Without that CLTV, the seller
could accept the trade, and immediately close the channel to reuse the
funds elsewhere. This CLTV protects the buyer from malicious sellers.
But it is actually doing a lot more: what Alice has bought is actually
*any* liquidity that ends up on Bob's side, for a whole month. And the
issue is that this is impossible for Bob to price correctly, and can be
used for liquidity griefing attacks against him.
Imagine that Alice opens a 1 BTC channel with Bob and asks him to add
10 000 sats of inbound liquidity for a month. This sounds interesting
for Bob, because Alice is bringing a lot of funds in, so he can expect
payments to flow towards him which will bring him routing fees. And she
isn't asking for a lot of liquidity, so Bob can definitely spare that.
But then Alice sends all the channels funds through Bob to Carol. This
means that Bob now has 1 BTC locked for the whole month, while Alice
only paid for 10 000 sats! He earned some routing fees, but that isn't
enough to make up for the long duration of the lock. If payments keep
flowing in both directions with enough velocity, this is great for both
Bob and Alice. But if the channel is then unused, or Alice just goes
offline, this was a very bad investment for Bob. With splicing, Bob
cannot even know beforehand how much liquidity is potentially at risk,
because Alice may splice funds in after paying for the liquidity ad.
If Alice pays for a 10 000 sats lease, we only want those 10 000 sats
to be encumbered with a CLTV. But this is actually not enforceable. We
could create a separate output in the commitment transaction with the
leased funds and a CLTV, while keeping the rest of the seller's funds in
a normal output that doesn't have a CLTV. But then what happens when
HTLCs are relayed and then failed? To which output should we add the
funds back? Any strategy we use here can be exploited either by the
seller to drain the leased funds back to its non-CLTV-locked output,
or by the buyer to keep funds in the CLTV-locked output forever.
Adding a CLTV thus protects the buyer at the expense of the seller. In
some cases this is ok: if you are a new seller who wants to attract
buyers, you may be willing to take that risk. But in most cases, the
seller is going to be more reputable than the buyer, and has more
incentives to behave correctly than the buyer. When buying liquidity,
you will likely look at the network's topology, and buy from nodes that
are well-connected, or known to be reliable. Or if you are a mobile
wallet user, you'll be buying from your LSPs, who have incentives to
behave honestly to earn fees and attract new users. In those scenarios,
the buyers will very often be new nodes, without any public channels,
which means that the seller has no way of knowing what their incentives
are beforehand. It thus makes more sense to protect the seller than to
protect the buyer. For those use-cases, the simplest solution is to not
add a CLTV at all: the buyer is taking the risk that the seller removes
the liquidity before the end of the lease. But if that happens, they'll
just mourn their lost fees, blacklist that node, and move on. There will
be a lot more buyers than sellers in that market, so I believe that this
model makes sense for most large public nodes.
I think that both use-cases should be supported, so I suggest making the
CLTV enforcement of the lease optional. It will be up to each seller to
decide whether they are willing to take the risk of locking their funds
to attract buyers or not. Sellers can (should) price that additional
risk in their advertised rates.
In the case where the CLTV is enforced, splicing brings in additional
subtleties. We should prevent the seller from making any splice-out,
otherwise they would effectively be bypassing the lease CLTV. But we
should allow the seller to splice-in, and the buyer should still be
allowed to splice-in and splice-out.
