Re: [Lightning-dev] Liquidity Ads: Updated Spec Posted, please review
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 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 > 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 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
Re: [Lightning-dev] Liquidity Ads: Updated Spec Posted, please review
> 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 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 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
Re: [Lightning-dev] Liquidity Ads: Updated Spec Posted, please review
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 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 n
