path: root/9c/23eb77dd8fb147d5a6ce2fa81b1d37fb5975b1

Return-Path: <nadav@shesek.info>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5C2B7C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 22 Oct 2023 04:49:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 370EB85224
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 22 Oct 2023 04:49:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 370EB85224
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=shesek.info header.i=@shesek.info
 header.a=rsa-sha256 header.s=google header.b=sazDLCMW
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, 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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id BTN3MF7j7DYI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 22 Oct 2023 04:49:33 +0000 (UTC)
Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com
 [IPv6:2001:4860:4864:20::2b])
 by smtp1.osuosl.org (Postfix) with ESMTPS id B871E81A3B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 22 Oct 2023 04:49:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org B871E81A3B
Received: by mail-oa1-x2b.google.com with SMTP id
 586e51a60fabf-1dd71c0a41fso1699535fac.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Oct 2023 21:49:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=shesek.info; s=google; t=1697950171; x=1698554971;
 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=Tq5N6teuJeQx+JmZYLSA3lvzJlZH/7zLj1NnInIkWy0=;
 b=sazDLCMWW8GZvCefFx4KVTljUT9KmZTIX8me2Tey6UNPddMzN6ywlJJomNVFqEUS9D
 lWveXz3cypjAu0MHNN819rQyI2D6BRvgRP4F88my7NRajSj8pLJl5O9MQjFgccCZHB/X
 6puEP8favy2vy6oSuxfYxUG1pRFkjimlwwyr5CXdGbJ2SUmafyG4Hd9oysOqW30dShcd
 aqvF9U+WbWgKXTMZhuJqJAOr9QDLFSBgyxmAzCsWcgyEaCq4rzwp2T5fnwjzbWyDjT+M
 Z66hAjkwcAqowMB9pI33mUn+7wNJUl/3xp0QQuTQoFmDKLW1zUoQL3Py5BlDD3t+QXAa
 exJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1697950171; x=1698554971;
 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=Tq5N6teuJeQx+JmZYLSA3lvzJlZH/7zLj1NnInIkWy0=;
 b=wKZ/3XMLvm40/sj9SjilaW2tEQOLnNkglg5tdhoUdCA0Ypm1Wtj9P9oHKi3OLYZGIW
 pN+blYY/nXRVh0+m2no5Wi+9xE+W6hQyYzgn5WwE4XbBuGRiFFnWwS/qNeL9Awe3UeLp
 veGSJFTVrX9ePaBAbFdnK377ABRXVvSaozEwmZMmp4f5b3Rndb80RmdJ3qj8Z00ZTykt
 WnrHXuQteGcgqNHwlogQH9dvd2F2JQXxCJYJBiN5izbe46DaLZh466Ar8sThGqXiNvmz
 vaNIfTsNWnU1t8gCzr9FwnSypyZFRvgvnJwOL+YbiNDAhsyBmsTKIXm02ukTbais3tmn
 dzvg==
X-Gm-Message-State: AOJu0YwRu4PH997Uy62p3h3mUuLd9OyC/61Qm52GH5u0GeTGIgjJIeGL
 xjRB490LS8o033jy2Q0EN53mAKBSw2WXrEzZirjMdw==
X-Google-Smtp-Source: AGHT+IHYolqHT/D21yetmZJcFJlFt/j3kHr8GRgS6/K60TA0jcz3X0XDo77xVlOAmuOMGlPsLZRfdhiYqjwFr5q5n9A=
X-Received: by 2002:a05:6870:2e07:b0:1e9:9833:daad with SMTP id
 oi7-20020a0568702e0700b001e99833daadmr8153645oab.4.1697950171237; Sat, 21 Oct
 2023 21:49:31 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
In-Reply-To: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
From: Nadav Ivgi <nadav@shesek.info>
Date: Sun, 22 Oct 2023 07:49:19 +0300
Message-ID: <CAGXD5f2S4-Om7pkaUR+H6OiiyZ2F_AEWsohu8uJMvR7_+wwQkw@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cda0c1060846d495"
X-Mailman-Approved-At: Sun, 22 Oct 2023 09:07:58 +0000
Cc: security@ariard.me, "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Oct 2023 04:49:35 -0000

--000000000000cda0c1060846d495
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Could this be addressed with an OP_CSV_ALLINPUTS, a covenant opcode that
requires *all* inputs to have a matching nSequence, and using `1
OP_CSV_ALLINPUTS` in the HTLC preimage branch?

