From antoine.riard at gmail.com Tue Dec 13 01:38:43 2022 From: antoine.riard at gmail.com (Antoine Riard) Date: Mon, 12 Dec 2022 20:38:43 -0500 Subject: [Lightning-dev] "Updates Overflow" Attacks against Two-Party Eltoo ? Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: