From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C90A2C0032; Thu, 2 Nov 2023 04:46:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 9E7DC70524; Thu, 2 Nov 2023 04:46:47 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9E7DC70524 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=b+Dtdro/ 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 smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da7ElUzhLfFc; Thu, 2 Nov 2023 04:46:42 +0000 (UTC) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) by smtp3.osuosl.org (Postfix) with ESMTPS id 50EFA70522; Thu, 2 Nov 2023 04:46:42 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 50EFA70522 Received: by mail-io1-xd31.google.com with SMTP id ca18e2360f4ac-7a93df91813so24877039f.2; Wed, 01 Nov 2023 21:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698900401; x=1699505201; 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=OnpujMNOx98zInF+gjd90oe6juO2L3xw1Cg/GLOKpT0=; b=b+Dtdro/W2V6RD9a4xwF9+KuK7lWZCPXFSRVAF7ppH9Bq77Vz1/93YnTqja7gRIpxM 4JHCXLRmU2cMwDO+jKg5Qtbd1N+MWAz/HNq8Td0xoYdWimWvN3LHu9r0p2wB1GHVNfqf CbP6nNrmuy/rRy4VCc/z2hozL+IFL1SXWG+gTS4ZSM2keJzcPDHQMvZl0RE8tZd2z1tz QhSi9gXGd83zbgiCm1ksGfsAYUZmgzIKD/k5uuCCaoJlxd1+K+NUQ+m8sxooPK5XNuEO FSd2kVwxRlSQggb1V4Re2KRW1p1ugW6Snm6CDMjbh2bBZV17kYFfUgY4xUrSu7zeKFSA ufPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698900401; x=1699505201; 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=OnpujMNOx98zInF+gjd90oe6juO2L3xw1Cg/GLOKpT0=; b=Yt/8wvxlT3nGZll20qB2L4WbIr4gGRWIqILqImTgBzLznNnyFpRx3goBtIUo1VZFAA I3ksqRr0UtnDxhsyyMvO8APuOxXN5VM8B8bOX3cR+MUbyObaq8YaLsPQBwHAG18yMXr0 K730uh84q8m7d+D6hDphgqo4OXY4g/GeYvjhx+lwQ6qmCHK7qiW5Jfv91V7f7OovkCT3 KWCCD54i1rkTTN+hun7QPKgiIhsrWVyTmGp0Mkp7EHhbNG2+ipelkKuvXsVJQzxbrcWg /PNnhlclmO+h7cMWjWGIwi1MY3jP1FGevPZN1nEXZl3nAGDUncDVbHMTacMN9hTdPPvf rwvQ== X-Gm-Message-State: AOJu0YwJleHmHJGUglnwZR4oQgmzJNp+SR0Mn3PNXveRGOL5qnOu4BMx lt508s8tEni+vpt3Y5latk1AaTuTCTOTsX/g4LiTFJhaQJqGSQ== X-Google-Smtp-Source: AGHT+IFLgId3YrvcQaCDaH1MmHaaq94fpQlrc3bSmtwuVwmMBI+qBX0eEoXHyrP+AqECY9cuC5ansz/fhLX97ag9Svs= X-Received: by 2002:a05:6602:2f09:b0:795:13ea:477a with SMTP id q9-20020a0566022f0900b0079513ea477amr22843631iow.8.1698900400742; Wed, 01 Nov 2023 21:46:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Thu, 2 Nov 2023 04:46:29 +0000 Message-ID: To: Bitcoin Protocol Discussion , "lightning-dev\\\\@lists.linuxfoundation.org" Content-Type: multipart/alternative; boundary="000000000000e523f7060924125f" X-Mailman-Approved-At: Thu, 02 Nov 2023 11:36:06 +0000 Cc: security@ariard.me Subject: Re: [bitcoin-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, 02 Nov 2023 04:46:47 -0000 --000000000000e523f7060924125f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list, As I received a lot of feedback on the full disclosure of the 16th week of October and the following posts, some accurate, I'm taking time to address a few of them. I think one of the most recurring feedback is the fact that the replacement cycling issue laid out in the initial full disclosure post could have been better explained or presented. Here you have a typical disclosure dilemma encountered by any security researcher, on one hand you wish to explain them as best you can to enlighten the public audience, on the other hand if you come up with a full exploitation rootkit, its manual and a paper with a lot of graphic informing on all the way to exploit, you might expose the public audience funds. As a reminder, at the time of the full disclosure the 16th, some lightning implementations were still adding up mitigations in their codebase and corresponding release has only been tagged last week. Moreover, I think when you're doing a full disclosure as a security researcher, it is wiser to be conservative in the flow of information disclosed, as you might have missed some observations or insights worsening the severity and practicality of exploitation. In my reasonable and modest experience, the amount and clarity of information you're revealing in matters of security disclosure is an art rhythmed by contingencies, not a science. Additionally, there is one "unusual" security risk only affecting Bitcoin second-layers, namely triggering winds of panic among lightning node operators. This group of users started to manually force-close channels and holistically congestion network mempools, opening the door to opportunistic "flood & loot" exploitation, a risk known by lightning experts for years. E.g bare option anchor commitment transactions are 900 WU (bolt3), max block size is 4_000_000 WU, if you have half of the 80k of _public_ channels, you might have a hour and half of full blocks, which might offer the opportunity of stealing payments from payee, based on historical timelocks. This last risk is based on experience from previous security coordination work and I did inform the core security list of this concern in date of the 5 october: " if we see an abnormal rate of network mempools congestion from LN node operators manually force-closing their channels with low-trusted peers, this phenomena has already happened during past Lightning security issues disclosures" as it could have provoked disruptions ecosystem-wide beyond lightning. There have been some voices speaking up on the sudden announcement from my side to step down from lightning development. While there has been complete distorsion of my statement by non-specialized journalists and I've been the first one to complain, howev er it was very deliberate on my side to ring the bell on the very poor state of lightning security and marked the score than this new replacement cycling issue is a far more concerning than other major security risks of lightning known so far. As a friendly reminder, we start to pile up a very serious stack of security risks: pinnings, channel jamming, replacement cycling, time dilation (all those ones could kill lightning if exploited at scale - period) and more minor ones such as dust HTLC exposure, fee or liquidity griefing and other denial-of-service. Hard things about hard things, every new major security risk discovered somehow constrains lightning developers to go back on the whiteboard and check that any mitigation in development for each risk is not broken or the security properties with. Most of the time, we might think in isolation to ease the mitigation of research and development work. Astute adversaries might not give us those flowers. At the end, technical reality advises that lightning security issues are better solved at the base-layer, and this is where expert time is cruelly missing to make lightning more robust on the very long-term. On a more ethical plan, there is no wish on my side to stay accountable on the coordinated handling of security issues in the lightning ecosystem, when I have the inner conviction than replacement cycling issues are practical and critical, that they cannot be solved correctly on the lightning-side, that any serious mitigation on the base-layer might take numerous years and their integration back in the lightning-side might take another couple of years. Once again, I warned the whole community of the nest of issues at the mempool-level for lightning very consistently during the past years. With humility, if those replacement cycling attacks start to be played out at scale by sophisticated attackers during the coming future, I'm not competent to improvise an effective mitigation. And even less competent to coordinate dissemination of such eventual patch of mitigations across an ecosystem of nodes, without losing inter-compatibility between implementations, wallets and releases versions (and here the lack of standardized mechanism like dynamic upgrade bolt pr #1090 is a missing safety feature). Security of critical software systems is somehow akin to medical practice. If you wish to nurture an adequate clinical treatment, you have to get the diagnosis of the illness severity first, even if it's a painful truth for the patient. In my opinion, here the patient is the community of lightning node operators and lightning users, and if we wish for an adequate technical treatment to overcome the vulnerability severity, building consensus on the severity sounds a necessary step. As of today, I think the criticality of this replacement cycling attack is still misappreciated by other bitcoin devs, including lightning experts. I have not seen so far discussion of the issue entitled "package malleability" and the corresponding test on bitcoin core mempool, adapting the replacement cycling scenario to a post-package relay world. If I'm correct here though welcoming more expert eyes with pleasure here, dynamic fee-bumping of pre-signed lightning states as we have been working from years can be broken by replacement cycling attacks, extending the types of lightning nodes at risk from forwarding nodes to just any lightning node (and in the lack of dynamic fee-bumping pre-signed states might not propagate to miners template due to the dynamic mempool min fee). Finally, running a piece of software is a matter of an individual or business decision. While one can as a technical "domain expert" explain the risk model with the utmost care and diligence, at the end of the day the decision belongs to everyone on what to do with their own computing infrastructure and stack of satoshis. Yet if you're servicing customers or users with your infrastructure, please be mindful of the safety of their funds and take time to understand how your technical decisions might affect them. Their risk tolerance is very likely not yours [0]. All that said, after months of working on those issues under embargo, I find it pleasant to see the bitcoin technical community and beyond actually talking about those issues at length with a "don't trust, verify" mindset. I'll take time to answer the public mails on those subjects during the coming weeks and months. I'm still enthusiastic to do a real-world demonstration of a replacement cycling attack on mainnet though I won't have time until the second semester of 2024 at the very best (I'm still late on my announcement of 2020 to do a real-world demonstration of pinning attacks - I'm learning to be very conservative with my public open-source commitment now). Assuming a timeline of a decade or two, I'm still optimistic on seeing one day a lightning ecosystem looking like the p2p cypherpunk version as fleshed out in the original paper. Cheers, Antoine [0] "Chancellor on the brink of second bailout of banks" - I think the 2008 crisis and its massive bailout of big financial players by the small guy money worldwide is a good meditation. Hopefully, we're not building a new financial system where the big bitcoin and lightning players are concealing massive security risks from the average end-user, and in the occurrence of the risks flagrant realization will deny any form of accountability by walls of PR statements. Le sam. 21 oct. 2023 =C3=A0 21:05, Antoine Riard = a =C3=A9crit : > Hi, > > As I've been shown offline Twitter posts misrepresenting my previous mail= , > I think it's good to correct them. The security flaws are not "intentiona= l > backdoor" or whatever misrepresentation that would question the competenc= e > and know-how of the Bitcoin and Lightning development community. > > The replacement cycling issue discovered has been known by a small circle > of Bitcoin developers since December 2022. As it appears to some experts > and it has been commented publicly, changes at the bitcoin base-layer mig= ht > be the most substantial fixes. Those changes take time and here this is > akin to how the linux kernel, bsds and OS vendors are working [0]. > > All I can say is that we had recently had internal discussion on how to > improve coordinated security fixes and patching processes for the coming > decades. This is an area of concern where I've always been at the forefro= nt > as early as 2020 / 2021 [1]. > > In the meanwhile, lightning experts have already deployed mitigations > which are hardening the lightning ecosystem significantly in face of simp= le > or medium attacks. More advanced attacks can only be mounted if you have > sufficient p2p and mempool knowledge as was pointed out by other bitcoin > experts like Matt or Peter (which take years to acquire for average bitco= in > developers) and the months of preparation to attempt them. > > If you're a journalist reporting on the information in mainstream crypto > publications, I'll suggest waiting to do so before expert reporters of > bitcoin circles who have more in-field knowledge can do so and qualify th= e > technical situation with more distance. As I've already been interviewed = by > top financial publication years ago for my work on bitcoin, as a journali= st > you're engaging your own reputation on the information you're reporting. > Thanks for being responsible here. > > This is the nature of the electronic communication and contemporaneous > media that information is extremely fluid and there is no native anti-DoS > mechanism to slow down the propagation of sensitive information where > mitigations are still in deployment. A reason I'm not on social media of > any kind [2]. In the meanwhile, it's good to go to read senecca and marcu= s > aurelius take the situation with stoicism and with a zelt of meditation [= 3]. > > All my previous statements are mostly technically correct (even if some > could have been written with more clarity once again I'm not an english > native [4]). While I wish to wait the week of the 30th Oct o discuss > further what is best fix and what are the trade-offs as a community as a > wide (give time some laggard lightning implementations ship fixes), thoug= h > I'll comment further on the mailing list if the flow of information on > "social media" is DoSing the ability of the bitcoin community to work on > the long-term appropriate fixes in a responsible and constructive fashion= . > > [0] See meltdown class of vulnerability and how operating systems are > handling hardware-sourced vulnerabilities > https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability). Most of > the time they do their best on the software side and they go to see with > hardware vendors how to do the necessary updates. > > [1] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/0030= 02.html > > [2] And for the wider analysis on contemporaneous culture of information > propagation and network effect, I can only recommend to read venkatesh > rao's ribbonfarm essays http://ribbonfarm.com > > [3] There are very good reasons why some executives at top modern > technology companies are doing meditation daily, some even hours. "mind > illuminated" is a good read. > > [4] While my former employer, Chaincode Labs, paid for my english lessons > back in 2020. Generally it was a good insight from them to train people o= n > how to communicate in a crisis. > > > Le ven. 20 oct. 2023 =C3=A0 07:56, Antoine Riard a > =C3=A9crit : > >> Hi, >> >> After writing the mail reply on the economics of sequential malicious >> replacement of honest HTLC-timeout, I did write one more test to verify = the >> behavior on core mempool, and it works as expected. >> >> >> https://github.com/ariard/bitcoin/commit/30f5d5b270e4ff195e8dcb9ef6b7ddc= c5f6a1bf2 >> >> Responsible disclosure process has followed the lines of hardware issues >> affecting operating system, as documented for the Linux kernel, while >> adapted to the bitcoin ecosystem: >> >> https://docs.kernel.org/6.1/process/embargoed-hardware-issues.html >> >> Effective now, I'm halting my involvement with the development of the >> lightning network and its implementations, including coordinating the >> handling of security issues at the protocol level (I informed some senio= r >> lightning devs in that sense before). >> >> Closed the very old issue which was affected to me at this purpose on th= e >> bolt repository: >> >> https://github.com/lightning/bolts/pull/772 >> >> I think this new class of replacement cycling attacks puts lightning in = a >> very perilous position, where only a sustainable fix can happen at the >> base-layer, e.g adding a memory-intensive history of all-seen transactio= ns >> or some consensus upgrade. Deployed mitigations are worth something in f= ace >> of simple attacks, though I don't think they're stopping advanced attack= ers >> as said in the first full disclosure mail. >> >> Those types of changes are the ones necessitating the utmost transparenc= y >> and buy-in of the community as a whole, as we're altering the full-nodes >> processing requirements or the security architecture of the decentralize= d >> bitcoin ecosystem in its integrality. >> >> On the other hand fully explaining why such changes would be warranted >> for the sake of lightning and for designing them well, we might need to = lay >> out in complete state practical and critical attacks on a ~5 355 public = BTC >> ecosystem. >> >> Hard dilemma. >> >> There might be a lesson in terms of bitcoin protocol deployment, we migh= t >> have to get them right at first try. Little second chance to fix them in >> flight. >> >> I'll be silent on those issues on public mailing lists until the week of >> the 30 oct. Enough material has been published and other experts are >> available. Then I'll be back focusing more on bitcoin core. >> >> Best, >> Antoine >> >> Le lun. 16 oct. 2023 =C3=A0 17:57, Antoine Riard a >> =C3=A9crit : >> >>> (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 chann= els >>> was discovered. >>> >>> After careful analysis, it turns out this attack is practical and >>> immediately exposed lightning routing hops carrying HTLC traffic to los= s of >>> funds security risks, both legacy and anchor output channels. A potenti= al >>> exploitation plausibly happening even without network mempools congesti= on. >>> >>> 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 should >>> 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 reporte= d >>> in the wild since the last ~10 months or experimented in real-world >>> conditions on bitcoin mainet, functional test is available exercising t= he >>> affected lightning channel against bitcoin core mempool (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 po= wer) >>> and only access to basic bitcoin and lightning software. Yet I still th= ink >>> 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 th= e >>> 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 privileg= ed >>> 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 t= he >>> 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-pap= er/replacement-cycling.pdf >>> >>> ## 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 with either a success or timeout before the incoming sta= te >>> 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 prope= rty). >>> >>> 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 inco= ming >>> 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, this exact interval value being an implementation = and >>> node policy setting. As a minimal value, the specification recommends 3= 4 >>> 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 blocks from chain tip, giving a reasonable buffer o= f >>> 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`) when 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 he= ight >>> 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 vic= tim >>> lightning node and triggers a replacement. Both for legacy and anchor >>> output channels, a HTLC-preimage on a counterparty commitment transacti= on >>> 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), p= ays >>> 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 tha= n >>> 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 parent >>> 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 expirati= on >>> of the inbound HTLC timelock I. Once this height is reached a HTLC-time= out >>> is broadcast by the counterparty's on the incoming link in collusion wi= th >>> the one on the outgoing link broadcasting its own HTLC-preimage. >>> >>> The honest Lightning node has been "double-spent" in its HTLC forwardin= g. >>> >>> 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 t= he >>> miner winning the block race and therefore realizes a spent of the offe= red >>> output. In practice, a replacement cycling attack might over-connect to >>> miners' mempools and public reachable nodes to succeed in a fast evicti= on >>> of the HTLC-timeout by its HTLC-preimage. As this latter transaction ca= n >>> 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 o= nce >>> every block, or less the replacement cycling malicious transactions pai= d >>> 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 attacker >>> in a simple setup broadcast the HTLC-preimage to all the network mempoo= ls, >>> the honest lightning node is able to catch on the flight the unconfirme= d >>> 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 i= t 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 s= ome >>> 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, wh= ere an >>> attacker package RBF a honest package out of the mempool to subsequentl= y >>> 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 lightnin= g >>> channel commitment transaction on top of the nversion=3D3 code branch i= s >>> 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 patter= n >>> are proposed. >>> >>> In 2019, bitcoin core 0.19 is released with carve-out support. Continue= d >>> 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 poten= tial >>> 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, i= n >>> 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 memp= ool >>> anti-DoS rules, I discovered this new replacement cycling attack was >>> affecting deployed lightning channels and immediately reported the find= ing >>> 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 disclosur= e >>> - 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 st= ill >>> practical for advanced attackers. Beyond this new attack might come as = a >>> way to partially or completely defeat some of the pinning mitigations w= hich >>> 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 unde= r >>> current consensus rules, and if any other time-sensitive multi-party >>> protocol, designed or deployed isn't de facto affected too (loss of fun= ds >>> or denial of service). >>> >>> Assuming analysis on package malleability is correct, it is unclear to >>> me if it can be corrected by changes in replacement / eviction rules or >>> mempool chain of transactions processing strategy. Inviting my technica= l >>> peers and the bitcoin community to look more on this issue, including t= o >>> dissent. I'll be the first one pleased if I'm fundamentally wrong on th= ose >>> issues, or if any element has not been weighted with the adequate techn= ical >>> accuracy it deserves. >>> >>> 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. >>> >> --000000000000e523f7060924125f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi list,

