bolts
bolts copied to clipboard
lightning
Advertise liquidity ads rates
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 don't add any constraints to the commitment transaction. The lease duration isn't protected by script opcodes, which means that the seller could immediately close the channel, or splice funds out. It is up to the buyer to then blacklist that seller.
This is a subset of #878 and mostly matches what @niftynei proposed there, with some changes that were discussed during the review process and over threads on the mailing list (such as https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004227.html). The goal of this PR is to be a first step that can be integrated before #878 and allows nodes to buy/sell liquidity without restrictions on the seller side, relying on incentives rather than scripts inside the commitment transactions. This will let us observe what behaviors emerge and the market dynamics. If we feel that adding restrictions on the seller side by modifying the commitment transactions can be useful (as proposed in #878), we can easily add it on top of this change using a dedicated feature bit. It would still allow unrestricted liquidity leases, by simply using a lease_duration of 0. This provides an easy path for a more complex change, without sacrificing simplicity in the short term.
Is the goal here to get this in production while the details of #878 are still being ironed out? Is the intent to eventually replace #878? Trying to figure out what lense to review this with.
Is the goal here to get this in production while the details of https://github.com/lightning/bolts/pull/878 are still being ironed out? Is the intent to eventually replace https://github.com/lightning/bolts/pull/878? Trying to figure out what lense to review this with.
That probably wasn't clear enough with the initial PR description, sorry! I've updated the description with more details, let me know if that's better.
Ok yeah, let's get this shipped!
From a "building trustless protocols" perspective, I'm still holding onto hope that we can figure out an effective and useful way to enable optional commitments to lease enforcement, but I like the idea of moving forward with making this more widely available.
The biggest downside to shipping without a lease enforcement is that it skews the market in favor of a nodes with reputation; it may also retard adoption from buyers who are concerned about service fulfillment. A single bad actor could cause a market chill by behaving in a selfish manner, thereby making buyers less willing to participate in the protocol to buy inbound liquidity due to fear of being scalped/not having their channel liquidity lease term honored.
But given that:
- our current best lease enforcement protocol designs are widely agreed to be imperfect at best, and
- since this is an economic protocol, to some extent the downside risk can be 'priced' by buyers
I'm ok with moving forward with the just the lease negotiation protocol portion of the proposal, especially given that we may discover new information post launch that helps refine further versions.
I'm ok with moving forward with the just the lease negotiation protocol portion of the proposal, especially given that we may discover new information post launch that helps refine further versions.
Awesome! Do you plan on updating cln to match this proposal to allow for cross-compatibility tests? This way once we have cross-compat on the format between eclair and cln, and a concept ACK from @ProofOfKeags for the lnd folks (and hopefully a concept ACK as well from LDK), we can get that PR merged and start observing what happens on mainnet :rocket:
The lease duration isn't protected by script opcodes, which means that the seller could immediately close the channel, or splice funds out. It is up to the buyer to then blacklist that seller.
The burden here is really on the application developers to track the channel lease terms and alert the users for channel closures which do not respect the lease terms. Each app developer would need to come up with some sort of a reputation tracking mechanism to keep the users informed of the quality of liquidity providers.
After discussing using liquidity ads with the LSP specifications working group, I got some feedback that it would be useful to have more flexibility on how the fee is paid, and what constraints apply to the liquidity lease. That lead me to a different design, that allows extending liquidity ads with more lease types in #1153
I think #1153 is more versatile than this version, while also allowing the features offered by this version. I'm interested in reviewers feedback on those two different designs.