Extensible Liquidity Ads #1153

t-bast · 2024-04-15T13:58:49Z

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.

07-routing-gossip.md

t-bast · 2024-04-15T14:04:17Z

@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!

07-routing-gossip.md

Add types and codecs for the extensible liquidity ads format proposed in lightning/bolts#1153.

JssDWt

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

07-routing-gossip.md

02-peer-protocol.md

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.

02-peer-protocol.md

07-routing-gossip.md

Add types and codecs for the extensible liquidity ads format proposed in lightning/bolts#1153.

The last commit of lightning/bolts#1153 introduces a separate `payment_type` field, that allows extending the ways fees can be paid.

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

02-peer-protocol.md

07-routing-gossip.md

t-bast · 2024-05-21T09:01:36Z

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!

We previously only used liquidity ads with splicing: we now support it during the initial channel opening flow as well. This lets us add more unit tests, including tests for the case where the node receiving the `open_channel` message is responsible for paying the commitment fees. We also update liquidity ads to use the latest version of the spec from lightning/bolts#1153. This introduces more ways of paying the liquidity fees, to support on-the-fly funding without existing channel balance (not implemented in this commit). Note that we need some backwards-compatibility with the previous liquidity ads types in our state serialization code: when we're in the middle of signing a splice transaction, we may have a legacy liquidity lease in our splice status. We ignore it when finalizing the splice: the only consequence is that we won't store an entry in our DB for that lease, but the channel will otherwise work correctly.

The initiator of `open_channel2`, `tx_init_rbf` and `splice_init` can request funding from the remote node. The non-initiator node will: - let the open-channel-interceptor plugin decide whether to provide liquidity for new channels or not, and how much - always honor liquidity requests on existing channels (RBF and splice) when funding rates have been configured Liquidity ads are included in the `node_announcement` message, which lets buyers compare sellers and connect to sellers that provide rates they are comfortable with. They are also included in the `init` message which allows providing different rates to specific peers. This implements lightning/bolts#1153. We currently use the temporary tlv tag 1339 while we're waiting for feedback on the spec proposal.

We previously only used liquidity ads with splicing: we now support it during the initial channel opening flow as well. This lets us add more unit tests, including tests for the case where the node receiving the `open_channel` message is responsible for paying the commitment fees. We also update liquidity ads to use the latest version of the spec from lightning/bolts#1153. This introduces more ways of paying the liquidity fees, to support on-the-fly funding without existing channel balance (not implemented in this commit). Note that we need some backwards-compatibility with the previous liquidity ads types in our state serialization code: when we're in the middle of signing a splice transaction, we may have a legacy liquidity lease in our splice status. We ignore it when finalizing the splice: the only consequence is that we won't store an entry in our DB for that lease, but the channel will otherwise work correctly.

The initiator of `open_channel2`, `tx_init_rbf` and `splice_init` can request funding from the remote node. The non-initiator node will: - let the open-channel-interceptor plugin decide whether to provide liquidity for new channels or not, and how much - always honor liquidity requests on existing channels (RBF and splice) when funding rates have been configured Liquidity ads are included in the `node_announcement` message, which lets buyers compare sellers and connect to sellers that provide rates they are comfortable with. They are also included in the `init` message which allows providing different rates to specific peers. This implements lightning/bolts#1153. We currently use the temporary tlv tag 1339 while we're waiting for feedback on the spec proposal.

We previously only used liquidity ads with splicing: we now support it during the initial channel opening flow as well. This lets us add more unit tests, including tests for the case where the node receiving the `open_channel` message is responsible for paying the commitment fees. We also update liquidity ads to use the latest version of the spec from lightning/bolts#1153. This introduces more ways of paying the liquidity fees, to support on-the-fly funding without existing channel balance (not implemented in this commit). Note that we need some backwards-compatibility with the previous liquidity ads types in our state serialization code: when we're in the middle of signing a splice transaction, we may have a legacy liquidity lease in our splice status. We ignore it when finalizing the splice: the only consequence is that we won't store an entry in our DB for that lease, but the channel will otherwise work correctly.

07-routing-gossip.md

The initiator of `open_channel2`, `tx_init_rbf` and `splice_init` can request funding from the remote node. The non-initiator node will: - let the open-channel-interceptor plugin decide whether to provide liquidity for new channels or not, and how much - always honor liquidity requests on existing channels (RBF and splice) when funding rates have been configured Liquidity ads are included in the `node_announcement` message, which lets buyers compare sellers and connect to sellers that provide rates they are comfortable with. They are also included in the `init` message which allows providing different rates to specific peers. This implements lightning/bolts#1153. We currently use the temporary tlv tag 1339 while we're waiting for feedback on the spec proposal.

We previously only used liquidity ads with splicing: we now support it during the initial channel opening flow as well. This lets us add more unit tests, including tests for the case where the node receiving the `open_channel` message is responsible for paying the commitment fees. We also update liquidity ads to use the latest version of the spec from lightning/bolts#1153. This introduces more ways of paying the liquidity fees, to support on-the-fly funding without existing channel balance (not implemented in this commit). Note that we need some backwards-compatibility with the previous liquidity ads types in our state serialization code: when we're in the middle of signing a splice transaction, we may have a legacy liquidity lease in our splice status. We ignore it when finalizing the splice: the only consequence is that we won't store an entry in our DB for that lease, but the channel will otherwise work correctly.

t-bast · 2024-09-03T13:09:17Z

Note to reviewers: I slightly changed the format of funding rates in the last commit to include an additional fee for channel creation. As detailed in the commit message, creating a new channel doesn't have the same cost as adding liquidity to an existing channel (in terms of resources and future on-chain usage): this lets node operators collect a different fee for channel creation to hedge the cost of a future (force) close.