As I received a lot of feedbac= k on the full disclosure of the 16th week of October and the following post= s, some accurate, I'm taking time to address a few of them.
<= br>
I think one of the most recurring feedback is the fact that t= he replacement cycling issue laid out in the initial full disclosure post c= ould have been better explained=C2=A0or presented. Here you have a typical = disclosure dilemma encountered by any security researcher, on one hand you = wish to explain them as best you can to enlighten the public audience, on t= he other hand if you come up with a full exploitation rootkit, its manual a= nd a paper with a lot of graphic informing on all the way to exploit, you m= ight expose the public audience funds.

As a remind= er, at the time of the full disclosure the 16th, some lightning implementat= ions were still adding up mitigations in their codebase and corresponding r= elease has only been tagged last week. Moreover, I think when you're do= ing a full disclosure as a security researcher, it is wiser to be conservat= ive in the flow of information disclosed, as you might have missed some obs= ervations or insights worsening the severity and practicality of exploitati= on.

In my reasonable and modest experience, the am= ount and clarity of information you're revealing in matters of security= disclosure is an art rhythmed by contingencies, not a science.
<= br>
Additionally, there is one "unusual" security risk = only affecting Bitcoin second-layers, namely triggering winds of panic amon= g lightning node operators. This group of users started to manually force-c= lose channels and holistically congestion network mempools, opening the doo= r to opportunistic "flood & loot" exploitation, a risk known = by lightning experts for years.

E.g bare option an= chor commitment transactions are 900 WU (bolt3), max block size is 4_000_00= 0 WU, if you have half of the 80k of _public_ channels, you might have a ho= ur and half of full blocks, which might offer the opportunity of stealing p= ayments from payee, based on historical timelocks.

This last risk is based on experience from previous security coordination = work and I did inform the core security list of this concern in date of the= 5 october: "=C2=A0= if we see an abnormal rate of network mempools congestion from LN node oper= ators manually force-closing their channels with low-trusted peers, this ph= enomena has already happened during past Lightning security issues disclosu= res" as it could have provoked disruptions ecosystem-wide beyond light= ning.

There have been some voices speaking up on t= he sudden announcement from my side to step down from lightning development= . While there has been complete distorsion of my statement by non-specializ= ed journalists and I've been the first one to complain, howev er it was= very deliberate on my side to ring the bell on the very poor state of ligh= tning security and marked the score than this new replacement cycling issue= is a far more concerning than other major security risks of lightning know= n so far. As a friendly reminder, we start to pile up a very serious stack = of security risks: pinnings, channel jamming, replacement cycling, time dil= ation (all those ones could kill lightning if exploited at scale - period) = and more minor ones such as dust HTLC exposure, fee or liquidity griefing a= nd other denial-of-service.

