Hi all. The original Liquidity Ads spec draft[1] was posted a few years ago and implemented and shipped in core-lightning's v0.10.1 (Aug 2021).
We received some great comments and feedback on the initial design, and I've since updated the spec to incorporate some of these changes. Big thanks to everyone that's already spent time reviewing it. The updated proposal hasn't been implemented in CLN yet, however I wanted to solicit some early feedback, particularly around the usage of CLTV and the introduction of a new 'second stage' transaction to help gate the leasor's funds for the duration of the lease. You can find the draft here: https://github.com/lightning/bolts/pull/878 Here's an overview of notable changes. ### CSV to CLTV The original proposal used a constantly updated blockheight to lock up funds of the leasor with a CSV. We reused the CSV lock that was introduced by anchor outputs to add this. This created a dependency on anchor outputs, as well as added complexity around commitment transaction updates. It required constant updates to decrement the CSV lock as time went on. The HTLC outputs of the leasor in the remote's (leasee's) commitment transaction weren't encumbered with a timelock. This means that if the leasor convinced their peer into force closing the channel, any funds in inflight HTLCs would be available to them prior to the end of the agreed upon lease period. This new proposal switches from CSV to CLTV, and adds a CLTV lock on every output which goes to the leasor. For the above case of HTLCs in the leasee's commitment transaction, we can't add an additional CLTV directly to the script, as this would impact the timeout calculation for every payment routed through a leased channel. Instead, we introduce the concept of a "lease locked" transaction. These are almost identical to HTLC transactions, with the exception that they only exist on the commitment transaction where the leasor is remote. This change is more complex in terms of onchain handling, but it closes all possible avenues for the leasor gaining access to their funds onchain ahead of the lease end. Credit to @morehouse for identifying this and the proposed fix. For a more in-depth exploration of this change, please see the relevant proposed commit. [2] ### Variable Lease Terms Another change we've made is allowed for the lease length to be specified by the node asking for the lease. Previously, all leases were fixed at about a month, or 4032 blocks. This allows for a more dynamic pricing mechanism on the seller's side, as they can tailor the rates that they return back in `accept_tlv.lease_rates` to account for the desired lease length of the opener. (Generally, I'd anticipate longer leases would command a higher price). The channel fee cap commitments have been updated to specify a range of blocks for which the commitment is valid. ### Channel Fee Caps The channel fee caps were originally specified to be in increments of 1k ppm in the liquidity advertisement in the node_announcement. We received feedback that this was too coarse of a range. It's been updated to be 100's of ppm (which maps cleanly to bips). The current draft also proposes fixing the base msat cap at 500sats; @t-bast has already proposed that we revert this to a variable fee. The spec should be updated shortly. I think that's the majority of the proposed changes, but highly recommend you check out the proposal. (Start at the 2nd to last commit, if this is prior to dual-funding PR getting merged). ## Fraud Proofs + Slashing (Channel Fee Commitments) It was pointed out by some members of the CLN hack week team that the current proposal includes what is essentially a fraud proof. In the case that the leasor commits to channel fee caps of say 100ppm and 0 base msat; and then within the blockrange publishes a signed channel_update which sets their channel fees for that channel to 1000ppm, the leasee is essentially now in possession of a fraud proof. Ideally we'd be able to include a bond or some other mechanism to punish an offending node, however it seems that ranges of values are extremely difficult to make cryptographic commitments about. If anyone has any suggestions or ideas about how to use these two signed commitments to effectuate a bond release via script, please get in touch. I think that's everything! Thanks to the CLN hack week participants for their early review and opinions on the protocol (Michael Evans, Tony, @ddustin, @farscapian, Ken Sedgwick, @chrisguida); @t-bast for his fast review + new suggestions; Jesse Schrader of AMBOSS for his insights into node fee behavior. ~nifty [1] https://github.com/lightning/bolts/pull/878 [2] https://github.com/lightning/bolts/pull/878/commits/b93f5b882cfca76b84750ae9d5f2de68f76f6ba4
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
