path: root/74/e227cbf9276e318a1d4700f4d339bc3a921ff4

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0AE12C0032;
 Tue, 17 Oct 2023 17:47:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id C494E4046B;
 Tue, 17 Oct 2023 17:47:30 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C494E4046B
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=XqZzOhkH
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id XlyHPuihP0ds; Tue, 17 Oct 2023 17:47:27 +0000 (UTC)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com
 [IPv6:2607:f8b0:4864:20::12b])
 by smtp2.osuosl.org (Postfix) with ESMTPS id D03E1400F3;
 Tue, 17 Oct 2023 17:47:26 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org D03E1400F3
Received: by mail-il1-x12b.google.com with SMTP id
 e9e14a558f8ab-3528bc102adso22243375ab.2; 
 Tue, 17 Oct 2023 10:47:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1697564846; x=1698169646;
 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=I0h0bevg1BRbXQt/NOm28FBqLXSZ1gv/tSGL1EzCsAc=;
 b=XqZzOhkHu+z4clzTNZze+AwJcqGcE6zAyJFUVYW4M4rDM1Io+/BFk+7GNBM5SBVT63
 82ZeQV/etEA2J+8M2x6t1att03eOpB3T+YB1WmSguXrVQmuAW/248VXrYKJbZOFLVuUg
 B0VkAV57pY+emsDjgSryCiLPqxdJ1liqNNQdwUAxQr4yyWhQMmiLL+s/X5S1q/c6/W1Q
 MHd8nrvLpqFWdYv8hWuxpssmP+zIizSSjTBnlaD/ia7+RJ0zrK+sDVxNgSkk1SZwT1zf
 1jCs6S1ngb0+RZtlrlQ8eqaI8+PeCvmg7bztLvep6JnRE1xKHOsHbL+8q9NVIHkU94cU
 ZGww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1697564846; x=1698169646;
 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=I0h0bevg1BRbXQt/NOm28FBqLXSZ1gv/tSGL1EzCsAc=;
 b=Gf/KyMVIv10VqTHIvvede+ZzSBQWNIfmvWPtkFYA8mh7bBh9Ut6puR5KmCDmxMtYu9
 y1bTZVC9v6YzNgYnqUj/N1c4y0tdJpfopNrdriofR+8Udg3FAoW9AuPQuhM2h/Q2tAYm
 JwhM8Bwr2ui4S1eZF04tjt1nDHg1/NeLr5x4wntcGAi/TpB3kFvZp+VVp0zkqZvGmENS
 /sezgP6a/+X++K9t4QcVpHyRClCsmXpvkWSVqf0lg+iRIb61PA6033+qgWBvbyhPSpi6
 pIFaqgiSck9dRSDNoYoBCcluRGHGhBkC6ISVc1UVWSTxmOnrEEHqDrVGADsvShhRRTsP
 OfIQ==
X-Gm-Message-State: AOJu0YxQrkOImiG/VSS85Z+iGdig2LF0V++BOIenUUWbK54YOsCpD96o
 31hwQtt5SoP+JfFl7ImEtHYrxO9DnCqqRy+6+H0=
X-Google-Smtp-Source: AGHT+IEtM+aLbuUDq8Pa95NFwrUeDZkScnNrwjphEFM69aLPKjK/TK4ZBvpGzaLGxX6d+d1qxBlNuqeVTs8mg2OkLVY=
X-Received: by 2002:a92:da41:0:b0:357:6ad5:51c0 with SMTP id
 p1-20020a92da41000000b003576ad551c0mr2954116ilq.3.1697564845685; Tue, 17 Oct
 2023 10:47:25 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <eW4O0HQJ2cbrzZhXSlgeDRWuhgRHXcAxIQCHJiqPh1zUxr270xPvl_tb7C4DUauZy56HaCq6BqGN9p4k-bkqQmLb4EHzPgIxZIZGVPlqyF0=@protonmail.com>
In-Reply-To: <eW4O0HQJ2cbrzZhXSlgeDRWuhgRHXcAxIQCHJiqPh1zUxr270xPvl_tb7C4DUauZy56HaCq6BqGN9p4k-bkqQmLb4EHzPgIxZIZGVPlqyF0=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 17 Oct 2023 18:47:14 +0100
Message-ID: <CALZpt+HMBgLhuXaeZHFkbHCi644HWKu0YUAZ+soLDMebWcKLyQ@mail.gmail.com>
To: ziggie1984 <ziggie1984@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000009c40a40607ed1d27"
X-Mailman-Approved-At: Wed, 18 Oct 2023 00:07:44 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 security@ariard.me, "lightning-dev\\\\\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 /
 CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are
 belong to us"
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <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: Tue, 17 Oct 2023 17:47:31 -0000

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

Hi Ziggie,

> thanks for this detailed explanation. This class of pinning attacks sound
not too unlikely especially if the attacker targets channels with high
capacity and very loose channel policies (allowing the full htlc
> amount to be the channel capacity). Could you add more details about the
attack you observed on mainnet ? How did you monitor the chain, are the
some tools available I can run in parallel to my
> lightning software to record this kind of suspicious behaviour (which did
you use)?

Just to give a clarification no _such_ attack has been observed on mainnet,
since I and other LN maintainers have been aware of this issue. If there is
a confusion on the disclosure mail thanks to point to it, I'll correct it.

We discussed privately to experiment a demo attack in restrained dev
circles, like we have done in the past for some LN sec issues. We have
conducted one so far, multiple scenarios to look at.

I confirm the risk of exposure if an attacker targets channels with high
capacity and loose channel policies. Note there is no way to configure the
cap for the total value of outbound HTLC in-flight, which is the flow
affected.

If you would like to observe the existence of such an attack happening,
look at your mempool logs and the amount of HTLC output being
systematically conflicted out with the following sequence (HTLC-timeout -
HTLC-preimage - HTLC-timeout - ...).

As an observation note, this is not akin to a pinning attack, as there is
no "honest" or "malicious" transaction pinned in network mempools. And it
can happen without network mempools congestion.

> What's also worth mentioning here is that you do not really have to
control 2 neighbouring nodes to target your victim. If you can cycle the
attack on the tail side and delay the confirmation of the htlc- timeout
covenant the peer at the front (incoming link) of the victim will
force-close the channel and claim his timeout-path in the same way
(canceling back the initial htlc amount to the attackers initial node).

I think this is a behavior worthy of testing.

> Apart from that I think one can even introduce some kind of feebumping
race between the victim and the attacker on the tail side of the attack
making the attack even more costly. I think
> currently when lightning nodes see the preimage in the mempool (during
the time where they already can spend the same output with the
timeout-covenant) we are honest and just extract
> the preimage and don't try to race this tx output.

Local-mempool preimage monitoring has been implemented by Eclair for years
as a mitigation against old school pinning attacks on second-stage HTLC
transactions.

This mechanism has been implemented by LND in the last months, following
the report of replacement cycling attacks. As of today this is not
implemented by Core-Lightning or LDK.

> So we maybe should start feebumping this output if we end up in this
scenario? If we see the preimage and can also claim this output via the
htlc-timeout path, we should aggressively fee-bump (racing this output) our
htlc-output in addition to grabbing the preimage and claiming it on the
incoming. This is only feasible with anchor channels where we can add fees
to the htlc-covenant. This would make the attack more costly for a peer
when he knows that we use fees up to 50% of the htlc value. When you cycle
this 144 times you will be at a heavy loss trying to steal this htlc.

This is the "defensive fee mitigation" proposed in the paper. Coming with
some unknown.

> I would add another mitigation to the list for node runners to restrict
the amount and number of HTLCs  for big channels to unknown peers. It
quickly comes with a loss when the HTLCs the attacker tries to steal are
small.

See the point above on the lack of way at the spec-level to negotiate cap
on the total value of outbound HTLC in-flight.

Le mar. 17 oct. 2023 =C3=A0 08:21, ziggie1984 <ziggie1984@protonmail.com> a
=C3=A9crit :

> ## 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.
>
>
> Hi Antoine,
>
> thanks for this detailed explanation. This class of pinning attacks sound
> not too unlikely especially if the attacker targets channels with high
> capacity and very loose channel policies (allowing the full htlc amount t=
o
> be the channel capacity). Could you add more details about the attack you
> observed on mainnet ? How did you monitor the chain, are the some tools
> available I can run in parallel to my lightning software to record this
> kind of suspicious behaviour (which did you use)?
> What's also worth mentioning here is that you do not really have to
> control 2 neighbouring nodes to target your victim. If you can cycle the
> attack on the tail side and delay the confirmation of the htlc-timeout
> covenant the peer at the front (incoming link) of the victim will
> force-close the channel and claim his timeout-path in the same way
> (canceling back the initial htlc amount to the attackers initial node).
>
> Apart from that I think one can even introduce some kind of feebumping
> race between the victim and the attacker on the tail side of the attack
> making the attack even more costly. I think currently when lightning node=
s
> see the preimage in the mempool (during the time where they already can
> spend the same output with the timeout-covenant) we are honest and just
> extract the preimage and don't try to race this tx output. So we maybe
> should start feebumping this output if we end up in this scenario? If we
> see the preimage and can also claim this output via the htlc-timeout path=
,
> we should aggressively fee-bump (racing this output) our htlc-output in
> addition to grabbing the preimage and claiming it on the incoming. This i=
s
> only feasible with anchor channels where we can add fees to the
> htlc-covenant. This would make the attack more costly for a peer when he
> knows that we use fees up to 50% of the htlc value. When you cycle this 1=
44
> times you will be at a heavy loss trying to steal this htlc.
>
> I would add another mitigation to the list for node runners to restrict
> the amount and number of HTLCs  for big channels to unknown peers. It
> quickly comes with a loss when the HTLCs the attacker tries to steal are
> small.
>
>
> Kind regards,
>
> ziggie
>
>
> ------- Original Message -------
> On Monday, October 16th, 2023 at 18:57, Antoine Riard <
> antoine.riard@gmail.com> 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.
>
>
>

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