Hard things about hard= things, every new major security risk discovered somehow constrains lightn= ing developers to go back on the whiteboard and check that any mitigation i= n development for each risk is not broken or the security properties with. = Most of the time, we might think in isolation to ease the mitigation of res= earch and development work. Astute adversaries might not give us those flow= ers. At the end, technical reality advises that lightning security issues a= re better solved at the base-layer, and this is where expert time is cruell= y missing to make lightning more robust on the very long-term.
On a more ethical plan, there is no wish on my side to stay ac= countable on the coordinated handling of security issues in the lightning e= cosystem, when I have the inner conviction than replacement cycling issues = are practical and critical, that they cannot be solved correctly on the lig= htning-side, that any serious mitigation on the base-layer might take numer= ous years and their integration back in the lightning-side might take anoth= er couple of years. Once again, I warned the whole community of the nest of= issues at the mempool-level for lightning very consistently during the pas= t years.

With humility, if those replacement cycli= ng attacks start to be played out at scale by sophisticated attackers durin= g the coming future, I'm not competent to improvise an effective mitiga= tion. And even less competent to coordinate dissemination of such eventual = patch of mitigations across an ecosystem of nodes, without losing inter-com= patibility between implementations, wallets and releases versions (and here= the lack of standardized mechanism like dynamic upgrade bolt pr #1090 is a= missing safety feature).

Security of critical sof= tware systems is somehow akin to medical practice. If you wish to nurture a= n adequate clinical treatment, you have to get the diagnosis of the illness= severity first, even if it's a painful truth for the patient. In my op= inion, here the patient is the community of lightning node operators and li= ghtning users, and if we wish for an adequate technical treatment to overco= me the vulnerability severity, building consensus on the severity sounds a = necessary step.

As of today, I think the criticali= ty of this replacement cycling attack is still misappreciated by other bitc= oin devs, including lightning experts. I have not seen so far discussion of= the issue entitled "package malleability" and the corresponding = test on bitcoin core mempool, adapting the replacement cycling scenario to = a post-package relay world. If I'm correct here though welcoming more e= xpert eyes with pleasure here, dynamic fee-bumping of pre-signed lightning = states as we have been working from years can be broken by replacement cycl= ing attacks, extending the types of lightning nodes at risk from forwarding= nodes to just any lightning node (and in the lack of dynamic fee-bumping p= re-signed states might not propagate to miners template due to the dynamic = mempool min fee).

Finally, running a piece of soft= ware is a matter of an individual or business decision. While one can as a = technical "domain expert" explain the risk model with the utmost = care and diligence, at the end of the day the decision belongs to everyone = on what to do with their own computing infrastructure and stack of satoshis= . Yet if you're servicing customers or users with your infrastructure, = please be mindful of the safety of their funds and take time to understand = how your technical decisions might affect them. Their risk tolerance is ver= y likely not yours [0].

All that said, after month= s of working on those issues under embargo, I find it pleasant to see the b= itcoin technical community and beyond actually talking about those issues a= t length with a "don't trust, verify" mindset. I'll take = time to answer the public mails on those subjects during the coming weeks a= nd months. I'm still enthusiastic to do a real-world demonstration of a= replacement cycling attack on mainnet though I won't have time until t= he second semester of 2024 at the very best (I'm still late on my annou= ncement of 2020 to do a real-world demonstration of pinning attacks - I'= ;m learning to be very conservative with my public open-source commitment n= ow). Assuming a timeline of a decade or two, I'm still optimistic on se= eing one day a lightning ecosystem looking like the p2p cypherpunk version = as fleshed out in the original paper.

Cheers,
Antoine

[0] "Chancellor on the brink of= second bailout of banks" - I think the 2008 crisis and its massive ba= ilout of big financial players by the small guy money worldwide is a good m= editation. Hopefully, we're not building a new financial system where t= he big bitcoin and lightning players are concealing massive security risks = from the average end-user, and in the occurrence of the risks flagrant real= ization will deny any form of accountability by walls of PR statements.

Le=C2=A0sam. 21 oct. 2023 =C3=A0=C2=A021:05, Antoine Riard <antoine.riard@gmail.com> a =C3=A9cr= it=C2=A0:
Hi,

As I've been shown offline Twitter posts misrepresenting my previous m= ail, I think it's good to correct them. The security flaws are not &quo= t;intentional backdoor" or whatever misrepresentation that would quest= ion the competence and know-how of the Bitcoin and Lightning development co= mmunity.

The replacement cycling issue discovered = has been known by a small circle of Bitcoin developers since December 2022.= As it appears to some experts and it has been commented publicly, changes = at the bitcoin base-layer might be the most substantial fixes. Those change= s take time and here this is akin to how the linux kernel, bsds and OS vend= ors are working [0].

All I can say is that we had = recently had internal discussion on how to improve coordinated security fix= es and patching processes for the coming decades. This is an area of concer= n where I've always been at the forefront as early as 2020 / 2021 [1].<= /div>

In the meanwhile, lightning experts have already= =C2=A0deployed mitigations which are hardening the lightning ecosystem sign= ificantly in face of simple or medium attacks. More advanced attacks can on= ly be mounted if you have sufficient p2p and mempool knowledge as was point= ed out by other bitcoin experts like Matt or Peter (which take years to acq= uire for average bitcoin developers) and the months of preparation to attem= pt them.

If you're a journalist reporting on t= he information in mainstream crypto publications, I'll suggest waiting = to do so before expert reporters of bitcoin circles who have more in-field = knowledge can do so and qualify the technical situation with more distance.= As I've already been interviewed by top financial publication years ag= o for my work on bitcoin, as a journalist you're engaging your own repu= tation on the information you're reporting. Thanks for being responsibl= e here.

This is the nature of the electronic commu= nication and contemporaneous media that information is extremely fluid and = there is no native anti-DoS mechanism to slow down the propagation of sensi= tive information where mitigations are still in deployment. A reason I'= m not on social media of any kind [2]. In the meanwhile, it's good to g= o to read senecca and marcus aurelius take the situation with stoicism and = with a zelt of meditation [3].

