Skip to content
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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

t-bast
Copy link
Collaborator

@t-bast t-bast commented Mar 5, 2024

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.

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.
@ProofOfKeags
Copy link
Contributor

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.

@t-bast
Copy link
Collaborator Author

t-bast commented Mar 8, 2024

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.

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.

@niftynei
Copy link
Collaborator

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.

@t-bast
Copy link
Collaborator Author

t-bast commented Mar 12, 2024

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 🚀

@saubyk
Copy link

saubyk commented Mar 12, 2024

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.

t-bast added a commit to ACINQ/eclair that referenced this pull request Mar 29, 2024
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.
Copy link
Contributor

@ProofOfKeags ProofOfKeags left a 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`.
Comment on lines +365 to +366
- MUST set `min_lease_amount_sat` and `max_lease_amount_sat` to the minimum
and maximum amount it will contribute at this rate.
Copy link
Contributor

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"

@t-bast
Copy link
Collaborator Author

t-bast commented Apr 15, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants