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
Re: [Lightning-dev] Lightning Address in a Bolt 12 world
Hi Andy, > Also, we might want to make it explicit in the spec that you can't > have duplicate records? Many DNS records allow multiple for > redundancy. Is that desired here? Agreed, this should be made explicit in the bLIP. I don't see a reason to allow duplicate records, so we should require uniqueness. > Is there any problem allowing a different user to have a different > blinded path? This not only helps with scalability, but say someone > want's to have a domain that is shared by say 5 users, but all those > users want to run their own node. I'm not sure which option you're commenting on here. In option 1, you can't have different blinded paths per user, since you have a single DNS record that just points to the domain owner's node. In option 3, there is already one record per user, and the user chose the blinded path themselves. If the end user (payment recipient) wants to handle this with their own node and control the blinded path, I think they'll need to have their own domain and use option 3. I may be misunderstanding your point though, let me know if that seems to be the case. Thanks, Bastien Le lun. 20 nov. 2023 à 17:32, Matt Corallo a écrit : > > > On 11/20/23 6:53 AM, Andy Schroder wrote: > >> > >>> - I would omit suggesting to use DoH from the spec. DoH seems a bit > centralized to me and that's > >>> up to the client to decide what to do. DNS itself is a hierarchically > distributed system, so > >>> there is redundancy built into it (which has its flaw at the root > nameserver / ICANN level) and > >>> it seems to me like DoH is taking much of that distributed design > away. It seems like if you are > >>> concerned about your ISP snooping your traffic, you should use a > tunnel so that your traffic is > >>> obfuscated that way, that way things are done at the IP level and not > way up at the HTTPS level. > >>> Are you resorting to DoH because many ISP block traffic for DNSSEC > records traffic through their > >>> networks? Either way, how you query DNS seems like that should be left > up to the client and not > >>> really part of the spec. > >> > >> It is, but its worth mentioning in large part because almost certainly > ~all implementations will > >> use it. While I agree that it'd be very nice to not use it, in order to > do so clients would need > >> to (a) actually be able to query TXT records, which isn't in standard > operating system libraries, > >> so would probably mean DoH to 127.0.0.53 or so, (b) trust the > resolver's DNSSEC validation, which > >> means having some confidence its local, and not a coffee shop/etc. > >> > >> Given the level of trust you have to have here in the DNS resolution, > its almost certainly best to > >> cross-validate with at least multiple DoH services, unless you are > validating the DNSSEC chain > >> yourself (which I'd really strongly prefer as the best solution here, > but I'm unaware of any open > >> source code to do so). > > > > delv, part of bind9, does recursive DNSSEC validation locally: > > https://manpages.ubuntu.com/manpages/jammy/en/man1/delv.1.html > > Sadly this doesn't really solve the issue. Lightning nodes need to be able > to get a DNSSEC tree in a > cross-platform way (which "just call delv" is not) ideally without relying > on sending UDP directly > at all. What this really means is that we'll eventually want to use the > RFC 9102 CHAIN serialization > format and put that in the node_announcement, but to do that we need some > kind of (cross-platform > library) client software which can take a serialized CHAIN and validate > it. I'm unaware of any such > software, though in theory it shouldn't be that hard to write. > > Matt > ___ > 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
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
Re: [Lightning-dev] [bitcoin-dev] HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants)
Hi Johan, Few comments. ## Transaction recycling The transaction recycling attack is made possible by the change made to HTLC second level transactions for the anchor channel type[8]; making it possible to add fees to the transaction by adding inputs without violating the signature. For the legacy channel type this attack was not possible, as all fees were taken from the HTLC outputs themselves, and had to be agreed upon by channel counterparties during signing (of course this has its own problems, which is why we wanted to change it). The attack works on legacy channels if the holder (or local) commitment transaction confirms first, the second-stage HTLC claim transaction is fully malleable by the counterparty. See https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs (only remote_htlcpubkey required) Note a replacement cycling attack works in a future package-relay world too. See test: https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf > The idea of HTLC output aggregation is to collapse all HTLC outputs on > the commitment to a single one. This has many benefits (that I’ll get > to), one of them being the possibility to let the spender claim the > portion of the output that they’re right to, deciding how much should > go to fees. Note that this requires a covenant to be possible. Another advantage of HTLC output aggregation is the reduction of fee-bumping reserves requirements on channel counterparties, as second-stage HTLC transactions have common fields (nVersion, nLocktime, ...) *could* be shared. > ## A single HTLC output > Today, every forwarded HTLC results in an output that needs to be > manifested on the commitment transaction in order to claw back money > in case of an uncooperative channel counterparty. This puts a limit on > the number of active HTLCs (in order for the commitment transaction to > not become too large) which makes it possible to jam the channel with > small amounts of capital [1]. It also turns out that having this limit > be large makes it expensive and complicated to sweep the outputs > efficiently [2]. > Instead of having new HTLC outputs manifest for each active > forwarding, with covenants on the base layer one could create a single > aggregated output on the commitment. The output amount being the sum > of the active HTLCs (offered and received), alternatively one output > for received and one for offered. When spending this output, you would > only be entitled to the fraction of the amount corresponding to the > HTLCs you know the preimage for (received), or that has timed out > (offered). > ## Impacts to transaction recycling > Depending on the capabilities of the covenant available (e.g. > restricting the number of inputs to the transaction) the transaction > spending the aggregated HTLC output can be made self sustained: the > spender will be able to claim what is theirs (preimage or timeout) and > send it to whatever output they want, or to fees. The remainder will > go back into a covenant restricted output with the leftover HTLCs. > Note that this most likely requires Eltoo in order to not enable fee > siphoning[7]. I think one of the weaknesses of this approach is the level of malleability still left to the counterparty, where one might burn in miners fees all the HTLC accumulated value promised to the counterparty, and for which the preimages have been revealed off-chain. I wonder if a more safe approach, eliminating a lot of competing interests style of mempool games, wouldn't be to segregate HTLC claims in two separate outputs, with full replication of the HTLC lockscripts in both outputs, and let a covenant accepts or rejects aggregated claims with satisfying witness and chain state condition for time lock. > ## Impacts to slot jamming > With the aggregated output being a reality, it changes the nature of > “slot jamming” [1] significantly. While channel capacity must still be > reserved for in-flight HTLCs, one no longer needs to allocate a > commitment output for each up to some hardcoded limit. > In today’s protocol this limit is 483, and I believe most > implementations default to an even lower limit. This leads to channel > jamming being quite inexpensive, as one can quickly fill a channel > with small HTLCs, without needing a significant amount of capital to > do so. > The origins of the 483 slot limits is the worst case commitment size > before getting into unstandard territory [3]. With an aggregated > output this would no longer be the case, as adding HTLCs would no > longer affect commitment size. Instead, the full on-chain footprint of > an HTLC would be deferred until claim time. > Does this mean one could lift, or even remove the limit for number of > active HTLCs? Unfortunately, the obvious approach doesn’t seem to get > rid of the problem entirely, but mitigates it quite a bit. Yes, protocol limit of 483 is a long-term limit on the payment throughput of the LN,
