Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8B1F3C0032; Thu, 19 Oct 2023 17:22:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 541E34060C; Thu, 19 Oct 2023 17:22:17 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 541E34060C Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=DxxBtShQ X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMgX4-TBLY9f; Thu, 19 Oct 2023 17:22:13 +0000 (UTC) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) by smtp2.osuosl.org (Postfix) with ESMTPS id 4A4C04019D; Thu, 19 Oct 2023 17:22:13 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4A4C04019D Received: by mail-il1-x12e.google.com with SMTP id e9e14a558f8ab-3528bc102adso30522495ab.2; Thu, 19 Oct 2023 10:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697736132; x=1698340932; darn=lists.linuxfoundation.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xW2ITEgmwPkr/h+lsSeDj1ZeM94awEmIc0f0YYIBVdw=; b=DxxBtShQJN25RnHFfG3vqB3NPgzOI9SXgX/UdnVQ1KkM5FY5ES6A5xf1YyeJlGY2eE tIzAjOyf9nGH0EOv7Q/W4r+yA3Ht0ZjzTcE6fjEmjtwSOWeeR3Xe+DWYntFG6snHUWVk 38dUuFovHF6zP0Hd/2WbdHwc+B3AsF4DII9o6TPICH4/NK8eo1jhZnLOvBLzS+tLhxw+ +omJRY2SEEKKeSQY6NItOrHMFqfus3TmwwE3My84HgNoijbX/85AYCWLrGzrfndFxvS5 OmDFqFfTwFdcgXKRp++VKmne0ql3ltLuFiO2Bl7zexu8gb32MVFCnXYetVb8sEUS6M5G itqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697736132; x=1698340932; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xW2ITEgmwPkr/h+lsSeDj1ZeM94awEmIc0f0YYIBVdw=; b=Hpb6dcW4XjFtvb6HNzRl6pvzh8R1MqIvZIkXDWEq5gAS8e9GxzyRDkzIF/wBSwOi8w pN//fe+ZGqkGsb5jtwrtWIG3pAf9TdzzqxklYww2dTvSDbXgt24owPxUnxq2Xp6ghSPX bsFLb1qycdTgz3uy2/V08kmwD02lP7Dh3K2yypk7MVmnVPH27IVB3M4M1KgZs6VRkbzm MK3TxrVFqypgLYOZJk2/PAxM0tM2OnVkqTEIfYqttsPvsilFKu/FCdUyOtb/Dmar9zoo ySc30RNi+82fluNvcT0PtMJuJzI7oArL0DRjBkk+2c7KyiDZAT6gD9DDYMmq7/P1Afxe 8+Ew== X-Gm-Message-State: AOJu0Yzesz3AKBbvQBUpn3oDFxHIdaha8SaCzYR+9wY4MsN3UaRAJSP1 5tRZtX3SN/9ImJR2vm0NK0ubdmzOULtJYMXsrgy2LODmobexFQ== X-Google-Smtp-Source: AGHT+IHRkopE9WO6S0ZDlmnQIQ04G3gy836wwLR/Wy7u/5rJb8cliv6zWCyVb4x31pJwA7ypCi0mc+NcKLYJfdsT99E= X-Received: by 2002:a92:d78d:0:b0:357:a8cc:44dd with SMTP id d13-20020a92d78d000000b00357a8cc44ddmr3043946iln.31.1697736132196; Thu, 19 Oct 2023 10:22:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Thu, 19 Oct 2023 18:22:01 +0100 Message-ID: To: Matt Morehouse Content-Type: multipart/alternative; boundary="000000000000150479060814ffd5" X-Mailman-Approved-At: Thu, 19 Oct 2023 21:52:02 +0000 Cc: Bitcoin Protocol Discussion , security@ariard.me, "lightning-dev\\\\@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2023 17:22:17 -0000 --000000000000150479060814ffd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Matt, This mitigation is mentioned in the attached paper (see subsection 3.4 defensive fee-rebroadcasting) https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/r= eplacement-cycling.pdf As soon as you start to have a bit of a mempool backlog and the defensive fractional fee HTLC-timeout stays stuck, it gives the advantage to the attacker again. Beyond that, I think an attacker can replace-cycle multiple honest HTLC-timeout with a single malicious HTLC-preimage (with a sequence of replacement, not concurrently) paying the absolute fee, while only encumbering the RBF penalty. I didn't test this specific behavior, though the "fees" math doesn't seem at the advantage of the defenders at first sight. Best, Antoine Le jeu. 19 oct. 2023 =C3=A0 17:23, Matt Morehouse = a =C3=A9crit : > On Wed, Oct 18, 2023 at 12:34=E2=80=AFAM Matt Corallo via bitcoin-dev > wrote: > > > > There appears to be some confusion about this issue and the mitigations= . > To be clear, the deployed > > mitigations are not expected to fix this issue, its arguable if they > provide anything more than a PR > > statement. > > > > There are two discussed mitigations here - mempool scanning and > transaction re-signing/re-broadcasting. > > > > Mempool scanning relies on regularly checking the mempool of a local > node to see if we can catch the > > replacement cycle mid-cycle. It only works if wee see the first > transaction before the second > > transaction replaces it. > > > > Today, a large majority of lightning nodes run on machines with a > Bitcoin node on the same IP > > address, making it very clear what the "local node" of the lightning > node is. An attacker can > > trivially use this information to connect to said local node and do the > replacement quickly, > > preventing the victim from seeing the replacement. > > > > More generally, however, similar discoverability is true for mining > pools. An attacker performing > > this attack is likely to do the replacement attack on a miner's node > directly, potentially reducing > > the reach of the intermediate transaction to only miners, such that the > victim can never discover it > > at all. > > > > The second mitigation is similarly pathetic. Re-signing and > re-broadcasting the victim's transaction > > in an attempt to get it to miners even if its been removed may work, if > the attacker is super lazy > > and didn't finish writing their attack system. If the attacker is > connected to a large majority of > > hashrate (which has historically been fairly doable), they can simply d= o > their replacement in a > > cycle aggressively and arbitrarily reduce the probability that the > victim's transaction gets confirmed. > > What if the honest node aggressively fee-bumps and retransmits the > HTLC-timeout as the CLTV delta deadline approaches, as suggested by > Ziggie? Say, within 10 blocks of the deadline, the honest node starts > increasing the fee by 1/10th the HTLC value for each non-confirmation. > > This "scorched earth" approach may cost the honest node considerable > fees, but it will cost the attacker even more, since each attacker > replacement needs to burn at least as much as the HTLC-timeout fees, > and the attacker will need to do a replacement every time the honest > node fee bumps. > > I think this fee-bumping policy will provide sufficient defense even > if the attacker is replacement-cycling directly in miners' mempools > and the victim has no visibility into the attack. > > > > > Now, the above is all true in a spherical cow kinda world, and the P2P > network has plenty of slow > > nodes and strange behavior. Its possible that these mitigations might, > by some stroke of luck, > > happen to catch such an attack and prevent it, because something took > longer than the attacker > > intended or whatever. But, that's a far cry from any kind of material > "fix" for the issue. > > > > Ultimately the only fix for this issue will be when miners keep a > history of transactions they've > > seen and try them again after they may be able to enter the mempool > because of an attack like this. > > > > Matt > > > > On 10/16/23 12:57 PM, Antoine Riard wrote: > > > (cross-posting mempool issues identified are exposing lightning chan > to loss of funds risks, other > > > multi-party bitcoin apps might be affected) > > > > > > Hi, > > > > > > End of last year (December 2022), amid technical discussions on eltoo > payment channels and > > > incentives compatibility of the mempool anti-DoS rules, a new > transaction-relay jamming attack > > > affecting lightning channels was discovered. > > > > > > After careful analysis, it turns out this attack is practical and > immediately exposed lightning > > > routing hops carrying HTLC traffic to loss of funds security risks, > both legacy and anchor output > > > channels. A potential exploitation plausibly happening even without > network mempools congestion. > > > > > > Mitigations have been designed, implemented and deployed by all major > lightning implementations > > > during the last months. > > > > > > Please find attached the release numbers, where the mitigations shoul= d > be present: > > > - LDK: v0.0.118 - CVE-2023 -40231 > > > - Eclair: v0.9.0 - CVE-2023-40232 > > > - LND: v.0.17.0-beta - CVE-2023-40233 > > > - Core-Lightning: v.23.08.01 - CVE-2023-40234 > > > > > > While neither replacement cycling attacks have been observed or > reported in the wild since the last > > > ~10 months or experimented in real-world conditions on bitcoin mainet= , > functional test is available > > > exercising the affected lightning channel against bitcoin core mempoo= l > (26.0 release cycle). > > > > > > It is understood that a simple replacement cycling attack does not > demand privileged capabilities > > > from an attacker (e.g no low-hashrate power) and only access to basic > bitcoin and lightning > > > software. Yet I still think executing such an attack successfully > requests a fair amount of bitcoin > > > technical know-how and decent preparation. > > > > > > From my understanding of those issues, it is yet to be determined if > the mitigations deployed are > > > robust enough in face of advanced replacement cycling attackers, > especially ones able to combine > > > different classes of transaction-relay jamming such as pinnings or > vetted with more privileged > > > capabilities. > > > > > > Please find a list of potential affected bitcoin applications in this > full disclosure report using > > > bitcoin script timelocks or multi-party transactions, albeit no > immediate security risk exposure as > > > severe as the ones affecting lightning has been identified. Only > cursory review of non-lightning > > > applications has been conducted so far. > > > > > > There is a paper published summarizing replacement cycling attacks on > the lightning network: > > > > https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper= /replacement-cycling.pdf > > > < > https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper= /replacement-cycling.pdf > > > > > > > > ## Problem > > > > > > A lightning node allows HTLCs forwarding (in bolt3's parlance accepte= d > HTLC on incoming link and > > > offered HTLC on outgoing link) should settle the outgoing state with > either a success or timeout > > > before the incoming state timelock becomes final and an asymmetric > defavorable settlement might > > > happen (cf "Flood & Loot: A Systematic Attack on The Lightning > Network" section 2.3 for a classical > > > exposition of this lightning security property). > > > > > > Failure to satisfy this settlement requirement exposes a forwarding > hop to a loss of fund risk where > > > the offered HTLC is spent by the outgoing link counterparty's > HTLC-preimage and the accepted HTLC is > > > spent by the incoming link counterparty's HTLC-timeout. > > > > > > The specification mandates the incoming HTLC expiration timelock to b= e > spaced out by an interval of > > > `cltv_expiry_delta` from the outgoing HTLC expiration timelock, this > exact interval value being an > > > implementation and node policy setting. As a minimal value, the > specification recommends 34 blocks > > > of interval. If the timelock expiration I of the inbound HTLC is equa= l > to 100 from chain tip, the > > > timelock expiration O of the outbound HTLC must be equal to 66 blocks > from chain tip, giving a > > > reasonable buffer of reaction to the lightning forwarding node. > > > > > > In the lack of cooperative off-chain settlement of the HTLC on the > outgoing link negotiated with the > > > counterparty (either `update_fulfill_htlc` or `update_fail_htlc`) whe= n > O is reached, the lightning > > > node should broadcast its commitment transaction. Once the commitment > is confirmed (if anchor and > > > the 1 CSV encumbrance is present), the lightning node broadcasts and > confirms its HTLC-timeout > > > before I height is reached. > > > > > > Here enter a replacement cycling attack. A malicious channel > counterparty can broadcast its > > > HTLC-preimage transaction with a higher absolute fee and higher > feerate than the honest HTLC-timeout > > > of the victim lightning node and triggers a replacement. Both for > legacy and anchor output channels, > > > a HTLC-preimage on a counterparty commitment transaction is malleable= , > i.e additional inputs or > > > outputs can be added. The HTLC-preimage spends an unconfirmed and > unrelated to the channel parent > > > transaction M and conflicts its child. > > > > > > As the HTLC-preimage spends an unconfirmed input that was already > included in the unconfirmed and > > > unrelated child transaction (rule 2), pays an absolute higher fee of > at least the sum paid by the > > > HTLC-timeout and child transaction (rule 3) and the HTLC-preimage > feerate is greater than all > > > directly conflicting transactions (rule 6), the replacement is > accepted. The honest HTLC-timeout is > > > evicted out of the mempool. > > > > > > In an ulterior move, the malicious counterparty can replace the paren= t > transaction itself with > > > another candidate N satisfying the replacement rules, triggering the > eviction of the malicious > > > HTLC-preimage from the mempool as it was a child of the parent T. > > > > > > There is no spending candidate of the offered HTLC output for the > current block laying in network > > > mempools. > > > > > > This replacement cycling tricks can be repeated for each rebroadcast > attempt of the HTLC-timeout by > > > the honest lightning node until expiration of the inbound HTLC > timelock I. Once this height is > > > reached a HTLC-timeout is broadcast by the counterparty's on the > incoming link in collusion with the > > > one on the outgoing link broadcasting its own HTLC-preimage. > > > > > > The honest Lightning node has been "double-spent" in its HTLC > forwarding. > > > > > > As a notable factor impacting the success of the attack, a lightning > node's honest HTLC-timeout > > > might be included in the block template of the miner winning the bloc= k > race and therefore realizes a > > > spent of the offered output. In practice, a replacement cycling attac= k > might over-connect to miners' > > > mempools and public reachable nodes to succeed in a fast eviction of > the HTLC-timeout by its > > > HTLC-preimage. As this latter transaction can come with a better > ancestor-score, it should be picked > > > up on the flight by economically competitive miners. > > > > > > A functional test exercising a simple replacement cycling of a HTLC > transaction on bitcoin core > > > mempool is available: > > > https://github.com/ariard/bitcoin/commits/2023-test-mempool > > > > > > > > > ## Deployed LN mitigations > > > > > > Aggressive rebroadcasting: As the replacement cycling attacker > benefits from the HTLC-timeout being > > > usually broadcast by lightning nodes only once every block, or less > the replacement cycling > > > malicious transactions paid only equal the sum of the absolute fees > paid by the HTLC, adjusted with > > > the replacement penalty. Rebroadcasting randomly and multiple times > before the next block increases > > > the absolute fee cost for the attacker. > > > > > > Implemented and deployed by Eclair, Core-Lightning, LND and LDK . > > > > > > Local-mempool preimage monitoring: As the replacement cycling attacke= r > in a simple setup broadcast > > > the HTLC-preimage to all the network mempools, the honest lightning > node is able to catch on the > > > flight the unconfirmed HTLC-preimage, before its subsequent mempool > replacement. The preimage can be > > > extracted from the second-stage HTLC-preimage and used to fetch the > off-chain inbound HTLC with a > > > cooperative message or go on-chain with it to claim the accepted HTLC > output. > > > > > > Implemented and deployed by Eclair and LND. > > > > > > CLTV Expiry Delta: With every jammed block comes an absolute fee cost > paid by the attacker, a risk > > > of the HTLC-preimage being detected or discovered by the honest > lightning node, or the HTLC-timeout > > > to slip in a winning block template. Bumping the default CLTV delta > hardens the odds of success of a > > > simple replacement cycling attack. > > > > > > Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72. > > > > > > ## Affected Bitcoin Protocols and Applications > > > > > > From my understanding the following list of Bitcoin protocols and > applications could be affected by > > > new denial-of-service vectors under some level of network mempools > congestion. Neither tests or > > > advanced review of specifications (when available) has been conducted > for each of them: > > > - on-chain DLCs > > > - coinjoins > > > - payjoins > > > - wallets with time-sensitive paths > > > - peerswap and submarine swaps > > > - batch payouts > > > - transaction "accelerators" > > > > > > Inviting their developers, maintainers and operators to investigate > how replacement cycling attacks > > > might disrupt their in-mempool chain of transactions, or fee-bumping > flows at the shortest delay. > > > Simple flows and non-multi-party transactions should not be affected > to the best of my understanding. > > > > > > ## Open Problems: Package Malleability > > > > > > Pinning attacks have been known for years as a practical vector to > compromise lightning channels > > > funds safety, under different scenarios (cf. current bip331's > motivation section). Mitigations at > > > the mempool level have been designed, discussed and are under > implementation by the community > > > (ancestor package relay + nverrsion=3D3 policy). Ideally, they should > constraint a pinning attacker to > > > always attach a high feerate package (commitment + CPFP) to replace > the honest package, or allow a > > > honest lightning node to overbid a malicious pinning package and get > its time-sensitive transaction > > > optimistically included in the chain. > > > > > > Replacement cycling attack seem to offer a new way to neutralize the > design goals of package relay > > > and its companion nversion=3D3 policy, where an attacker package RBF = a > honest package out of the > > > mempool to subsequently double-spend its own high-fee child with a > transaction unrelated to the > > > channel. As the remaining commitment transaction is pre-signed with a > minimal relay fee, it can be > > > evicted out of the mempool. > > > > > > A functional test exercising a simple replacement cycling of a > lightning channel commitment > > > transaction on top of the nversion=3D3 code branch is available: > > > https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2 > > > > > > > > > ## Discovery > > > > > > In 2018, the issue of static fees for pre-signed lightning > transactions is made more widely known, > > > the carve-out exemption in mempool rules to mitigate in-mempool > package limits pinning and the > > > anchor output pattern are proposed. > > > > > > In 2019, bitcoin core 0.19 is released with carve-out support. > Continued discussion of the anchor > > > output pattern as a dynamic fee-bumping method. > > > > > > In 2020, draft of anchor output submitted to the bolts. Initial > finding of economic pinning against > > > lightning commitment and second-stage HTLC transactions. Subsequent > discussions of a > > > preimage-overlay network or package-relay as mitigations. Public call > made to inquiry more on > > > potential other transaction-relay jamming attacks affecting lightning= . > > > > > > In 2021, initial work in bitcoin core 22.0 of package acceptance. > Continued discussion of the > > > pinning attacks and shortcomings of current mempool rules during > community-wide online workshops. > > > Later the year, in light of all issues for bitcoin second-layers, a > proposal is made about killing > > > the mempool. > > > > > > In 2022, bip proposed for package relay and new proposed v3 policy > design proposed for a review and > > > implementation. Mempoolfullrbf is supported in bitcoin core 24.0 and > conceptual questions about > > > alignment of mempool rules w.r.t miners incentives are investigated. > > > > > > Along this year 2022, eltoo lightning channels design are discussed, > implemented and reviewed. In > > > this context and after discussions on mempool anti-DoS rules, I > discovered this new replacement > > > cycling attack was affecting deployed lightning channels and > immediately reported the finding to > > > some bitcoin core developers and lightning maintainers. > > > > > > ## Timeline > > > > > > - 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns, > Greg Sanders and Gloria Zhao > > > - 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien > Teinturier, Matt Corallo and Olaoluwa > > > Osuntunkun > > > - 2022-12-23: Sharing to Eugene Siegel (LND) > > > - 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot > (non-lightning potential affected projects) > > > - 2022-01-14: Sharing to Gleb Naumenko (miners incentives and > cross-layers issuers) and initial > > > proposal of an early public disclosure > > > - 2022-01-19: Collection of analysis if other second-layers and > multi-party applications affected. > > > LN mitigations development starts. > > > - 2023-05-04: Sharing to Wilmer Paulino (LDK) > > > - 2023-06-20: LN mitigations implemented and progressively released. > Week of the 16 october proposed > > > for full disclosure. > > > - 2023-08-10: CVEs assigned by MITRE > > > - 2023-10-05: Pre-disclosure of LN CVEs numbers and replacement > cycling attack existence to > > > security@bitcoincore.org . > > > - 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2023-40232 / > CVE-2023-40233 / CVE-2023-40234 > > > and replacement cycling attacks > > > > > > ## Conclusion > > > > > > Despite the line of mitigations adopted and deployed by current major > lightning implementations, I > > > believe replacement cycling attacks are still practical for advanced > attackers. Beyond this new > > > attack might come as a way to partially or completely defeat some of > the pinning mitigations which > > > have been working for years as a community. > > > > > > As of today, it is uncertain to me if lightning is not affected by a > more severe long-term package > > > malleability critical security issue under current consensus rules, > and if any other time-sensitive > > > multi-party protocol, designed or deployed isn't de facto affected to= o > (loss of funds or denial of > > > service). > > > > > > Assuming analysis on package malleability is correct, it is unclear t= o > me if it can be corrected by > > > changes in replacement / eviction rules or mempool chain of > transactions processing strategy. > > > Inviting my technical peers and the bitcoin community to look more on > this issue, including to > > > dissent. I'll be the first one pleased if I'm fundamentally wrong on > those issues, or if any element > > > has not been weighted with the adequate technical accuracy it deserve= s. > > > > > > Do not trust, verify. All mistakes and opinions are my own. > > > > > > Antoine > > > > > > "meet with Triumph and Disaster. And treat those two impostors just > the same" - K. > > > > > > _______________________________________________ > > > Lightning-dev mailing list > > > Lightning-dev@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000150479060814ffd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Matt,