<div dir=3D"ltr">Hi Ziggie,<div><br></div><div><span style=3D"font-family:A=
rial,sans-serif">&gt; thanks for this detailed explanation. This class of p=
inning attacks sound not too unlikely especially if the attacker=C2=A0targe=
ts=C2=A0channels with high capacity=C2=A0and very loose channel policies (a=
llowing the full htlc</span></div><div><span style=3D"font-family:Arial,san=
s-serif">&gt; amount to be the channel capacity). Could you add more detail=
s about the attack you observed=C2=A0on mainnet ? How did you monitor=C2=A0=
the chain, are the some tools available=C2=A0I can run in parallel to my</s=
pan></div><div><span style=3D"font-family:Arial,sans-serif">&gt; lightning =
software to record this kind of suspicious behaviour (which did you use)?</=
span><br></div><div><span style=3D"font-family:Arial,sans-serif"><br></span=
></div><div><span style=3D"font-family:Arial,sans-serif">Just to give a cla=
rification no _such_ attack has been observed on mainnet, since I and other=
 LN maintainers have been aware of this issue. If there is a confusion on t=
he disclosure mail thanks to point to it, I&#39;ll correct it.</span></div>=
<div><span style=3D"font-family:Arial,sans-serif"><br></span></div><div><sp=
an style=3D"font-family:Arial,sans-serif">We discussed privately to experim=
ent a demo attack in restrained dev circles, like we have done in the past =
for some LN sec issues. We have conducted one so far, multiple=C2=A0scenari=
os=C2=A0to look at.</span></div><div><span style=3D"font-family:Arial,sans-=
serif"><br></span></div><div><span style=3D"font-family:Arial,sans-serif">I=
 confirm the risk of exposure if an attacker targets channels with high cap=
acity and loose channel policies. Note there is no way to configure the cap=
 for the total value of outbound HTLC in-flight, which is the flow affected=
.</span></div><div><span style=3D"font-family:Arial,sans-serif"><br></span>=
</div><div><span style=3D"font-family:Arial,sans-serif">If you would like t=
o observe the existence of such an attack happening, look at your mempool l=
ogs and the amount of HTLC output being systematically conflicted out with =
the following sequence (HTLC-timeout - HTLC-preimage - HTLC-timeout - ...).=
</span></div><div><span style=3D"font-family:Arial,sans-serif"><br></span><=
/div><div><span style=3D"font-family:Arial,sans-serif">As an observation no=
te, this is not akin to a pinning attack, as there is no &quot;honest&quot;=
 or &quot;malicious&quot; transaction pinned in network mempools. And it ca=
n happen without network mempools congestion.</span></div><div><span style=
=3D"font-family:Arial,sans-serif"><br></span></div><div><div><div><font fac=
e=3D"Arial, sans-serif">&gt; What&#39;s also worth mentioning here is that =
you do not really have to control 2 neighbouring nodes to target your victi=
m. If you can cycle the attack on the tail side and delay the confirmation =
of the htlc- timeout covenant=C2=A0the peer at the front (incoming link) of=
 the victim will force-close the channel and claim his timeout-path in the =
same way (canceling back the initial htlc amount to the attackers initial n=
ode).</font></div></div><div><font face=3D"Arial, sans-serif"><br></font></=
div><div><font face=3D"Arial, sans-serif">I think this is a behavior worthy=
 of testing.</font></div><div><font face=3D"Arial, sans-serif"><br></font><=
/div><div><span style=3D"font-family:Arial,sans-serif;font-size:14px">&gt; =
Apart from that I think one can even introduce some kind of feebumping race=
 between the victim and the attacker on the tail side of the attack making =
the attack even more costly. I think</span></div><div><span style=3D"font-f=
amily:Arial,sans-serif;font-size:14px">&gt; currently when lightning nodes =
see the preimage in the mempool (during the time where they already can spe=
nd the same output with the timeout-covenant) we are honest and just extrac=
t</span></div><div><span style=3D"font-family:Arial,sans-serif;font-size:14=
px">&gt; the preimage and don&#39;t try to race this tx output.</span><font=
 face=3D"Arial, sans-serif"><br></font></div><div><br></div><div><font face=
=3D"Arial, sans-serif">Local-mempool preimage monitoring has been implement=
ed by Eclair for years as a mitigation against old school pinning attacks o=
n second-stage HTLC transactions.</font></div><div><font face=3D"Arial, san=
s-serif"><br></font></div><div><font face=3D"Arial, sans-serif">This mechan=
ism has been implemented by LND in the last months, following the report of=
 replacement cycling attacks. As of today this is not implemented by Core-L=
ightning or LDK.</font></div><div><font face=3D"Arial, sans-serif"><br></fo=
nt></div><div><span style=3D"font-family:Arial,sans-serif;font-size:14px">&=
gt; So we maybe should start feebumping this output if we end up in this sc=
enario? If we see the preimage and can also claim this output via the htlc-=
timeout path, we should aggressively fee-bump (racing this output) our htlc=
-output in addition to grabbing the preimage and claiming it on the incomin=
g. This is only feasible with anchor channels where we can add fees to the =
htlc-covenant. This would make the attack more costly for a peer when he kn=
ows that we use fees up to 50% of the htlc value. When you cycle this 144 t=
imes you will be at a heavy loss trying to steal this htlc.=C2=A0</span><fo=
nt face=3D"Arial, sans-serif"><br></font></div><div><span style=3D"font-fam=
ily:Arial,sans-serif;font-size:14px"><br></span></div><div>This is the &quo=
t;defensive fee mitigation&quot; proposed in the paper. Coming with some un=
known.</div><div><br></div><div><span style=3D"font-family:Arial,sans-serif=
;font-size:14px">&gt; I would add another mitigation to the list for node r=
unners to restrict the amount and number of HTLCs=C2=A0 for big channels to=
 unknown peers. It quickly comes with a loss when the HTLCs the attacker tr=
ies to steal are small.</span><br></div><div><font face=3D"Arial, sans-seri=
f"><br></font></div>See the point above on the lack of way at the spec-leve=
l to negotiate cap on the total value of outbound HTLC in-flight.</div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=
=C2=A0mar. 17 oct. 2023 =C3=A0=C2=A008:21, ziggie1984 &lt;<a href=3D"mailto=
:ziggie1984@protonmail.com">ziggie1984@protonmail.com</a>&gt; a =C3=A9crit=
=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div><blockquote style=3D"font-family:Ari=
al,sans-serif;font-size:14px;border-left-width:3px;border-left-style:solid;=
border-color:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)"><sp=
an style=3D"line-height:1.5;font-family:system-ui,sans-serif">## Deployed L=
N mitigations</span><div style=3D"line-height:1.5;font-family:system-ui,san=
s-serif"><br></div><div style=3D"line-height:1.5;font-family:system-ui,sans=
-serif">Aggressive rebroadcasting: As the replacement cycling attacker bene=
fits from the HTLC-timeout being usually broadcast by lightning nodes only =
once every block, or less the replacement cycling malicious transactions pa=
id 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.</div><div =
style=3D"line-height:1.5;font-family:system-ui,sans-serif"><br></div><div s=
tyle=3D"line-height:1.5;font-family:system-ui,sans-serif">Implemented and d=
eployed by Eclair, Core-Lightning, LND and LDK .</div><div style=3D"line-he=
ight:1.5;font-family:system-ui,sans-serif"><br></div><div><span style=3D"li=
ne-height:1.5;font-family:system-ui,sans-serif">Local-mempool preimage moni=
toring: As the replacement cycling attacker in a simple setup broadcast the=
 HTLC-preimage to all the network mempools, the honest lightning node is ab=