All my previous sta= tements are mostly technically correct (even if some could have been writte= n with more clarity once again I'm not an english native [4]). While I = wish to wait the week of the 30th Oct o discuss further what is best fix an= d what are the trade-offs as a community as a wide (give time some laggard = lightning implementations ship fixes), though I'll comment further on t= he mailing list if the flow of information on "social media" is D= oSing the ability of the bitcoin community to work on the long-term appropr= iate fixes in a responsible and constructive fashion.

<= div>[0] See meltdown class of vulnerability and how operating systems are h= andling hardware-sourced vulnerabilities=C2=A0https://en= .wikipedia.org/wiki/Meltdown_(security_vulnerability). Most of the time= they do their best on the software side and they go to see with hardware v= endors how to do the necessary updates.

[1]=C2=A0<= a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-Ap= ril/003002.html" target=3D"_blank">https://lists.linuxfoundation.org/piperm= ail/lightning-dev/2021-April/003002.html

[2] A= nd for the wider analysis on contemporaneous culture of information propaga= tion and network effect, I can only recommend to read venkatesh rao's r= ibbonfarm essays http:/= /ribbonfarm.com

[3] There are very good reason= s why some executives at top modern technology companies are doing meditati= on daily, some even hours. "mind illuminated" is a good read.

[4] While my former employer, Chaincode Labs, paid fo= r my english lessons back in 2020. Generally it was a good insight from the= m to train people on how to communicate in a crisis.
=C2=A0
=

= Le=C2=A0ven. 20 oct. 2023 =C3=A0=C2=A007:56, Antoine Riard <antoine.riard@gmail.com> a =C3=A9crit=C2=A0:


Responsible disclosure process has followed the lines of = hardware issues affecting operating system, as documented for the Linux ker= nel, while adapted to the bitcoin ecosystem:


Effective now, I'm halting my= involvement with the development of the lightning=C2=A0network and its imp= lementations, including coordinating the handling of security=C2=A0issues a= t the protocol=C2=A0level (I informed some senior lightning devs in that se= nse before).

Closed the very old issue which was a= ffected to me at this purpose on the bolt repository:

<= div>https://github.com/lightning/bolts/pull/772

=
I think this new class of replacement cycling attacks puts lightning i= n a very perilous position, where only a sustainable fix can happen at the = base-layer, e.g adding a memory-intensive history of all-seen transactions = or some consensus upgrade. Deployed mitigations are worth something in face= of simple attacks, though I don't think they're stopping advanced = attackers as said in the first full disclosure mail.

Those types of changes are the ones necessitating the utmost transparenc= y and buy-in of the community as a whole, as we're altering the full-no= des processing requirements or the security architecture of the decentraliz= ed bitcoin ecosystem in its integrality.

On the ot= her hand fully explaining why such changes would be warranted for the sake = of lightning and for designing them well, we might need to lay out in compl= ete state practical and critical attacks on a ~5 355 public BTC ecosystem.<= /div>

Hard dilemma.

There might= be a lesson in terms of bitcoin protocol deployment, we might have to get = them right at first try. Little second chance to fix them in flight.
<= div>
I'll be silent on those issues on public mailing lis= ts until the week of the 30 oct. Enough material has been published and oth= er experts are available. Then I'll be back focusing more on bitcoin co= re.

Best,
Antoine

Le=C2=A0lun. 16 o= ct. 2023 =C3=A0=C2=A017:57, Antoine Riard <antoine.riard@gmail.com> a =C3=A9cri= t=C2=A0:
(cross-posting mem= pool 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 discussi= ons on eltoo payment channels and incentives compatibility of the mempool a= nti-DoS rules, a new transaction-relay jamming attack affecting lightning c= hannels was discovered.

After careful analysis, it= turns out this attack is practical and immediately=C2=A0exposed lightning = routing hops carrying HTLC traffic to loss of funds security risks, both le= gacy and anchor=C2=A0output channels. A potential exploitation plausibly ha= ppening even without network mempools congestion.

= Mitigations have been designed, implemented and deployed by all major light= ning implementations during the last months.

Pleas= e find attached the release numbers, where the mitigations should be presen= t:
- 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 lightn= ing channel against bitcoin core mempool (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 p= ower) and only access to basic bitcoin and lightning software. Yet I still = think executing such an attack successfully requests a fair amount of bitco= in technical know-how and decent preparation.

From= my understanding of those issues, it is yet to be determined if the mitiga= tions deployed are robust enough in face of advanced replacement cycling at= tackers, especially ones able to combine different classes of transaction-r= elay jamming such as pinnings or vetted with more privileged capabilities.<= /div>

Please find a list of potential affected bitcoin a= pplications in this full disclosure report using bitcoin script timelocks o= r multi-party transactions, albeit no immediate security risk exposure as s= evere as the ones affecting lightning has been identified. Only cursory rev= iew of non-lightning applications has been conducted so far.

=
There is a paper published summarizing replacement cycling attac= ks on the lightning network:

=C2=A0= ## Problem

A lightning node allows HTLCs forwardin= g (in bolt3's parlance accepted 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 Systemat= ic Attack on The Lightning Network" section 2.3 for a classical exposi= tion 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 counterpa= rty's HTLC-preimage and the accepted HTLC is spent by the incoming link= counterparty's HTLC-timeout.

The specificatio= n mandates the incoming HTLC expiration timelock to be spaced out by an int= erval of `cltv_expiry_delta` from the outgoing HTLC expiration timelock, th= is exact interval value being an implementation and node policy setting. As= a minimal value, the specification recommends 34 blocks of interval. If th= e 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 blocks = from chain tip, giving a reasonable buffer of reaction to the lightning for= warding node.

In the lack of cooperative off-chain= settlement of the HTLC on the outgoing link negotiated with the counterpar= ty (either `update_fulfill_htlc` or `update_fail_htlc`) when O is reached, = the lightning node should broadcast its commitment transaction. Once the co= mmitment 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 transacti= on with a higher absolute fee and higher feerate than the honest HTLC-timeo= ut of the victim lightning node and triggers a replacement. Both for legacy= and anchor output channels, a HTLC-preimage on a counterparty commitment t= ransaction is malleable, i.e additional inputs or outputs can be added. The= HTLC-preimage spends an unconfirmed and unrelated to the channel parent tr= ansaction M and conflicts its child.

As the HTLC-p= reimage spends an unconfirmed input that was already included in the unconf= irmed 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 tr= ansactions (rule 6), the replacement is accepted. The honest HTLC-timeout i= s evicted out of the mempool.

In an ulterior move,= the malicious counterparty can replace the parent transaction itself with = another candidate N satisfying the replacement rules, triggering the evicti= on of the malicious HTLC-preimage from the mempool as it was a child of the= parent T.

There is no spending candidate of the o= ffered HTLC output for the current block laying in network mempools.
<= div>
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 H= TLC-timeout is broadcast by the counterparty's on the incoming link in = collusion with the one on the outgoing link broadcasting its own HTLC-preim= age.

The honest Lightning node has been "doub= le-spent" in its HTLC forwarding.

As a notabl= e 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 block race and therefore realizes a spent of the offered output. In pra= ctice, a replacement cycling attack might over-connect to miners' mempo= ols and public reachable nodes to succeed in a fast eviction of the HTLC-ti= meout by its HTLC-preimage. As this latter transaction can come with a bett= er ancestor-score, it should be picked up on the flight by economically com= petitive miners.

A functional test exercising a si= mple replacement cycling of a HTLC transaction on bitcoin core mempool is a= vailable:

## Deployed LN mitigat= ions

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 mal= icious transactions paid only equal the sum of the absolute fees paid by th= e HTLC, adjusted with the replacement penalty. Rebroadcasting randomly and = multiple times before the next block increases the absolute fee cost for th= e attacker.

Implemented and deployed by Eclair, Co= re-Lightning, LND and LDK .

Local-mempool preimage= monitoring: As the replacement cycling attacker in a simple setup broadcas= t 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 su= bsequent mempool replacement. The preimage can be extracted from the second= -stage HTLC-preimage and used to fetch the off-chain inbound HTLC with a co= operative 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 t= he 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 vecto= rs under some level of network mempools congestion. Neither tests or advanc= ed review of specifications (when available) has been conducted for each of= them:
- on-chain DLCs
- coinjoins
- payjoins=
- wallets with time-sensitive paths
- peerswap and sub= marine swaps
- batch payouts
- transaction "accele= rators"

Inviting their developers, maintainer= s and operators to investigate how replacement cycling attacks might disrup= t their in-mempool chain of transactions, or fee-bumping flows at the short= est delay. Simple flows and non-multi-party transactions should not be affe= cted to the best of my understanding.

## Open Prob= lems: Package Malleability

Pinning attacks have be= en known for years as a practical vector to compromise lightning channels f= unds safety, under different scenarios (cf. current bip331's motivation= section). Mitigations at the mempool level have been designed, discussed a= nd are under implementation by the community (ancestor package relay=C2=A0+= nverrsion=3D3 policy). Ideally, they should constraint a pinning attacker = to always attach a high feerate package (commitment=C2=A0+ CPFP) to replace= the honest package, or allow a honest lightning node to overbid a maliciou= s pinning package and get its time-sensitive transaction optimistically inc= luded in the chain.

Replacement cycling attack see= m to offer a new way to neutralize the design goals of package relay and it= s companion nversion=3D3 policy, where an attacker package RBF a honest pac= kage out of the mempool to subsequently double-spend its own high-fee child= with a transaction unrelated to the channel. As the remaining commitment t= ransaction is pre-signed with a minimal relay fee, it can be evicted out of= the mempool.

A functional test exercising a simpl= e 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 wid= ely 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 supp= ort. Continued discussion of the anchor output pattern as a dynamic fee-bum= ping method.

In 2020, draft of anchor output submi= tted to the bolts. Initial finding of economic pinning against lightning co= mmitment and second-stage HTLC transactions. Subsequent discussions of a pr= eimage-overlay network or package-relay as mitigations. Public call made to= inquiry more on potential other transaction-relay jamming attacks affectin= g lightning.

In 2021, initial work in bitcoin core= 22.0 of package acceptance. Continued discussion of the pinning attacks an= d shortcomings of current mempool rules during community-wide online worksh= ops. Later the year, in light of all issues for bitcoin second-layers, a pr= oposal 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 cor= e 24.0 and conceptual questions about alignment of mempool rules w.r.t mine= rs incentives are investigated.

Along this year 20= 22, eltoo lightning channels design are discussed, implemented and reviewed= . In this context and after discussions on mempool anti-DoS rules, I discov= ered this new replacement cycling attack was affecting deployed lightning c= hannels and immediately reported the finding to some bitcoin core developer= s and lightning maintainers.

## Timeline

- 2022-12-16: Report of the finding to Suhas Daftuar, Antho= ny 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-light= ning potential affected projects)
- 2022-01-14: Sharing to Gleb N= aumenko (miners incentives and cross-layers issuers) and initial proposal o= f an early public disclosure=C2=A0
- 2022-01-19: Collection of an= alysis if other second-layers and multi-party applications affected. LN mit= igations development starts.
- 2023-05-04: Sharing to Wilmer Paul= ino (LDK)
- 2023-06-20: LN mitigations implemented and progressiv= ely released. Week of the 16 october proposed for full disclosure.
- 2023-08-10: CVEs assigned by MITRE
- 2023-10-05: Pre-disclosu= re of LN CVEs numbers and replacement cycling attack existence to security@bitcoincore= .org.
- 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2= 023-40232 / CVE-2023-40233 / CVE-2023-40234 and replacement cycling attacks=

## Conclusion=C2=A0

Desp= ite 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 part= ially 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 too (loss of funds or denial of service).

Assuming analysis on package malleability is correct, = it is unclear to me if it can be corrected by changes in replacement / evic= tion rules or mempool chain of transactions processing strategy. Inviting m= y technical peers and the bitcoin community to look more on this issue, inc= luding 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 deserves.

Do not tr= ust, verify. All mistakes and opinions are my own.

Antoine

"meet with Triumph and Disaster. And= treat those two impostors just the same" - K.
--000000000000e523f7060924125f--