lightning-dev

Combined summary - Liquidity Ads and griefing subtleties

Combined summary - Liquidity Ads and griefing subtleties

Recent discussions within the developer community have highlighted a shift in optimizing strategies for managing inbound liquidity on the Lightning Network.

Developers are moving away from the use of complex mechanisms like CLTV (Check Lock Time Verify) and timelocks due to their complexity, which does not seem justified by the benefits they provide. The emerging consensus favors simpler protocols that rely on incentive structures to promote cooperation among network participants. This could involve direct payments or transaction fees paid by buyers to sellers, thus encouraging the maintenance of liquidity without the need for intricate lease agreements or timelocks.

There is a recognition that a one-size-fits-all approach does not suffice for meeting inbound liquidity needs. Instead, a more adaptive strategy is necessary to cope with fluctuating conditions such as varying on-chain fees. A flexible method has been proposed where buyers and sellers negotiate payment terms and frequency at the outset of a channel relationship, allowing for adjustments based on the changing benefit to each party. Such a model could streamline the protocol and better align the incentives of liquidity providers with user demands.

While an immediate replenishment of liquidity by sellers as it gets depleted by buyers was considered, this faces practical challenges, especially for small payments where on-chain fees might be too high. As an alternative, using routing fees and lease fees as incentives for sellers to commit to liquidity reservations has been suggested.

Complexities associated with handling multiple leases, such as managing transactions awaiting confirmation and updating commitment transactions, were also discussed. There may be a need for new communication mechanisms to ensure synchronization between nodes. Splicing into transactions presents another layer of complexity, particularly in deciding how additional amounts should be allocated and the extensive coding required to support such features.

An approach that relies on market dynamics and user behavior, rather than enforcing CLTV-based leases, was presented. This suggests that if buyers find the liquidity duration unsatisfactory, they could choose not to continue with that seller, potentially leading to a more user-centric outcome.

The concept of liquidity advertisements was reviewed, proposing a shift towards leasing specified amounts of liquidity rather than entire channel capacities. This allows sellers to reclaim any unused balance once the leased amount is utilized, granting them the flexibility to decide whether to keep channels open.

Finally, a detailed strategy for managing sellers' funds within a transactional system was outlined. It involves tracking different states of the seller's assets and precise handling of HTLCs (Hashed Time-Locked Contracts), ensuring that to_local_leased funds are prioritized during HTLC transactions and creating appropriate CLTV outputs when necessary. The management of fund ownership and channel capacity through CLTV encumbrance was discussed, offering security while maintaining accessibility to funds.

In terms of policy for handling transactions, a threshold is suggested for CLTV binding, with the first 10,000 satoshis from a seller being subject to CLTV. Amounts above this would be considered standard transactions. This ensures that outgoing HTLCs utilize non-CLTV-bound funds first, with failures replenishing CLTV outputs up to their designated cap. The potential risks associated with liquidity ads, including griefing attacks and the implications of optional CLTV enforcement for pricing and risk assumption between buyers and sellers, were also examined. Despite the complexities involved, liquidity ads are deemed crucial for the advancement of the Lightning Network, with efforts underway to integrate liquidity marketplaces into widespread use.

Discussion History

0
Bastien TEINTURIEROriginal Post
December 1, 2023 17:45 UTC
1
December 1, 2023 22:42 UTC
2
December 2, 2023 02:22 UTC
3
December 4, 2023 09:48 UTC
4
December 7, 2023 21:17 UTC
5
December 8, 2023 08:00 UTC
6
December 8, 2023 15:47 UTC
7
December 8, 2023 22:31 UTC
8
December 11, 2023 13:53 UTC
9
December 13, 2023 02:23 UTC
10
December 13, 2023 12:59 UTC
11
December 13, 2023 19:46 UTC
12
December 14, 2023 09:40 UTC