le to catch on the flight the unconfirmed HTLC-preimage, before its subsequ=
ent mempool replacement. The preimage can be extracted from the second-stag=
e HTLC-preimage and used to fetch the off-chain inbound HTLC with a coopera=
tive message or go on-chain with it to claim the accepted HTLC output.</spa=
n><br></div></blockquote><div style=3D"font-family:Arial,sans-serif;font-si=
ze:14px"><span><br></span></div><div style=3D"font-family:Arial,sans-serif;=
font-size:14px"><span>Hi Antoine,</span></div><div style=3D"font-family:Ari=
al,sans-serif;font-size:14px"><span><br></span></div><div><font face=3D"Ari=
al, sans-serif">thanks for this detailed explanation. This class of pinning=
 attacks sound not too unlikely especially if the attacker=C2=A0targets=C2=
=A0channels with high capacity=C2=A0and very loose channel policies (allowi=
ng the full htlc amount to be the channel capacity). Could you add more det=
ails about the attack you observed=C2=A0on mainnet ? How did you monitor=C2=
=A0the chain, are the some tools available=C2=A0I can run in parallel to my=
 lightning software to record this kind of suspicious behaviour (which did =
you use)?</font></div><div><font face=3D"Arial, sans-serif">What&#39;s also=
 worth mentioning here is that you do not really have to control 2 neighbou=
ring nodes to target your victim. If you can cycle the attack on the tail s=
ide and delay the confirmation of the htlc-timeout covenant=C2=A0the peer a=
t the front (incoming link) of the victim will force-close the channel and =
claim his timeout-path in the same way (canceling back the initial htlc amo=
unt to the attackers initial node).</font></div></div><div style=3D"font-fa=
mily:Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-family:A=
rial,sans-serif;font-size:14px">Apart from that I think one can even introd=
uce some kind of feebumping race between the victim and the attacker on the=
 tail side of the attack making the attack even more costly. I think curren=
tly when lightning nodes see the preimage in the mempool (during the time w=
here they already can spend the same output with the timeout-covenant) we a=
re honest and just extract the preimage and don&#39;t try to race this tx o=
utput. So we maybe should start feebumping this output if we end up in this=
 scenario? If we see the preimage and can also claim this output via the ht=
lc-timeout path, we should aggressively fee-bump (racing this output) our h=
tlc-output in addition to grabbing the preimage and claiming it on the inco=
ming. This is only feasible with anchor channels where we can add fees to t=
he htlc-covenant. This would make the attack more costly for a peer when he=
 knows that we use fees up to 50% of the htlc value. When you cycle this 14=
4 times you will be at a heavy loss trying to steal this htlc.=C2=A0</div><=
div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div st=
yle=3D"font-family:Arial,sans-serif;font-size:14px">I would add another mit=
igation to the list for node runners to restrict the amount and number of H=
TLCs=C2=A0 for big channels to unknown peers. It quickly comes with a loss =
when the HTLCs the attacker tries to steal are small.</div><div style=3D"fo=
nt-family:Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-fam=
ily:Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-family:Ar=
ial,sans-serif;font-size:14px">Kind regards,</div><div style=3D"font-family=
:Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-family:Arial=
,sans-serif;font-size:14px">ziggie</div><div style=3D"font-family:Arial,san=
s-serif;font-size:14px"><br></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div>
        ------- Original Message -------<br>
        On Monday, October 16th, 2023 at 18:57, Antoine Riard &lt;<a href=
