-
Notifications
You must be signed in to change notification settings - Fork 491
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Advertise liquidity ads rates #1145
Conversation
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. We can in the future modify the commitment transactions to restrict the seller: a dedicated feature bit will let us add this seamlessly if it is considered useful.
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:
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 |
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. |
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 lease liquidity for new channels or not, and how much - always honor liquidity requests on existing channels (RBF and splice) We currently don't modify commitment transactions to enforce the lease. This is different from lightning/bolts#878 and instead matches lightning/bolts#1145. We currently use the temporary tlv tag 1337 while we're waiting for feedback on our spec proposal. 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. We store every liquidity purchase (whether we're buyer or seller) in the audit DB. This is important information when choosing which peers are worth keeping channels with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept ACK
Add amount range to `lease_rate`.
- MUST set `min_lease_amount_sat` and `max_lease_amount_sat` to the minimum | ||
and maximum amount it will contribute at this rate. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this actually be enforced? I wonder if this should be "SHOULD"
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. |
Closing in favor of #1153 |
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
of0
. This provides an easy path for a more complex change, without sacrificing simplicity in the short term.