Re: [Lightning-dev] "Updates Overflow" Attacks against Two-Party Eltoo ?
On Mon, Dec 12, 2022 at 08:38:43PM -0500, Antoine Riard wrote: > The attack purpose is to delay the confirmation of the final settlement > transaction S, to double-spend a HTLC forwarded by a routing hop. > The cltv_expiry_delta requested by Ned is equal to N=144. I believe what you're suggesting here is: Mallory has two channels with Bob, M1 and M2. Both have a to_self_delay of 144 blocks. In that case cltv_expiry_delay should include some slack, I'm going to assume it's 154 blocks in total. Mallory forwards a large payment, M1->Bob->M2. Mallory claims the funds on M2 just prior to the timeout, but goes offline on M1. Bob chose the timeout for M2 via cltv_expiry_delay, so now has 154 blocks before the CLTV on the M1->Bob payment expires. In this scenario, under the two-party eltoo scheme, Bob should: 1) immediately broadcast the most recent UB.n state for M1/Bob, aiming for this to be confirmed within 5 blocks 2) wait 144 blocks for the relative timelock to expire 3) broadcast SB.n to finalise the funds, and immediately claim the large HTLC. providing this confirms within 5 blocks, it will confirm before the HTLC timelock expires, and Mallory will have been unable to claim the funds. The only transactions Mallory could broadcast are: prior to (1): UA.k (k <= n) -- However this allows Bob to immediately broadcast one of either CA.n or RA.n, and will then have ~150 blocks to claim the HTLC before its timeout during (2): CA.n -- Again, this allows Bob to claim the HTLC immediately, prior to its timeout The only delaying attack with repeated transactions comes if Bob broadcasts an old state UB.k (k < n), in which case Mallory can broadcast (n-k) WA.i watchtower transactions prior to finalising the state. However if Bob *only* has old state, Mallory can simply broadcast WA.n, at which point Bob can do nothing, as (by assumption) he doesn't have access to current state and thus doesn't have SB.n to broadcast it. > The attack scenario works in the following way: Malicia updates the Eltoo > channel N time, getting the possession of N update transactions. At block > A, she breaks the channel and confirms the update transaction 0 by > attaching a feerate equal to or superior to top mempool block space + 1 > sat. At each new block, she iterates by confirming the next update > transaction, i.e update transaction 1 at block A+1, update transaction > transaction 2 at block A+2, update transaction 3 at block A+3, ... I think traditional eltoo envisages being able to spend update transaction 1 immediately, without having to wait for the next block. This might not be compatible with the version 3 relay rules that are being thought about, though, and presumably would hit ancestor limits. I think a simple way to avoid that problem would be for eltoo nodes to have a priority tx relay network -- if they see a channel close to state N, always replace any txs closing to an earlier state K From Ned's viewpoint, there is limited rationality of the network mempools, > as such each punishment transaction R, as it's confirmation could have been > delay due to "honest" slow propagation on the network is likely to be > pre-signed with top mempool block space feerate, but not more to save on > fees. Therefore, transaction RN.0 should fail to punish update transaction > 0 as it's double-spent by update transaction 1, transaction RN.1 should > fail to punish update transaction 1 as it's double-spent by update > transaction 2, transaction RN.2 should fail to punish update transaction 2 > as it's double-spent by update transaction 3... In the two-party scheme, the only transaction Mallory can broadcast after sending UA.k and having it confirmed on chain is SA.k, and that only after a 144 block relative timelock. UA.(k+1) etc only spend the funding output, but that has already been spent by UA.k. Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Two-party eltoo w/ punishment
Hi Greg, > Feel free to assume that we've worked around mempool pinning for all of > these discussions, otherwise we're pretty hosed regardless. I'm implicitly > assuming V3+ephemeral anchors, which disallows batched bumps, for example. > You'll need to give some room for "slippage", but I think > shared_delay/2*shared_delay is going to end up dominating UX in any > non-layered scheme. I think I was making the same assumption of V3+ephemeral anchors, and effectively disabling batching removes the known case of "commitment cat-and-mouse" attack, where a counterparty goes to confirm the commitment one by one to break the validity of the common CPFP. However, I wonder if there is not another attack case, see my other "update overflow" mail, and I don't think it qualifies as a pinning here! > This architecture doesn't suffer from 2*self_delay, and each transition > aside from Slow/Settle/SX.y has no relative timelock so that relative > timelock is all that matters. It does introduce a watchtower cycle, so it's > not longer a one-shot architecture, or even k-shot exactly, it ends up > looking like vanilla eltoo for that single path. Here I think my understanding is aligned, the watchtower cycle ends up looking more like the update phase of vanilla eltoo. Antoine Le jeu. 8 déc. 2022 à 15:28, Greg Sanders a écrit : > Antoine, > > > While the 2*to_self_delay sounds the maximum time delay in the state > publication scenario where the cheating counterparty publishes a old state > then the honest counterparty publishes the latest one, there could be the > case where the cheating counterparty broadcast chain of old states, up to > mempool's `limitancestorcount`. However, this chain of eltoo transactions > could be replaced by the honest party paying a higher-feerate (assuming > something like nversion=3). I think there might still be an attack > triggerable under certain economic conditions, where the attacker overbids > with the higher-feerate transaction until the HTLC cltv expires. If this > attack is plausible, it could be even opportun if you're batching against > multiple channels, where the victims are not able to coordinate response. > > Feel free to assume that we've worked around mempool pinning for all of > these discussions, otherwise we're pretty hosed regardless. I'm implicitly > assuming V3+ephemeral anchors, which disallows batched bumps, for example. > You'll need to give some room for "slippage", but I think > shared_delay/2*shared_delay is going to end up dominating UX in any > non-layered scheme. > > > I wonder if the introduction of watchtower specific transactions doesn't > break the 2*to_self_delay assumption > > This architecture doesn't suffer from 2*self_delay, and each transition > aside from Slow/Settle/SX.y has no relative timelock so that relative > timelock is all that matters. It does introduce a watchtower cycle, so it's > not longer a one-shot architecture, or even k-shot exactly, it ends up > looking like vanilla eltoo for that single path. > > Cheers, > Greg > > On Thu, Dec 8, 2022 at 2:14 PM Antoine Riard > wrote: > >> Hi AJ, >> >> The eltoo irc channel is ##eltoo on Libera chat. >> >> > - 2022-10-21, eltoo/chia: >> https://twitter.com/bramcohen/status/1583122833932099585 >> >> On the eltoo/chia variant, from my (quick) understanding, the main >> innovation aimed for is the limitation of the publication of eltoo states >> more than once by a counterparty, by introducing a cryptographic puzzle, >> where the witness can be produced once and only once ? I would say you >> might need the inheritance of the updated scriptpubkey across the chain of >> eltoo states, with a TLUV-like mechanism. >> >> > The basic idea is "if it's a two party channel with just Alice and Bob, >> > then if Alice starts a unilateral close, then she's already had her say, >> > so it's only Bob's opinion that matters from now on, and he should be >> > able to act immediately", and once it's only Bob's opinion that matters, >> > you can simplify a bunch of things. >> >> From my understanding, assuming Eltoo paper terminology, Alice can >> publish an update K transaction, and then after Bob can publish an update >> transaction K> can publish an update transaction N. The main advantage of this >> construction I can see is a strict bound on the shared_delay encumbered in >> the on-chain publication of the channel ? >> >> > fast forwards: we might want to allow our channel partner >> > to immediately rely on a new state we propose without needing a >> > round-trip delay -- this potentially makes forwarding payments much >> > faster (though with some risk of locking the funds up, if you do a >> > fast forward to someone who's gone offline) >> >> IIRC, there has already been a "fast-forward" protocol upgrade proposal >> based on update-turn in the LN-penalty paradigm [0]. I think reducing the >> latency of HTLC propagation across payment paths would constitute a UX >> improvement, especially a link-level
[Lightning-dev] "Updates Overflow" Attacks against Two-Party Eltoo ?
Hi list, The following post describes a potential attack vector against eltoo-based Lightning channels, from my understanding also including the recent two-party eltoo w/ punishment construction. While I think this concern has been known for a while among devs, and I believe it's mitigable by adopting an adequate fee-bumping strategy, I still wonder how exactly it affects eltoo-based constructions. AFAICT, the eltoo 2-stage proposal relies on a serie of pre-signed update transactions, of which in the optimistic case only one of them confirms. There is a script-spend path, where an update transaction N can spend an update transaction K, assuming KFrom Ned's viewpoint, there is limited rationality of the network mempools, as such each punishment transaction R, as it's confirmation could have been delay due to "honest" slow propagation on the network is likely to be pre-signed with top mempool block space feerate, but not more to save on fees. Therefore, transaction RN.0 should fail to punish update transaction 0 as it's double-spent by update transaction 1, transaction RN.1 should fail to punish update transaction 1 as it's double-spent by update transaction 2, transaction RN.2 should fail to punish update transaction 2 as it's double-spent by update transaction 3... While there is a RBF-race, I think this can be easily won by Malicia by mass-connecting on the transaction-relay network and ignoring the Core transaction-relay delay timers (here for privacy purposes iirc). If it holds, I think the attack is economically opportun as long as the sum of the chain of update transactions weight multiplied by the spent feerate is inferior to the sum of HTLC values stolen (upper bounded to `max_htlc_value_in_flight_msat`, not `funding_satoshis`). The attack could be more sound in periods of low-fee, as the number of HTLC exploitable is higher. A mitigation could be for a fee-bumping strategy to adopt a scorched approach when the HTLC-timeout is approaching, and there is a corresponding incoming HTLC. When the HTLC-timeout is near expiration (e.g X blocks from incoming HTLC expiry), probably 100% of the HTLC value should be burnt in update transaction fees. I think some implementations in the LN-penalty are already doing "upward" fee-bumping frequency, while I believe it reduces the attack surface, I still think there is an exploitable window for "update overflow" attack. E.g in LDK justice transactions are bumped by 25% every block according to a height timer schedule [0]. Assuming the attack holds, and scorched approach are adopted by default to mitigate this concern, there is a second-order concern, we might open Lightning channels to miner-harvesting attacks, where the confirmation of the update transactions are deferred to kick-out the scorched earth reaction of the fee-bumping engine. In my opinion, this would be still an improvement, as we're moving a (plausible) security risk triggerable by a Lightning counterparty to (hypothetical) one triggerable by a wide coalition of miners. There is another caveat, it sounds if the update transaction can be malleable (i.e SIGHASH_SINGLE|ANYONECANPAY), update transactions across Lightning channels could be aggregated by the attacker, changing the economy there in a way defavorable to the victims. I.e the attacker can select the targeted channels, but the victim cannot coordinate with each other to respond with a collective fee-bumping. Is the understanding of the two-party eltoo construction correct, and this "update overflow" attack is sound and economically opportun ? If it holds, I still wonder if we have variants playing with mempool descendant limits. In all cases, it sounds to me the implications are more in the way fee-bumping is implemented by Lightning softwares rather than directly on eltoo-based constructions, I don't see an immediate way to address it by the construction itself. Mistakes and confusions are my own. Antoine [0] https://github.com/lightningdevkit/rust-lightning/blob/5e14c24a11f610ab8c402f788ec5bd637e9e24af/lightning/src/chain/onchaintx.rs#L505 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