=3D"mailto:antoine.riard@gmail.com" target=3D"_blank">antoine.riard@gmail.c=
om</a>&gt; wrote:<br><br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><div>(cross-posting mempool issues identified =
are exposing lightning chan to loss of funds risks, other multi-party bitco=
in apps might be affected)</div><div><br></div>Hi,<div><br></div><div>End o=
f last year (December 2022), amid technical discussions on eltoo payment ch=
annels and incentives compatibility of the mempool anti-DoS rules, a new tr=
ansaction-relay jamming attack affecting lightning channels was discovered.=
</div><div><br></div><div>After careful analysis, it turns out this attack =
is practical and immediately exposed lightning routing hops carrying HTLC t=
raffic to loss of funds security risks, both legacy and anchor output chann=
els. A potential exploitation plausibly happening even without network memp=
ools congestion.</div><div><br></div><div>Mitigations have been designed, i=
mplemented and deployed by all major lightning implementations during the l=
ast months.</div><div><br></div><div>Please find attached the release numbe=
rs, where the mitigations should be present:</div><div>- LDK: v0.0.118 - CV=
E-2023 -40231</div><div>- Eclair: v0.9.0 - CVE-2023-40232</div><div>- LND: =
v.0.17.0-beta - CVE-2023-40233</div><div>- Core-Lightning: v.23.08.01 - CVE=
-2023-40234</div><div><br></div><div>While neither replacement cycling atta=
cks have been observed or reported in the wild since the last ~10 months or=
 experimented in real-world conditions on bitcoin mainet, functional test i=
s available exercising the affected lightning channel against bitcoin core =
mempool (26.0 release cycle).</div><div><br></div><div>It is understood tha=
t a simple replacement cycling attack does not demand privileged capabiliti=
es from an attacker (e.g no low-hashrate power) and only access to basic bi=
tcoin and lightning software. Yet I still think executing such an attack su=
ccessfully requests a fair amount of bitcoin technical know-how and decent =
preparation.</div><div><br></div><div>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.</div><div><br></div><div>Please f=
ind a list of potential affected bitcoin applications in this full disclosu=
re report using bitcoin script timelocks or multi-party transactions, albei=
t no immediate security risk exposure as severe as the ones affecting light=
ning has been identified. Only cursory review of non-lightning applications=
 has been conducted so far.</div><div><br></div><div>There is a paper publi=
shed summarizing replacement cycling attacks on the lightning network:</div=
><div><a rel=3D"noreferrer nofollow noopener" href=3D"https://github.com/ar=
iard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pd=
f" target=3D"_blank">https://github.com/ariard/mempool-research/blob/2023-1=
0-replacement-paper/replacement-cycling.pdf</a></div><div><br></div><div> #=
# 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 o=
n 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 &quot;Flood &amp; Loot: A Systemati=
c Attack on The Lightning Network&quot; section 2.3 for a classical exposit=
ion of this lightning security property).</div><div><br></div><div>Failure =
to satisfy this settlement requirement exposes a forwarding hop to a loss o=
f fund risk where the offered HTLC is spent by the outgoing link counterpar=
ty&#39;s HTLC-preimage and the accepted HTLC is spent by the incoming link =
counterparty&#39;s HTLC-timeout.</div><div><br></div><div>The specification=
 mandates the incoming HTLC expiration timelock to be spaced out by an inte=
