Extensible Liquidity Ads

[t-bast]

Add the ability to advertise rates at which nodes wish to sell their liquidity. Buyers can then connect to sellers and request liquidity, at one of the advertised rates.

This can be used when creating a dual-funded channel, where both participants contribute to the funding transaction, and one of them is paid for (some of) their contribution. This can also be used to splice additional liquidity into existing channels, when splicing is supported.

We introduce an extensible payment_type field to control how the funding fees are paid. The only payment_type currently defined pays funding fees from the buyer's channel balance during the interactive-tx session, but it is easy to introduce different payment_types (to pay the fees using HTLCs for example).

LSPs may for example want to offer funding where fees are not paid immediately when creating the transaction, but instead taken from every future HTLC relayed on that channel (see lightning/blips#36). We create the ability for bLIPs to introduce new payment types, without affecting the BOLTs.

We don't add any constraints to the commitment transactions. Sellers should keep the channel open for at least a month, but there is no way to guarantee that. The seller could immediately close the channel, or splice funds out. It is up to the buyer to then blacklist that seller.

This PR is a concurrent design for #1145.

Credits to @niftynei for the original design.

[t-bast]

@TheBlueMatt I believe this kind of design leaves enough room for introducing different types of leases and fee mechanisms, and would make it easy to support all LSP use-cases. It also makes it easy for bLIPs to introduce lease types, that would keep using most of the liquidity ads mechanisms. Let me know what you think!

[JssDWt]

From the first look this looks like a good extensible model for channel leases. I didn't find any obvious gaps.

[tnull]

Did a first pass, found just a few nits and questions so far.

I also like the extensible model, but have yet to spend more time thinking about the details regarding how this would work in a JIT flow exactly.

[niftynei]

While this is a considerable evolution of the original proposal, I think it's fair to ask that that I get at least a by-line credit the commit description for this. For example something like

Credit to: @niftynei for the original liquidity ads proposal

[t-bast]

While this is a considerable evolution of the original proposal, I think it's fair to ask that that I get at least a by-line credit the commit description for this. For example something like

Of course, I'd like to re-arrange the commits once reviewed (the first commit is only here to help guide the review and shouldn't be included on master IMO), once we get closer to a final version I'll clean-up the commits and add credits!

[t-bast]

@niftynei I updated the TLV fields in 910c070 to prevent conflicts with existing versions of cln.

[remyers]

If PR 1236 is merged, and either side can send tx_init_rbf then this line will need some clarification.

Only the initiator of the previous transaction should set request_funding for tx_init_rbf. The non-initiator must only set funding_output_contribution (as mentioned above) if they will provide an output contribution.

Same for the "The recipient" section below; request_funding is only expected by the non-initiator, but funding_output_contribution should be equal to or greater than the previous transaction that included a request_funding.

Note: this should also apply when the previous transaction is a splice.

[t-bast]

Indeed, that was discussed during spec meetings for #1236: when someone is purchasing liquidity from you, you shouldn't be the one initiating an RBF, because you would then lose this purchase. I'll update the PR to clarify that after splicing and #1236 are added to the BOLTs.