Hey Lisa, > One drawback is that it adds another reason an RBF attempt > might be rejected.
That's true, but not including it is also a reason for an RBF attempt to be rejected! If the seller changed their mind (because the tx took too much time to confirm and they want to allocate their liquidity elsewhere), they're incentivized to reject the RBF attempt and wait for an opportunity to double-spend. Whereas now they have an opportunity to ask for higher rates or to remove liquidity from this new funding tx. > - leave the hole, tell lessors to restrict their HTLC inflight value I'd favor that option as well. I don't think we can fully solve the issue of a liquidity seller not playing honestly. They could simply refuse to relay HTLCs, and you couldn't catch them doing so. Restricting exposure and good incentives to behave correctly are most likely better than over-engineering a complex protocol that cannot fix every hole anyway! Cheers, Bastien Le mar. 21 nov. 2023 à 19:09, niftynei <nifty...@gmail.com> a écrit : > > Each RBF attempt renegotiates a potential liquidity purchase, > independently of what the previous attempts contained. > > You're right, I'm missing the RBF spec! Thanks for the reminder. > > I think having the lease renegotiated makes sense, it gives > maximum flexibility and allows the API for an open/splice/rbf > to all be equivalent. > > One drawback is that it adds another reason an RBF attempt > might be rejected. > > > 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... > > Ah I think unfortunately you're right about this. Needing a peer sig > for *their* commitment tx isn't something we can do with the current > protocol. Drats. > > That leaves a few options, I think > > - leave the hole, tell lessors to restrict their HTLC inflight value > - extend any payment htlc through the channel by the lease length > - rearchitect the commitment flow > > > From a time management perspective, option 1 is the most expedient. > > We can always rearchitect the commitment flow to remove this hole in > the future, perhaps along with another upgrade that simplifies or needs > the same thing? (syncrhonous commitment flow; PTLCs; eltoo?) > > ~nifty > > > On Tue, Nov 21, 2023 at 4:33 AM Bastien TEINTURIER <bast...@acinq.fr> > wrote: > >> 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