rval of `cltv_expiry_delta` from the outgoing HTLC expiration timelock, thi=
s 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, =
the timelock expiration O of the outbound HTLC must be equal to 66 blocks f=
rom chain tip, giving a reasonable buffer of reaction to the lightning forw=
arding node.</div><div><br></div><div>In the lack of cooperative off-chain =
settlement of the HTLC on the outgoing link negotiated with the counterpart=
y (either `update_fulfill_htlc` or `update_fail_htlc`) when O is reached, t=
he lightning node should broadcast its commitment transaction. Once the com=
mitment 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.</div><div><br></div><div>Here enter a replacement cycling attack. =
A malicious channel counterparty can broadcast its HTLC-preimage transactio=
n with a higher absolute fee and higher feerate than the honest HTLC-timeou=
t of the victim lightning node and triggers a replacement. Both for legacy =
and anchor output channels, a HTLC-preimage on a counterparty commitment tr=
ansaction is malleable, i.e additional inputs or outputs can be added. The =
HTLC-preimage spends an unconfirmed and unrelated to the channel parent tra=
nsaction M and conflicts its child.</div><div><br></div><div>As the HTLC-pr=
eimage spends an unconfirmed input that was already included in the unconfi=
rmed 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 tra=
nsactions (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, =
the malicious counterparty can replace the parent transaction itself with a=
nother candidate N satisfying the replacement rules, triggering the evictio=
n of the malicious HTLC-preimage from the mempool as it was a child of the =
parent T.</div><div><br></div><div>There is no spending candidate of the of=
fered HTLC output for the current block laying in network mempools.</div><d=
iv><br></div><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 HT=
LC-timeout is broadcast by the counterparty&#39;s on the incoming link in c=
ollusion with the one on the outgoing link broadcasting its own HTLC-preima=
ge.</div><div><br></div><div>The honest Lightning node has been &quot;doubl=
e-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 =
HTLC-timeout might be included in the block template of the miner winning t=
he block race and therefore realizes a spent of the offered output. In prac=
tice, a replacement cycling attack might over-connect to miners&#39; mempoo=
ls and public reachable nodes to succeed in a fast eviction of the HTLC-tim=
eout by its HTLC-preimage. As this latter transaction can come with a bette=
r ancestor-score, it should be picked up on the flight by economically comp=
etitive miners.</div><div><br></div><div>A functional test exercising a sim=
ple replacement cycling of a HTLC transaction on bitcoin core mempool is av=
ailable:</div><div><a rel=3D"noreferrer nofollow noopener" href=3D"https://=
github.com/ariard/bitcoin/commits/2023-test-mempool" target=3D"_blank">http=
s://github.com/ariard/bitcoin/commits/2023-test-mempool</a><br></div><div><=
br></div><div>## Deployed LN mitigations</div><div><br></div><div>Aggressiv=
e rebroadcasting: As the replacement cycling attacker benefits from the HTL=
C-timeout being usually broadcast by lightning nodes only once every block,=
 or less the replacement cycling malicious transactions paid only equal the=
 sum of the absolute fees paid by the HTLC, adjusted with the replacement p=
enalty. Rebroadcasting randomly and multiple times before the next block in=
creases the absolute fee cost for the attacker.</div><div><br></div><div>Im=
plemented and deployed by Eclair, Core-Lightning, LND and LDK .</div><div><=
br></div><div>Local-mempool preimage monitoring: 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 unco=
nfirmed HTLC-preimage, before its subsequent mempool replacement. The preim=
age 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.</div><div><br></div><div>Implemented a=
nd deployed by Eclair and LND.<br></div><div><br></div><div>CLTV Expiry Del=
ta: 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 li=
ghtning node, or the HTLC-timeout to slip in a winning block template. Bump=
ing the default CLTV delta hardens the odds of success of a simple replacem=
ent cycling attack.</div><div><br></div><div>Default setting: Eclair 144, C=
ore-Lightning 34, LND 80 and LDK 72.</div><div><br></div><div>## Affected B=
itcoin Protocols and Applications</div><div><br></div><div>From my understa=
nding the following list of Bitcoin protocols and applications could be aff=
ected by new denial-of-service vectors under some level of network mempools=
 congestion. Neither tests or advanced review of specifications (when avail=
able) has been conducted for each of them:</div><div>- on-chain DLCs</div><=
div>- coinjoins</div><div>- payjoins</div><div>- wallets with time-sensitiv=
e paths</div><div>- peerswap and submarine swaps</div><div>- batch payouts<=
/div><div>- transaction &quot;accelerators&quot;</div><div><br></div><div>I=
nviting their developers, maintainers and operators to investigate how repl=
acement cycling attacks might disrupt their in-mempool chain of transaction=
s, or fee-bumping flows at the shortest delay. Simple flows and non-multi-p=
arty transactions should not be affected to the best of my understanding.</=
div><div><br></div><div>## Open Problems: Package Malleability</div><div><b=
r></div><div>Pinning attacks have been known for years as a practical vecto=
r to compromise lightning channels funds safety, under different scenarios =
(cf. current bip331&#39;s motivation section). Mitigations at the mempool l=
evel have been designed, discussed and are under implementation by the comm=
unity (ancestor package relay + nverrsion=3D3 policy). Ideally, they should=
 constraint a pinning attacker to always attach a high feerate package (com=
mitment + CPFP) to replace the honest package, or allow a honest lightning =
node to overbid a malicious pinning package and get its time-sensitive tran=
saction optimistically included in the chain.</div><div><br></div><div>Repl=
acement cycling attack seem to offer a new way to neutralize the design goa=
ls of package relay and its companion nversion=3D3 policy, where an attacke=
r package RBF a honest package out of the mempool to subsequently double-sp=
end 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.</div><div><br></div><div>A function=
al test exercising a simple replacement cycling of a lightning channel comm=
itment transaction on top of the nversion=3D3 code branch is available:</di=
v><div><a rel=3D"noreferrer nofollow noopener" href=3D"https://github.com/a=
riard/bitcoin/commits/2023-10-test-mempool-2" target=3D"_blank">https://git=
hub.com/ariard/bitcoin/commits/2023-10-test-mempool-2</a><br></div><div><br=
></div><div>## Discovery</div><div><br></div><div>In 2018, the issue of sta=
tic fees for pre-signed lightning transactions is made more widely known, t=
he carve-out exemption in mempool rules to mitigate in-mempool package limi=
ts pinning and the anchor output pattern are proposed.</div><div><br></div>=
<div>In 2019, bitcoin core 0.19 is released with carve-out support. Continu=
ed discussion of the anchor output pattern as a dynamic fee-bumping method.=
</div><div><br></div><div>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-overl=
ay network or package-relay as mitigations. Public call made to inquiry mor=
e on potential other transaction-relay jamming attacks affecting lightning.=
</div><div><br></div><div>In 2021, initial work in bitcoin core 22.0 of pac=
kage acceptance. Continued discussion of the pinning attacks and shortcomin=
gs of current mempool rules during community-wide online workshops. Later t=
he year, in light of all issues for bitcoin second-layers, a proposal is ma=
de about killing the mempool.</div><div><br></div><div>In 2022, bip propose=
d for package relay and new proposed v3 policy design proposed for a review=
 and implementation. Mempoolfullrbf is supported in bitcoin core 24.0 and c=
onceptual questions about alignment of mempool rules w.r.t miners incentive=
s are investigated.</div><div><br></div><div>Along this year 2022, eltoo li=
ghtning channels design are discussed, implemented and reviewed. In this co=
ntext and after discussions on mempool anti-DoS rules, I discovered this ne=
w replacement cycling attack was affecting deployed lightning channels and =
immediately reported the finding to some bitcoin core developers and lightn=
ing maintainers.</div><div><br></div><div>## Timeline</div><div><br></div><=
div>- 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns, Gr=
eg Sanders and Gloria Zhao</div><div>- 2022-12-16: Report to LN maintainers=
: Rusty Russell, Bastien Teinturier, Matt Corallo and Olaoluwa Osuntunkun</=
div><div>- 2022-12-23: Sharing to Eugene Siegel (LND)</div><div>- 2022-12-2=
4: Sharing to James O&#39;Beirne and Antoine Poinsot (non-lightning potenti=
al affected projects)</div><div>- 2022-01-14: Sharing to Gleb Naumenko (min=
ers incentives and cross-layers issuers) and initial proposal of an early p=
ublic disclosure </div><div>- 2022-01-19: Collection of analysis if other s=
econd-layers and multi-party applications affected. LN mitigations developm=
ent starts.</div><div>- 2023-05-04: Sharing to Wilmer Paulino (LDK)</div><d=
iv>- 2023-06-20: LN mitigations implemented and progressively released. Wee=
k of the 16 october proposed for full disclosure.</div><div>- 2023-08-10: C=
VEs assigned by MITRE</div><div>- 2023-10-05: Pre-disclosure of LN CVEs num=
bers and replacement cycling attack existence to <a rel=3D"noreferrer nofol=
low noopener" href=3D"mailto:security@bitcoincore.org" target=3D"_blank">se=
curity@bitcoincore.org</a>.</div><div>- 2023-10-16: Full disclosure of CVE-=
2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 and replaceme=
nt cycling attacks</div><div><br></div><div>## Conclusion </div><div><br></=
div><div>Despite the line of mitigations adopted and deployed by current ma=
jor 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 whi=
ch have been working for years as a community.</div><div><br></div><div>As =
of today, it is uncertain to me if lightning is not affected by a more seve=
re long-term package malleability critical security issue under current con=
sensus rules, and if any other time-sensitive multi-party protocol, designe=
d or deployed isn&#39;t de facto affected too (loss of funds or denial of s=
ervice).</div><div><br></div><div>Assuming analysis on package malleability=
 is correct, it is unclear to me if it can be corrected by changes in repla=
cement / eviction rules or mempool chain of transactions processing strateg=
y. Inviting my technical peers and the bitcoin community to look more on th=
is issue, including to dissent. I&#39;ll be the first one pleased if I&#39;=
m fundamentally wrong on those issues, or if any element has not been weigh=
ted with the adequate 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>Antoine</div><div><br></div><div>&quot;meet with Triumph and =
Disaster. And treat those two impostors just the same&quot; - K.</div></div=
>

        </blockquote><br>
    </div></blockquote></div>

--0000000000009c40a40607ed1d27--