Re: [bitcoin-dev] HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants)
> Bob can craft a HTLC-preimage spend of the single offered output spending one > of 0.1 BTC HTLC payout (and revealing its preimage) while burning all the > value as fee. This replaces out Alice's honest HTLC-timeout out of network > mempools, are they're concurrent spend. Bob can repeat this trick as long as > there is HTLC "payout" remaining in the offered set, until he's being able to > do a HTLC off-chain double-spend of the 1 BTC HTLC "payout". What do you mean by "do a HTLC off-chain double-spend of the 1 BTC HTLC"? Agreed on every detail up to this point. Note that every time Bob replaces Alice's timeout tx, he reveals a preimage that Alice can use to settle her incoming HTLC, so for those Alice loses nothing, Bob loses the HTLC value to fees. I believe for Bob to be able to profit from this, he would need to delay all of Alice's transactions until the timelock on Alice's incoming HTLC expires (CLTV delta blocks). Is this what you mean by "off-chain double spend"? Anyways, this means that Bob will have to pay ~next block fees each block in the delta period (assuming Alice is eager to get into the block since the timelocks are expiring on her incoming HTLCs), and burn the value of an HTLC for every such transaction. However, I think it is possible to make this very risky for Bob to play out, based on a simple fact: Alice can claim all the expired HTLCs cheaply (1 input 1 output tx, no merkle paths or preimages needed), and she is game theoretically willing to burn almost all of it to fees to get it confirmed before expiry. So for the last 1 BTC HTLC, she could pay ~0.9 BTC to fees, which Bob couldn't compete with by burning the much smaller HTLCs. However, Bob could of course grief Alice by making her do this, but unsure if that's rational. On Sun, Dec 17, 2023 at 11:56 PM Antoine Riard wrote: > > Hi Johan, > > > Is this a concern though, if we assume there's no revoked state that > > can be broadcast (Eltoo)? Could you share an example of how this would > > be played out by an attacker? > > Sure, let's assume no revoked state can be broadcast (Eltoo). > > My understanding of the new covenant mechanism is the aggregation or > collapsing of all HTLC outputs in one or at least 2 outputs (offered / > received). > Any spend of an aggregated HTLC "payout" should satisfy the script locking > condition by presenting a preimage and a signature. > An offerd aggregated HTLC output might collapse a M number of HTLC "payout", > where M is still limited by the max standard transaction relay, among other > things. > > The offered-to counterparty can claim any subset N of the aggregation M by > presenting the list of signatures and preimages (How they're feeded to the > spent script is a covenant implementation detail). However, there is no > guarantee that the offered-to counterparty reveal "all" the preimages she is > awarded off. Non-spent HTLC outputs are clawback to a remainder subset of M, > M'. > > I think this partial reveal of HTLC payout preimages still opens the door to > replacement cycling attacks. > > Let's say you have 5 offered HTLC "payouts" between Alice and Bob aggregated > in a single output, 4 of value 0.1 BTC and 1 of value 1 BTC. All expire at > timelock T. > At T, Alice broadcasts an aggregated HTLC-timeout spend for the 5 HTLC with > 0.0.1 BTC on-chain fee. > > Bob can craft a HTLC-preimage spend of the single offered output spending one > of 0.1 BTC HTLC payout (and revealing its preimage) while burning all the > value as fee. This replaces out Alice's honest HTLC-timeout out of network > mempools, are they're concurrent spend. Bob can repeat this trick as long as > there is HTLC "payout" remaining in the offered set, until he's being able to > do a HTLC off-chain double-spend of the 1 BTC HTLC "payout". > > This stealing gain of the 1 BTC HTLC "payout" covers what has been burned as > miners fees to replace cycle out Alice's sequence of honest HTLC-timeout. > > And it should be noted that Bob might benefit from network mempools > congestion delaying the confirmation of his malicious low-value high-fee > HTLC-preimage transactions. > > > I'm not sure what you mean here, could you elaborate? > > See > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022191.html > and my answer there. > I think "self-sustained" fees is one only part of the solution, the other > part being the sliding delay of the HTLC timelock based on block feerate. > Otherwise, a replacement cycling attacker can always benefit from network > mempools congestion spontaneously pushing out a malicious cycling transaction > out of block templates. > > > That sounds possible, but how would you deal with the exponential > > blowup in the number of combinations? > > In a taproot-world, "swallow the bullet" in terms of witness size growth in > case of non-cooperative closure. > I think this is where introducing an accumulator at the Script level to > efficiently
Re: [bitcoin-dev] HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants)
Hi Johan, > Is this a concern though, if we assume there's no revoked state that > can be broadcast (Eltoo)? Could you share an example of how this would > be played out by an attacker? Sure, let's assume no revoked state can be broadcast (Eltoo). My understanding of the new covenant mechanism is the aggregation or collapsing of all HTLC outputs in one or at least 2 outputs (offered / received). Any spend of an aggregated HTLC "payout" should satisfy the script locking condition by presenting a preimage and a signature. An offerd aggregated HTLC output might collapse a M number of HTLC "payout", where M is still limited by the max standard transaction relay, among other things. The offered-to counterparty can claim any subset N of the aggregation M by presenting the list of signatures and preimages (How they're feeded to the spent script is a covenant implementation detail). However, there is no guarantee that the offered-to counterparty reveal "all" the preimages she is awarded off. Non-spent HTLC outputs are clawback to a remainder subset of M, M'. I think this partial reveal of HTLC payout preimages still opens the door to replacement cycling attacks. Let's say you have 5 offered HTLC "payouts" between Alice and Bob aggregated in a single output, 4 of value 0.1 BTC and 1 of value 1 BTC. All expire at timelock T. At T, Alice broadcasts an aggregated HTLC-timeout spend for the 5 HTLC with 0.0.1 BTC on-chain fee. Bob can craft a HTLC-preimage spend of the single offered output spending one of 0.1 BTC HTLC payout (and revealing its preimage) while burning all the value as fee. This replaces out Alice's honest HTLC-timeout out of network mempools, are they're concurrent spend. Bob can repeat this trick as long as there is HTLC "payout" remaining in the offered set, until he's being able to do a HTLC off-chain double-spend of the 1 BTC HTLC "payout". This stealing gain of the 1 BTC HTLC "payout" covers what has been burned as miners fees to replace cycle out Alice's sequence of honest HTLC-timeout. And it should be noted that Bob might benefit from network mempools congestion delaying the confirmation of his malicious low-value high-fee HTLC-preimage transactions. > I'm not sure what you mean here, could you elaborate? See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022191.html and my answer there. I think "self-sustained" fees is one only part of the solution, the other part being the sliding delay of the HTLC timelock based on block feerate. Otherwise, a replacement cycling attacker can always benefit from network mempools congestion spontaneously pushing out a malicious cycling transaction out of block templates. > That sounds possible, but how would you deal with the exponential > blowup in the number of combinations? In a taproot-world, "swallow the bullet" in terms of witness size growth in case of non-cooperative closure. I think this is where introducing an accumulator at the Script level to efficiently test partial set membership would make sense. Note, exponential blowup is an issue for mass non-coordinated withdrawals of a payment pool too. Best, Antoine Le lun. 11 déc. 2023 à 09:17, Johan Torås Halseth a écrit : > Hi, Antoine. > > > 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. > > Yes, correct. Thanks for pointing that out! > > > 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. > > Is this a concern though, if we assume there's no revoked state that > can be broadcast (Eltoo)? Could you share an example of how this would > be played out by an attacker? > > > 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. > > I'm not sure what you mean here, could you elaborate? > > > I wonder if in a PTLC world, you can generate an aggregate curve point > for all the sub combinations of scalar plausible. Unrevealed curve points > in a taproot branch are cheap. It might claim an offered HTLC near-constant > size too. > > That sounds possible, but how would you deal with the exponential > blowup in the number of combinations? > > Cheers, > Johan > > > On Tue, Nov 21, 2023 at 3:39 AM Antoine Riard > wrote: > > > > 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];
Re: [bitcoin-dev] HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants)
Hi, Antoine. > 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. Yes, correct. Thanks for pointing that out! > 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. Is this a concern though, if we assume there's no revoked state that can be broadcast (Eltoo)? Could you share an example of how this would be played out by an attacker? > 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. I'm not sure what you mean here, could you elaborate? > I wonder if in a PTLC world, you can generate an aggregate curve point for > all the sub combinations of scalar plausible. Unrevealed curve points in a > taproot branch are cheap. It might claim an offered HTLC near-constant size > too. That sounds possible, but how would you deal with the exponential blowup in the number of combinations? Cheers, Johan On Tue, Nov 21, 2023 at 3:39 AM Antoine Riard wrote: > > 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
Re: [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,
[bitcoin-dev] HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants)
Hi all, After the transaction recycling has spurred some discussion the last week or so, I figured it could be worth sharing some research I’ve done into HTLC output aggregation, as it could be relevant for how to avoid this problem in a future channel type. TLDR; With the right covenant we can create HTLC outputs that are much more chain efficient, not prone to tx recycling and harder to jam. ## 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 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. ## 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]. ## 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. ### Slot jamming attack scenario Consider the scenario where an attacker sends a large number of non-dust* HTLCs across a channel, and the channel parties enforce no limit on the number of active HTLCs. The number of payments would not affect the size of the commitment transaction at all, only the size of the witness that must be presented when claiming or timing out the HTLCs. This means that there is still a point at which chain fees get high enough for the HTLC to be uneconomical to claim. This is no different than in today’s spec, and such HTLCs will just be stranded on-chain until chain fees decrease, at which point there is a race between the success and timeout spends. There seems to be no way around this; if you want to claim an HTLC on-chain, you need to put the preimage on-chain. And when the HTLC first reaches you, you have no way of predicting the future chain fee. With a large number of uneconomical HTLCs in play, the total BTC exposure could still be very large, so you might want to limit this somewhat. * Note that as long as the sum of HTLCs exceeds the dust limit, one could manifest the