This mitigation is mentioned i= n the attached paper (see subsection 3.4 defensive fee-rebroadcasting)
As soon as you start to have a bit of a mempool backlog a= nd the defensive fractional fee HTLC-timeout stays stuck, it gives the adva= ntage to the attacker again.

Beyond that, I think = an attacker can replace-cycle multiple honest HTLC-timeout with a single ma= licious HTLC-preimage (with a sequence of replacement, not concurrently) pa= ying the absolute fee, while only encumbering the RBF penalty. I didn't= test this specific behavior, though the "fees" math doesn't = seem at the advantage of the defenders at first sight.

=
Best,
Antoine

Le=C2=A0jeu. 19 oct. 2023 =C3=A0=C2=A017:= 23, Matt Morehouse <mattmoreh= ouse@gmail.com> a =C3=A9crit=C2=A0:
On Wed= , Oct 18, 2023 at 12:34=E2=80=AFAM Matt Corallo via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> There appears to be some confusion about this issue and the mitigation= s. To be clear, the deployed
> mitigations are not expected to fix this issue, its arguable if they p= rovide anything more than a PR
> statement.
>
> There are two discussed mitigations here - mempool scanning and transa= ction re-signing/re-broadcasting.
>
> Mempool scanning relies on regularly checking the mempool of a local n= ode to see if we can catch the
> replacement cycle mid-cycle. It only works if wee see the first transa= ction before the second
> transaction replaces it.
>
> Today, a large majority of lightning nodes run on machines with a Bitc= oin node on the same IP
> address, making it very clear what the "local node" of the l= ightning node is. An attacker can
> trivially use this information to connect to said local node and do th= e replacement quickly,
> preventing the victim from seeing the replacement.
>
> More generally, however, similar discoverability is true for mining po= ols. An attacker performing
> this attack is likely to do the replacement attack on a miner's no= de directly, potentially reducing
> the reach of the intermediate transaction to only miners, such that th= e victim can never discover it
> at all.
>
> The second mitigation is similarly pathetic. Re-signing and re-broadca= sting the victim's transaction
> in an attempt to get it to miners even if its been removed may work, i= f the attacker is super lazy
> and didn't finish writing their attack system. If the attacker is = connected to a large majority of
> hashrate (which has historically been fairly doable), they can simply = do their replacement in a
> cycle aggressively and arbitrarily reduce the probability that the vic= tim's transaction gets confirmed.