This would prevent using unconfirmed outputs in the HTLC-preimage-spending
transaction entirely, which IIUC should protect it against the replacement
cycling attack.

(If desirable, this could alternatively be OP_CSV_OTHERINPUTS to allow the
HTLC output itself to be spent immediately via the preimage branch, and
only require that the other inputs added for fees are confirmed.)


On Mon, Oct 16, 2023 at 8:03=E2=80=AFPM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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 channel=
s
> 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 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 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 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 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 ful=
l
> 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
>
>  ## Problem
>
> A lightning node allows HTLCs forwarding (in bolt3's parlance accepted
> HTLC on incoming link and offered HTLC on outgoing link) should settle th=
e
> 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 propert=
y).
>
> Failure to satisfy this settlement requirement exposes a forwarding hop t=
o
> 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 incomi=
ng
> 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 an=
d
> node policy setting. As a minimal value, the specification 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 HT=
LC
> 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`) 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 heig=
ht
> is reached.
>
> Here enter a replacement cycling attack. A malicious channel counterparty
> can broadcast its HTLC-preimage transaction with a higher absolute fee an=
d
> 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 conflic=
ts
> its child.
>
> As the HTLC-preimage spends an unconfirmed input that was already include=
d
> 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 chil=
d
> 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 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 expiration
> of the inbound HTLC timelock I. Once this height is reached a HTLC-timeou=
t
> 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 block race and therefore realizes a spent of the offere=
d
> output. In practice, a replacement cycling attack 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 b=
y
> 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 onc=
e
> every block, or less the replacement cycling malicious transactions paid
> only equal the sum of the absolute fees paid by the HTLC, adjusted with t=
he
> replacement penalty. Rebroadcasting randomly and multiple times before th=
e
> 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 mempools, t=
he
> honest lightning node is able to catch on the flight the unconfirmed
> HTLC-preimage, before its subsequent mempool replacement. The preimage ca=
n
> 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 pai=
d
> 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 succes=
s
> 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 som=
e
> 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 an=
d
> 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 ha=
ve
> 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, wher=
e 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 i=
s
> 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 o=
f
> 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 potenti=
al
> 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 rul=
es
> 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 mempoo=
l
> anti-DoS rules, I discovered this new replacement cycling attack was
> affecting deployed lightning channels and immediately reported the findin=
g
> 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-lightnin=
g
> potential affected projects)
> - 2022-01-14: Sharing to Gleb Naumenko (miners incentives and cross-layer=
s
> 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 stil=
l
> practical for advanced attackers. Beyond this new attack might come as a
> way to partially or completely defeat some of the pinning mitigations whi=
ch
> 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 curre=
nt
> 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 / 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 thos=
e
> issues, or if any element has not been weighted with the adequate technic=
al
> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000cda0c1060846d495
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Could this be addressed with an OP_CSV_ALLINPUTS, a c=
ovenant opcode that=20
requires <i>all</i> inputs to have a matching nSequence, and using `1=20
OP_CSV_ALLINPUTS` in the HTLC preimage branch?<br></div><div><br></div><div=
>This would prevent using unconfirmed outputs in the HTLC-preimage-spending=
 transaction entirely, which IIUC should protect it against the replacement=
 cycling attack.<br></div><div><br></div><div>(If desirable, this could alt=
ernatively be OP_CSV_OTHERINPUTS to allow the HTLC output itself to be spen=
t immediately via the preimage branch, and only require that the other inpu=
ts added for fees are confirmed.)<br></div></div><div dir=3D"ltr"><br></div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mo=
n, Oct 16, 2023 at 8:03=E2=80=AFPM Antoine Riard via bitcoin-dev &lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>(cross-posting mempo=
ol issues identified are exposing lightning chan to loss of funds risks, ot=
her multi-party bitcoin apps might be affected)</div><div><br></div>Hi,<div=
><br></div><div>End of last year (December 2022), amid technical discussion=
s on eltoo payment channels and incentives compatibility of the mempool ant=
i-DoS rules, a new transaction-relay jamming attack affecting lightning cha=
nnels was discovered.</div><div><br></div><div>After careful analysis, it t=
urns out this attack is practical and immediately=C2=A0exposed lightning ro=
uting hops carrying HTLC traffic to loss of funds security risks, both lega=
cy and anchor=C2=A0output channels. A potential exploitation plausibly happ=
ening even without network mempools congestion.</div><div><br></div><div>Mi=
tigations have been designed, implemented and deployed by all major lightni=
ng implementations during the last months.</div><div><br></div><div>Please =
find attached the release numbers, where the mitigations should be present:=
</div><div>- LDK: v0.0.118 - CVE-2023 -40231</div><div>- Eclair: v0.9.0 - C=
VE-2023-40232</div><div>- LND: v.0.17.0-beta - CVE-2023-40233</div><div>- C=
ore-Lightning: v.23.08.01 - CVE-2023-40234</div><div><br></div><div>While n=
either replacement cycling attacks have been observed or reported in the wi=
ld since the last ~10 months or experimented in real-world conditions on bi=
tcoin mainet, functional test is available exercising the affected lightnin=
g channel against bitcoin core mempool (26.0 release cycle).</div><div><br>=
</div><div>It is understood that a simple replacement cycling attack does n=
ot demand privileged capabilities from an attacker (e.g no low-hashrate pow=
er) 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.</div><div><br></div><div>From m=
y understanding of those issues, it is yet to be determined if the mitigati=
ons deployed are robust enough in face of advanced replacement cycling atta=
ckers, especially ones able to combine different classes of transaction-rel=
ay jamming such as pinnings or vetted with more privileged capabilities.</d=
iv><div><br></div><div>Please find a list of potential affected bitcoin app=
lications in this full disclosure report using bitcoin script timelocks or =
multi-party transactions, albeit no immediate security risk exposure as sev=
ere as the ones affecting lightning has been identified. Only cursory revie=
w of non-lightning applications has been conducted so far.</div><div><br></=
div><div>There is a paper published summarizing replacement cycling attacks=
 on the lightning network:</div><div><a href=3D"https://github.com/ariard/m=
empool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf" tar=
get=3D"_blank">https://github.com/ariard/mempool-research/blob/2023-10-repl=
acement-paper/replacement-cycling.pdf</a></div><div><br></div><div>=C2=A0##=
 Problem</div><div><br></div><div>A lightning node allows HTLCs forwarding =
(in bolt3&#39;s parlance accepted HTLC on incoming link and offered HTLC on=
 outgoing link) should settle the outgoing state with either a success or t=
imeout before the incoming state timelock becomes final and an asymmetric d=
efavorable settlement might happen (cf &quot;Flood &amp; Loot: A Systematic=
 Attack on The Lightning Network&quot; section 2.3 for a classical expositi=
on of this lightning security property).</div><div><br></div><div>Failure t=
o satisfy this settlement requirement exposes a forwarding hop to a loss of=
 fund risk where the offered HTLC is spent by the outgoing link counterpart=
y&#39;s HTLC-preimage and the accepted HTLC is spent by the incoming link c=
ounterparty&#39;s HTLC-timeout.</div><div><br></div><div>The specification =
mandates the incoming HTLC expiration timelock to be spaced out by an inter=
val 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 equal to 100 from chain tip, t=
he timelock expiration O of the outbound HTLC must be equal to 66 blocks fr=
om chain tip, giving a reasonable buffer of reaction to the lightning forwa=
rding node.</div><div><br></div><div>In the lack of cooperative off-chain s=
ettlement of the HTLC on the outgoing link negotiated with the counterparty=
 (either `update_fulfill_htlc` or `update_fail_htlc`) when O is reached, th=
e lightning node should broadcast its commitment transaction. Once the comm=
itment is confirmed (if anchor and the 1 CSV encumbrance is present), the l=
ightning node broadcasts and confirms its HTLC-timeout before I height is r=
eached.</div><div><br></div><div>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 a=
nd anchor output channels, a HTLC-preimage on a counterparty commitment tra=
nsaction is malleable, i.e additional inputs or outputs can be added. The H=
TLC-preimage spends an unconfirmed and unrelated to the channel parent tran=
saction M and conflicts its child.</div><div><br></div><div>As the HTLC-pre=
image spends an unconfirmed input that was already included in the unconfir=
med and unrelated child transaction (rule 2), pays an absolute higher fee o=
f 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 tran=
sactions (rule 6), the replacement is accepted. The honest HTLC-timeout is =
evicted out of the mempool.</div><div><br></div><div>In an ulterior move, t=
he malicious counterparty can replace the parent transaction itself with an=
other candidate N satisfying the replacement rules, triggering the eviction=
 of the malicious HTLC-preimage from the mempool as it was a child of the p=
arent T.</div><div><br></div><div>There is no spending candidate of the off=
ered HTLC output for the current block laying in network mempools.</div><di=
v><br></div><div>This replacement cycling tricks can be repeated for each r=
ebroadcast attempt of the HTLC-timeout by the honest lightning node until e=
xpiration of the inbound HTLC timelock I. Once this height is reached a HTL=
C-timeout is broadcast by the counterparty&#39;s on the incoming link in co=
llusion with the one on the outgoing link broadcasting its own HTLC-preimag=
e.</div><div><br></div><div>The honest Lightning node has been &quot;double=
-spent&quot; in its HTLC forwarding.</div><div><br></div><div>As a notable =
factor impacting the success of the attack, a lightning node&#39;s honest H=
TLC-timeout might be included in the block template of the miner winning th=
e block race and therefore realizes a spent of the offered output. In pract=
ice, a replacement cycling attack might over-connect to miners&#39; mempool=
s and public reachable nodes to succeed in a fast eviction of the HTLC-time=
out 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 compe=
titive miners.</div><div><br></div><div>A functional test exercising a simp=
le replacement cycling of a HTLC transaction on bitcoin core mempool is ava=
ilable:</div><div><a href=3D"https://github.com/ariard/bitcoin/commits/2023=
-test-mempool" target=3D"_blank">https://github.com/ariard/bitcoin/commits/=
2023-test-mempool</a><br></div><div><br></div><div>## Deployed LN mitigatio=
ns</div><div><br></div><div>Aggressive rebroadcasting: As the replacement c=
ycling attacker benefits from the HTLC-timeout being usually broadcast by l=
ightning nodes only once every block, or less the replacement cycling malic=
ious transactions paid only equal the sum of the absolute fees paid by the =
HTLC, adjusted with the replacement penalty. Rebroadcasting randomly and mu=
ltiple times before the next block increases the absolute fee cost for the =
attacker.</div><div><br></div><div>Implemented and deployed by Eclair, Core=
-Lightning, LND and LDK .</div><div><br></div><div>Local-mempool preimage m=
onitoring: As the replacement cycling attacker 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 subs=
equent mempool replacement. The preimage can be extracted from the second-s=
tage HTLC-preimage and used to fetch the off-chain inbound HTLC with a coop=
erative message or go on-chain with it to claim the accepted HTLC output.</=
div><div><br></div><div>Implemented and deployed by Eclair and LND.<br></di=
v><div><br></div><div>CLTV Expiry Delta: With every jammed block comes an a=
bsolute fee cost paid by the attacker, a risk of the HTLC-preimage being de=
tected or discovered by the honest lightning node, or the HTLC-timeout to s=
lip in a winning block template. Bumping the default CLTV delta hardens the=
 odds of success of a simple replacement cycling attack.</div><div><br></di=
v><div>Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72.</=
div><div><br></div><div>## Affected Bitcoin Protocols and Applications</div=
><div><br></div><div>From my understanding the following list of Bitcoin pr=
otocols 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 t=
hem:</div><div>- on-chain DLCs</div><div>- coinjoins</div><div>- payjoins</=
div><div>- wallets with time-sensitive paths</div><div>- peerswap and subma=
rine swaps</div><div>- batch payouts</div><div>- transaction &quot;accelera=
tors&quot;</div><div><br></div><div>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 shortes=
t delay. Simple flows and non-multi-party transactions should not be affect=
ed to the best of my understanding.</div><div><br></div><div>## Open Proble=
ms: Package Malleability</div><div><br></div><div>Pinning attacks have been=
 known for years as a practical vector to compromise lightning channels fun=
ds safety, under different scenarios (cf. current bip331&#39;s motivation s=
ection). Mitigations at the mempool level have been designed, discussed and=
 are under implementation by the community (ancestor package relay=C2=A0+ n=
verrsion=3D3 policy). Ideally, they should constraint a pinning attacker to=
 always attach a high feerate package (commitment=C2=A0+ CPFP) to replace t=
he honest package, or allow a honest lightning node to overbid a malicious =
pinning package and get its time-sensitive transaction optimistically inclu=
ded in the chain.</div><div><br></div><div>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 packa=
ge out of the mempool to subsequently double-spend its own high-fee child w=
ith a transaction unrelated to the channel. As the remaining commitment tra=
nsaction is pre-signed with a minimal relay fee, it can be evicted out of t=
he mempool.</div><div><br></div><div>A functional test exercising a simple =
replacement cycling of a lightning channel commitment transaction on top of=
 the nversion=3D3 code branch is available:</div><div><a href=3D"https://gi=
thub.com/ariard/bitcoin/commits/2023-10-test-mempool-2" target=3D"_blank">h=
ttps://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2</a><br></di=
v><div><br></div><div>## Discovery</div><div><br></div><div>In 2018, the is=
sue of static fees for pre-signed lightning transactions is made more widel=
y known, the carve-out exemption in mempool rules to mitigate in-mempool pa=
ckage limits pinning and the anchor output pattern are proposed.</div><div>=
<br></div><div>In 2019, bitcoin core 0.19 is released with carve-out suppor=
t. Continued discussion of the anchor output pattern as a dynamic fee-bumpi=
ng method.</div><div><br></div><div>In 2020, draft of anchor output submitt=
ed to the bolts. Initial finding of economic pinning against lightning comm=
itment and second-stage HTLC transactions. Subsequent discussions of a prei=
mage-overlay network or package-relay as mitigations. Public call made to i=
nquiry more on potential other transaction-relay jamming attacks affecting =
lightning.</div><div><br></div><div>In 2021, initial work in bitcoin core 2=
2.0 of package acceptance. Continued discussion of the pinning attacks and =
shortcomings of current mempool rules during community-wide online workshop=
s. Later the year, in light of all issues for bitcoin second-layers, a prop=
osal is made about killing the mempool.</div><div><br></div><div>In 2022, b=
ip proposed for package relay and new proposed v3 policy design proposed fo=
r 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.</div><div><br></div><div>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 discover=
ed this new replacement cycling attack was affecting deployed lightning cha=
nnels and immediately reported the finding to some bitcoin core developers =
and lightning maintainers.</div><div><br></div><div>## Timeline</div><div><=
br></div><div>- 2022-12-16: Report of the finding to Suhas Daftuar, Anthony=
 Towns, Greg Sanders and Gloria Zhao</div><div>- 2022-12-16: Report to LN m=
aintainers: Rusty Russell, Bastien Teinturier, Matt Corallo and Olaoluwa Os=
untunkun</div><div>- 2022-12-23: Sharing to Eugene Siegel (LND)</div><div>-=
 2022-12-24: Sharing to James O&#39;Beirne and Antoine Poinsot (non-lightni=
ng potential affected projects)</div><div>- 2022-01-14: Sharing to Gleb Nau=
menko (miners incentives and cross-layers issuers) and initial proposal of =
an early public disclosure=C2=A0</div><div>- 2022-01-19: Collection of anal=
ysis if other second-layers and multi-party applications affected. LN mitig=
ations development starts.</div><div>- 2023-05-04: Sharing to Wilmer Paulin=
o (LDK)</div><div>- 2023-06-20: LN mitigations implemented and progressivel=
y released. Week of the 16 october proposed for full disclosure.</div><div>=
- 2023-08-10: CVEs assigned by MITRE</div><div>- 2023-10-05: Pre-disclosure=
 of LN CVEs numbers and replacement cycling attack existence to <a href=3D"=
mailto:security@bitcoincore.org" target=3D"_blank">security@bitcoincore.org=
</a>.</div><div>- 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2023-=
40232 / CVE-2023-40233 / CVE-2023-40234 and replacement cycling attacks</di=
v><div><br></div><div>## Conclusion=C2=A0</div><div><br></div><div>Despite =
the line of mitigations adopted and deployed by current major lightning imp=
lementations, I believe replacement cycling attacks are still practical for=
 advanced attackers. Beyond this new attack might come as a way to partiall=
y or completely defeat some of the pinning mitigations which have been work=
ing for years as a community.</div><div><br></div><div>As of today, it is u=
ncertain to me if lightning is not affected by a more severe long-term pack=
age malleability critical security issue under current consensus rules, and=
 if any other time-sensitive multi-party protocol, designed or deployed isn=
&#39;t de facto affected too (loss of funds or denial of service).</div><di=
v><br></div><div>Assuming analysis on package malleability is correct, it i=
s unclear to me if it can be corrected by changes in replacement / eviction=
 rules or mempool chain of transactions processing strategy. Inviting my te=
chnical peers and the bitcoin community to look more on this issue, includi=
ng to dissent. I&#39;ll be the first one pleased if I&#39;m fundamentally w=
rong on those issues, or if any element has not been weighted with the adeq=
uate technical accuracy it deserves.</div><div><br></div><div>Do not trust,=
 verify. All mistakes and opinions are my own.</div><div><br></div><div>Ant=
oine</div><div><br></div><div>&quot;meet with Triumph and Disaster. And tre=
at those two impostors just the same&quot; - K.</div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000cda0c1060846d495--