Hey Lisa, Thanks for the update! I believe that moving to CLTV instead of CSV is definitely the right move here.
Regarding the newly added 2nd-stage lease locked transactions, I don't think that works. The issue is that you don't have an opportunity to receive signatures for those transactions with the current message flow. When you send `commit_sig`, the remote node will have a new commitment transaction that they can immediately broadcast, but you won't have their signatures if you need to claim your leased HTLC outputs. PTLCs have the same kind of issue, and we resolved them by adding new messages to the protocol flow, which I think would be overkill here. It could work if that 2nd-stage transaction did not require a signature from the remote peer, or if we could directly express the additional CLTV constraint in the output without requiring a 2nd-stage transaction at all. But I'm not sure this can be done... My other main feedback is about RBF. It currently isn't specified what behavior RBF attempts should have: should they honor the previous rates or not? I believe we should add the new funding tlv fields to the RBF messages (`tx_init_rbf` and `tx_ack_rbf`). Each RBF attempt renegotiates a potential liquidity purchase, independently of what the previous attempts contained. That will work better with splicing, where an RBF attempt may result in a very different liquidity allocation than the other pending splice transactions. I detailed that a bit more in my comment on the spec PR [1]. I'm actively working on implementing this in eclair, as I believe this is a very important feature for the network. Thanks again for pushing this spec forward! Cheers, Bastien [1] https://github.com/lightning/bolts/pull/878#issuecomment-1814006160 Le lun. 20 nov. 2023 à 20:05, niftynei <nifty...@gmail.com> a écrit : > 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 >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