What if the honest node aggressively fee-bumps and retransmits the
HTLC-timeout as the CLTV delta deadline approaches, as suggested by
Ziggie?=C2=A0 Say, within 10 blocks of the deadline, the honest node starts=
increasing the fee by 1/10th the HTLC value for each non-confirmation.

This "scorched earth" approach may cost the honest node considera= ble
fees, but it will cost the attacker even more, since each attacker
replacement needs to burn at least as much as the HTLC-timeout fees,
and the attacker will need to do a replacement every time the honest
node fee bumps.

I think this fee-bumping policy will provide sufficient defense even
if the attacker is replacement-cycling directly in miners' mempools
and the victim has no visibility into the attack.

>
> Now, the above is all true in a spherical cow kinda world, and the P2P= network has plenty of slow
> nodes and strange behavior. Its possible that these mitigations might,= by some stroke of luck,
> happen to catch such an attack and prevent it, because something took = longer than the attacker
> intended or whatever. But, that's a far cry from any kind of mater= ial "fix" for the issue.
>
> Ultimately the only fix for this issue will be when miners keep a hist= ory of transactions they've
> seen and try them again after they may be able to enter the mempool be= cause of an attack like this.
>
> Matt
>
> On 10/16/23 12:57 PM, Antoine Riard wrote:
> > (cross-posting mempool issues identified are exposing lightning c= han to loss of funds risks, other
> > multi-party bitcoin apps might be affected)
> >
> > Hi,
> >
> > End of last year (December 2022), amid technical discussions on e= ltoo payment channels and
> > incentives compatibility of the mempool anti-DoS rules, a new tra= nsaction-relay jamming attack
> > affecting lightning channels was discovered.
> >
> > After careful analysis, it turns out this attack is practical and= immediately exposed lightning
> > routing hops carrying HTLC traffic to loss of funds security risk= s, both legacy and anchor output
> > channels. A potential exploitation plausibly happening even witho= ut network mempools congestion.
> >
> > Mitigations have been designed, implemented and deployed by all m= ajor lightning implementations
> > during the last months.
> >
> > Please find attached the release numbers, where the mitigations s= hould be present:
> > - LDK: v0.0.118 - CVE-2023 -40231
> > - Eclair: v0.9.0 - CVE-2023-40232
> > - LND: v.0.17.0-beta - CVE-2023-40233
> > - Core-Lightning: v.23.08.01 - CVE-2023-40234
> >
> > While neither replacement cycling attacks have been observed or r= eported in the wild since the last
> > ~10 months or experimented in real-world conditions on bitcoin ma= inet, functional test is available
> > exercising the affected lightning channel against bitcoin core me= mpool (26.0 release cycle).
> >
> > It is understood that a simple replacement cycling attack does no= t demand privileged capabilities
> > from an attacker (e.g no low-hashrate power) and only access to b= asic bitcoin and lightning
> > software. Yet I still think executing such an attack successfully= requests a fair amount of bitcoin
> > technical know-how and decent preparation.
> >
> >=C2=A0 From my understanding of those issues, it is yet to be dete= rmined if the mitigations deployed are
> > robust enough in face of advanced replacement cycling attackers, = especially ones able to combine
> > different classes of transaction-relay jamming such as pinnings o= r vetted with more privileged
> > capabilities.
> >
> > Please find a list of potential affected bitcoin applications in = this full disclosure report using
> > bitcoin script timelocks or multi-party transactions, albeit no i= mmediate security risk exposure as
> > severe as the ones affecting lightning has been identified. Only = cursory review of non-lightning
> > applications has been conducted so far.
> >
> > There is a paper published summarizing replacement cycling attack= s on the lightning network:
> > https://github.com/ariard/mempool-research/blob/2023-10-replacement-= paper/replacement-cycling.pdf
> > <https://github.com/ariard/mempool-research/blob/2023-10-replace= ment-paper/replacement-cycling.pdf>
> >
> >=C2=A0 =C2=A0## Problem
> >
> > A lightning node allows HTLCs forwarding (in bolt3's parlance= accepted HTLC on incoming link and
> > offered HTLC on outgoing link) should settle the outgoing state w= ith either a success or timeout
> > before the incoming state timelock becomes final and an asymmetri= c defavorable settlement might
> > happen (cf "Flood & Loot: A Systematic Attack on The Lig= htning Network" section 2.3 for a classical
> > exposition of this lightning security property).
> >
> > Failure to satisfy this settlement requirement exposes a forwardi= ng hop to a loss of fund risk where
> > the offered HTLC is spent by the outgoing link counterparty's= HTLC-preimage and the accepted HTLC is
> > spent by the incoming link counterparty's HTLC-timeout.
> >
> > The specification mandates the incoming HTLC expiration timelock = to be spaced out by an interval of
> > `cltv_expiry_delta` from the outgoing HTLC expiration timelock, t= his exact interval value being an
> > implementation and node policy setting. As a minimal value, the s= pecification recommends 34 blocks
> > of interval. If the timelock expiration I of the inbound HTLC is = equal to 100 from chain tip, the
> > timelock expiration O of the outbound HTLC must be equal to 66 bl= ocks from chain tip, giving a
> > reasonable buffer of reaction to the lightning forwarding node. > >
> > In the lack of cooperative off-chain settlement of the HTLC on th= e outgoing link negotiated with the
> > counterparty (either `update_fulfill_htlc` or `update_fail_htlc`)= when O is reached, the lightning
> > node should broadcast its commitment transaction. Once the commit= ment is confirmed (if anchor and
> > the 1 CSV encumbrance is present), the lightning node broadcasts = and confirms its HTLC-timeout
> > before I height is reached.
> >
> > Here enter a replacement cycling attack. A malicious channel coun= terparty can broadcast its
> > HTLC-preimage transaction with a higher absolute fee and higher f= eerate than the honest HTLC-timeout
> > of the victim lightning node and triggers a replacement. Both for= legacy and anchor output channels,
> > a HTLC-preimage on a counterparty commitment transaction is malle= able, i.e additional inputs or
> > outputs can be added. The HTLC-preimage spends an unconfirmed and= unrelated to the channel parent
> > transaction M and conflicts its child.
> >
> > As the HTLC-preimage spends an unconfirmed input that was already= included in the unconfirmed and
> > unrelated child transaction (rule 2), pays an absolute higher fee= of at least the sum paid by the
> > HTLC-timeout and child transaction (rule 3) and the HTLC-preimage= feerate is greater than all
> > directly conflicting transactions (rule 6), the replacement is ac= cepted. The honest HTLC-timeout is
> > evicted out of the mempool.
> >
> > In an ulterior move, the malicious counterparty can replace the p= arent transaction itself with
> > another candidate N satisfying the replacement rules, triggering = the eviction of the malicious
> > HTLC-preimage from the mempool as it was a child of the parent T.=
> >
> > There is no spending candidate of the offered HTLC output for the= current block laying in network
> > mempools.
> >
> > This replacement cycling tricks can be repeated for each rebroadc= ast attempt of the HTLC-timeout by
> > the honest lightning node until expiration of the inbound HTLC ti= melock I. Once this height is
> > reached a HTLC-timeout is broadcast by the counterparty's on = the incoming link in collusion with the
> > one on the outgoing link broadcasting its own HTLC-preimage.
> >
> > The honest Lightning node has been "double-spent" in it= s HTLC forwarding.
> >
> > As a notable factor impacting the success of the attack, a lightn= ing node's honest HTLC-timeout
> > might be included in the block template of the miner winning the = block race and therefore realizes a
> > spent of the offered output. In practice, a replacement cycling a= ttack might over-connect to miners'
> > mempools and public reachable nodes to succeed in a fast eviction= of the HTLC-timeout by its
> > HTLC-preimage. As this latter transaction can come with a better = ancestor-score, it should be picked
> > up on the flight by economically competitive miners.
> >
> > A functional test exercising a simple replacement cycling of a HT= LC transaction on bitcoin core
> > mempool is available:
> > https://github.com/ariard/bitco= in/commits/2023-test-mempool
> > <https://github.com/ariard/b= itcoin/commits/2023-test-mempool>
> >
> > ## Deployed LN mitigations
> >
> > Aggressive rebroadcasting: As the replacement cycling attacker be= nefits from the HTLC-timeout being
> > usually broadcast by lightning nodes only once every block, or le= ss the replacement cycling
> > malicious transactions paid only equal the sum of the absolute fe= es paid by the HTLC, adjusted with
> > the replacement penalty. Rebroadcasting randomly and multiple tim= es before the next block increases
> > the absolute fee cost for the attacker.
> >
> > Implemented and deployed by Eclair, Core-Lightning, LND and LDK .=
> >
> > Local-mempool preimage monitoring: As the replacement cycling att= acker in a simple setup broadcast
> > the HTLC-preimage to all the network mempools, the honest lightni= ng node is able to catch on the
> > flight the unconfirmed HTLC-preimage, before its subsequent mempo= ol replacement. The preimage can be
> > extracted from the second-stage HTLC-preimage and used to fetch t= he off-chain inbound HTLC with a
> > cooperative message or go on-chain with it to claim the accepted = HTLC output.
> >
> > Implemented and deployed by Eclair and LND.
> >
> > CLTV Expiry Delta: With every jammed block comes an absolute fee = cost paid by the attacker, a risk
> > of the HTLC-preimage being detected or discovered by the honest l= ightning node, or the HTLC-timeout
> > to slip in a winning block template. Bumping the default CLTV del= ta hardens the odds of success of a
> > simple replacement cycling attack.
> >
> > Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72= .
> >
> > ## Affected Bitcoin Protocols and Applications
> >
> >=C2=A0 From my understanding the following list of Bitcoin protoco= ls and applications could be affected by
> > new denial-of-service vectors under some level of network mempool= s congestion. Neither tests or
> > advanced review of specifications (when available) has been condu= cted for each of them:
> > - on-chain DLCs
> > - coinjoins
> > - payjoins
> > - wallets with time-sensitive paths
> > - peerswap and submarine swaps
> > - batch payouts
> > - transaction "accelerators"
> >
> > Inviting their developers, maintainers and operators to investiga= te how replacement cycling attacks
> > might disrupt their in-mempool chain of transactions, or fee-bump= ing flows at the shortest delay.
> > Simple flows and non-multi-party transactions should not be affec= ted to the best of my understanding.
> >
> > ## Open Problems: Package Malleability
> >
> > Pinning attacks have been known for years as a practical vector t= o compromise lightning channels
> > funds safety, under different scenarios (cf. current bip331's= motivation section). Mitigations at
> > the mempool level have been designed, discussed and are under imp= lementation by the community
> > (ancestor package relay + nverrsion=3D3 policy). Ideally, they sh= ould constraint a pinning attacker to
> > always attach a high feerate package (commitment + CPFP) to repla= ce the honest package, or allow a
> > honest lightning node to overbid a malicious pinning package and = get its time-sensitive transaction
> > optimistically included in the chain.
> >
> > Replacement cycling attack seem to offer a new way to neutralize = the design goals of package relay
> > and its companion nversion=3D3 policy, where an attacker package = RBF a honest package out of the
> > mempool to subsequently double-spend its own high-fee child with = a transaction unrelated to the
> > channel. As the remaining commitment transaction is pre-signed wi= th a minimal relay fee, it can be
> > evicted out of the mempool.
> >
> > A functional test exercising a simple replacement cycling of a li= ghtning channel commitment
> > transaction on top of the nversion=3D3 code branch is available:<= br> > > https://github.com/ariard/= bitcoin/commits/2023-10-test-mempool-2
> > <https://github.com/ari= ard/bitcoin/commits/2023-10-test-mempool-2>
> >
> > ## Discovery
> >
> > In 2018, the issue of static fees for pre-signed lightning transa= ctions is made more widely known,
> > the carve-out exemption in mempool rules to mitigate in-mempool p= ackage limits pinning and the
> > anchor output pattern are proposed.
> >
> > In 2019, bitcoin core 0.19 is released with carve-out support. Co= ntinued discussion of the anchor
> > output pattern as a dynamic fee-bumping method.
> >
> > In 2020, draft of anchor output submitted to the bolts. Initial f= inding of economic pinning against
> > lightning commitment and second-stage HTLC transactions. Subseque= nt discussions of a
> > preimage-overlay network or package-relay as mitigations. Public = call made to inquiry more on
> > potential other transaction-relay jamming attacks affecting light= ning.
> >
> > In 2021, initial work in bitcoin core 22.0 of package acceptance.= Continued discussion of the
> > pinning attacks and shortcomings of current mempool rules during = community-wide online workshops.
> > Later the year, in light of all issues for bitcoin second-layers,= a proposal is made about killing
> > the mempool.
> >
> > In 2022, bip proposed for package relay and new proposed v3 polic= y design proposed for a review and
> > implementation. Mempoolfullrbf is supported in bitcoin core 24.0 = and conceptual questions about
> > alignment of mempool rules w.r.t miners incentives are investigat= ed.
> >
> > Along this year 2022, eltoo lightning channels design are discuss= ed, implemented and reviewed. In
> > this context and after discussions on mempool anti-DoS rules, I d= iscovered this new replacement
> > cycling attack was affecting deployed lightning channels and imme= diately reported the finding to
> > some bitcoin core developers and lightning maintainers.
> >
> > ## Timeline
> >
> > - 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Tow= ns, Greg Sanders and Gloria Zhao
> > - 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien Te= inturier, Matt Corallo and Olaoluwa
> > Osuntunkun
> > - 2022-12-23: Sharing to Eugene Siegel (LND)
> > - 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot (= non-lightning potential affected projects)
> > - 2022-01-14: Sharing to Gleb Naumenko (miners incentives and cro= ss-layers issuers) and initial
> > proposal of an early public disclosure
> > - 2022-01-19: Collection of analysis if other second-layers and m= ulti-party applications affected.
> > LN mitigations development starts.
> > - 2023-05-04: Sharing to Wilmer Paulino (LDK)
> > - 2023-06-20: LN mitigations implemented and progressively releas= ed. Week of the 16 october proposed
> > for full disclosure.
> > - 2023-08-10: CVEs assigned by MITRE
> > - 2023-10-05: Pre-disclosure of LN CVEs numbers and replacement c= ycling attack existence to
> > sec= urity@bitcoincore.org <mailto:security@bitcoincore.org>.
> > - 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2023-40232 = / CVE-2023-40233 / CVE-2023-40234
> > and replacement cycling attacks
> >
> > ## Conclusion
> >
> > Despite the line of mitigations adopted and deployed by current m= ajor lightning implementations, I
> > believe replacement cycling attacks are still practical for advan= ced attackers. Beyond this new
> > attack might come as a way to partially or completely defeat some= of the pinning mitigations which
> > have been working for years as a community.
> >
> > As of today, it is uncertain to me if lightning is not affected b= y a more severe long-term package
> > malleability critical security issue under current consensus rule= s, and if any other time-sensitive
> > multi-party protocol, designed or deployed isn't de facto aff= ected too (loss of funds or denial of
> > service).
> >
> > Assuming analysis on package malleability is correct, it is uncle= ar to me if it can be corrected by
> > changes in replacement / eviction rules or mempool chain of trans= actions processing strategy.
> > Inviting my technical peers and the bitcoin community to look mor= e on this issue, including to
> > dissent. I'll be the first one pleased if I'm fundamental= ly wrong on those issues, or if any element
> > has not been weighted with the adequate technical accuracy it des= erves.
> >
> > Do not trust, verify. All mistakes and opinions are my own.
> >
> > Antoine
> >
> > "meet with Triumph and Disaster. And treat those two imposto= rs just the same" - K.
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundat= ion.org/mailman/listinfo/lightning-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
--000000000000150479060814ffd5--