path: root/cf/d8f6e4146eb4e1925e657aa74cb1d5b19da361

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 9CF32C0032;
 Thu, 19 Oct 2023 19:33:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 7B78643138;
 Thu, 19 Oct 2023 19:33:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 7B78643138
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=AFOqFTWp
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 mftIm11NGkjb; Thu, 19 Oct 2023 19:33:35 +0000 (UTC)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com
 [IPv6:2607:f8b0:4864:20::d2b])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 158ED4312E;
 Thu, 19 Oct 2023 19:33:34 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 158ED4312E
Received: by mail-io1-xd2b.google.com with SMTP id
 ca18e2360f4ac-79fa5d9f3a2so2640839f.3; 
 Thu, 19 Oct 2023 12:33:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1697744014; x=1698348814;
 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=HbklPScFaQd+2POaV7kXPLFBZmNDLKtu8tyOdi6FPiY=;
 b=AFOqFTWpqAoC3FOfKRl8KKr5dA7fzZSJf601VfxO96CAWdjLRnHKkjtVym2UVdrXa0
 fPsHf+St/+hD1np2Ru3MOUmUc5/RbyB+hKK3boscb6QvZ7g9vRn/C7DpyTtjHUQXCPwT
 AbOvD+w8mx486CiyVJz3tNzf9aj1e/M9SDAhtGPNJ1Tdepqc7Xdgt13C0+rGlEXnI3Mk
 Qy7qXFmbcTzmT0XgXzrHbwSyGI0S1u98jFbeSeguHIqKZHyYBTI1+9TH8fi7rb3eIOU8
 SWgK4vPxKsuxRY5TVGQyfVcoTLMBc/wAr1OAmT/V9hn0n3anuH0LLzkwLemSF+8tIiiS
 xnDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1697744014; x=1698348814;
 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=HbklPScFaQd+2POaV7kXPLFBZmNDLKtu8tyOdi6FPiY=;
 b=ndoybhz0ZhgnxOGkyVrJu5UXSs10frBQzvdMBZKnmQL3yvSb/IaQFg7v5dJaN2Hi/S
 UPjQHI+QCum2ZT+u8d0CrDoIZe5CnQyFhRgu8xZWa/Gfcr5jnOksLvmHMV6ifkWOXQi6
 +b9rdThyrADxxJkQEckkJgTRdKkcL6LrSfBOIO8ha008LWDK8KzigAEBiKiVGo5Dt2j0
 zujOauG/8pk74BuhCNAL0wb/BO6Rw9z9ZJqwx/a6pUYK3RqCzXFgr51SbaMo5sTi6QUY
 9H+SVZB1RGcXo2yjAmJ4yRF7K49eOczxibvWMhffjfkoWXhP0YpskYQrkFvt7bepQXRu
 XPKQ==
X-Gm-Message-State: AOJu0Yzu3SJVEpbq4syNixtEpUGj6VWoIrHH1Y6RYqHEx/RIlZmPD2mf
 BPTAsc+8dyBwApsCKgXOzXy14iTq2WpP0Mjfr+o=
X-Google-Smtp-Source: AGHT+IHwFWmb/qv5cRsL7V+NRTY1l2wLtDIKary4Xpdk5zzxZUajJlvupETYxDNdkorMaPK2QdQio/WgLzBL3I4SgUs=
X-Received: by 2002:a05:6602:27d4:b0:792:82f8:749d with SMTP id
 l20-20020a05660227d400b0079282f8749dmr3655055ios.10.1697744013634; Thu, 19
 Oct 2023 12:33:33 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <ece6f28b-5b14-4f9c-a115-945082a63d68@mattcorallo.com>
 <CAGyamEWnSNAwJ1HpcgiYtNYwUqWOBn7RzhfR_W8460B_9n=qng@mail.gmail.com>
 <CALZpt+GaLGk_Yrnb9+CNm6psLdtiqw_DBkQt+gg8FGh87uN+0Q@mail.gmail.com>
 <CAGyamEXk6rNnFE1wztpbHqZVH_acN5AYb0Y7F2n2Nou1d_wdUA@mail.gmail.com>
In-Reply-To: <CAGyamEXk6rNnFE1wztpbHqZVH_acN5AYb0Y7F2n2Nou1d_wdUA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 19 Oct 2023 20:33:22 +0100
Message-ID: <CALZpt+FaYop1J5Zi=42F4jCScfiPL3AZ98HWtW82Qd8ZQG=aMg@mail.gmail.com>
To: Matt Morehouse <mattmorehouse@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000da31e3060816d4d7"
X-Mailman-Approved-At: Thu, 19 Oct 2023 21:52:02 +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: Thu, 19 Oct 2023 19:33:39 -0000

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

> As the CLTV
> delta deadline approaches, the fees in case 2 may be 50%, 80%, even
> 100% of the HTLC value under such a scorched earth policy.

A replacement-cycling attacker can afford to pay 100% of the HTLC value
under the defender scorched earth policy and still realize an economic gain=
.

Let's say you have Alice, Bob and Caroll all "honest" routing hops targeted
by an attacker. They all have 3 independent 10 000 sats HTLC in-flight on
their outbound channels.

Under this defensive fee scorched earth policy, Alice broadcasts her
HTLC-timeout at T + 1 with 10 000 sats committed as absolute fee.

It is replaced by Mallory at T+2 with a HTLC-preimage X of 200 000 sats (+
rbf penalty 1 sat / vb rule 4). Alice's HTLC-timeout is out of network
mempools.

Bob broadcasts her HTLC-timeout of 200 000 sats at T+3. It is replaced by
Mallory at T+4 with her HLTC-preimage Y of 200 000 sats (+ rbf penalty 1
sat / vb rule 4 * 2). Bob's HTLC-timeout is out of network mempools.
HTLC-preimage Y conflicts with HTLC-preimage X too (here comes the
multiplied by 2 of the rbf penalty).

Caroll broadcasts her HTLC-timeout of 200 000 sats at T+5. It is replaced
by Mallory at T+6 with her HTLC-preimage Z of 200 000 sats (+rbf penalty 1
sat / vb rule 4 * 3). Caroll's HTLC-timeout is out of network mempools.
HTLC-preimage Z conflicts with HTLC-preimage Z too (here comes the
multiplied by 3 of rbf penalty).

At any time if Mallory's HTLC-preimage enters into the top mempool feerates
group (due to the accumulated rbf penalty), one unconfirmed ancestor can be
double-spent to evict out the HTLC-preimage.

If Mallory succeeds the replacement cycling, she might be at loss of 10 000
sats + rbf penalty cost for each rebroadcast attempt of the victim. However
she wins Alice + Bob + Carol HTLC value of 200 000 sats each.

Assuming 5 rebroadcasts per block (even on random timers) multiplied by 3
victims, 200 bytes of HTLC-preimage and cltv_delta of 144 blocks, the total
attacker cost is 432 000 sats.

The economic gain realized is 168 000 sats. Sounds each additional victim
has a cost of 144 000 sats, whatever the HTLC value targeted.

Thanks for checking the fees math and replacement rules, though it sounds
correct to me.

(And here without introducing more favorable assumptions to the attacker,
like mempool spikes where the "honest" HTLC-timeout transactions can be let
floating in network mempools).

Best,
Antoine

Le jeu. 19 oct. 2023 =C3=A0 18:54, Matt Morehouse <mattmorehouse@gmail.com>=
 a
=C3=A9crit :

> On Thu, Oct 19, 2023 at 5:22=E2=80=AFPM Antoine Riard <antoine.riard@gmai=
l.com>
> wrote:
> >
> > Hi Matt,
> >
> > This mitigation is mentioned in the attached paper (see subsection 3.4
> defensive fee-rebroadcasting)
> >
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper=
/replacement-cycling.pdf
> >
> > As soon as you start to have a bit of a mempool backlog and the
> defensive fractional fee HTLC-timeout stays stuck, it gives the advantage
> to the attacker again.
> >
> > Beyond that, I think an attacker can replace-cycle multiple honest
> HTLC-timeout with a single malicious HTLC-preimage (with a sequence of
> replacement, not concurrently) paying the absolute fee, while only
> encumbering the RBF penalty. I didn't test this specific behavior, though
> the "fees" math doesn't seem at the advantage of the defenders at first
> sight.
>
> Right, some replacement cycles can be avoided by the attacker to
> reduce the cost of the attack.  But with the defender implementing a
> scorched-earth fee bumping policy, eventually either (1) the
> HTLC-timeout *will* confirm in the next block or (2) the attacker must
> pay more fees than the HTLC-timeout fees to replace it.  As the CLTV
> delta deadline approaches, the fees in case 2 may be 50%, 80%, even
> 100% of the HTLC value under such a scorched earth policy.  So even if
> the attacker only has to do one replacement cycle right before the
> deadline, the attack can be made unprofitable.  And in practice, with
> HTLC values significantly greater than the next-block fee cost, the
> attacker will need to do multiple replacements as the deadline
> approaches.
>
> And of course this linear scorched earth policy is just an
> illustration.  We should further tune the fee bumping curve across the
> full CLTV delta to ensure minimal fees paid when not under attack.
> But as we approach the deadline, it makes sense to become very
> aggressive both to get our transaction confirmed during high mempool
> congestion and to punish replacement-cycling attackers.
>
> >
> > Best,
> > Antoine
> >
> > Le jeu. 19 oct. 2023 =C3=A0 17:23, Matt Morehouse <mattmorehouse@gmail.=
com>
> a =C3=A9crit :
> >>
> >> On Wed, Oct 18, 2023 at 12:34=E2=80=AFAM Matt Corallo via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> >
> >> > There appears to be some confusion about this issue and the
> mitigations. To be clear, the deployed
> >> > mitigations are not expected to fix this issue, its arguable if they
> provide anything more than a PR
> >> > statement.
> >> >
> >> > There are two discussed mitigations here - mempool scanning and
> transaction re-signing/re-broadcasting.
> >> >
> >> > Mempool scanning relies on regularly checking the mempool of a local
> node to see if we can catch the
> >> > replacement cycle mid-cycle. It only works if wee see the first
> transaction before the second
> >> > transaction replaces it.
> >> >
> >> > Today, a large majority of lightning nodes run on machines with a
> Bitcoin node on the same IP
> >> > address, making it very clear what the "local node" of the lightning
> node is. An attacker can
> >> > trivially use this information to connect to said local node and do
> the replacement quickly,
> >> > preventing the victim from seeing the replacement.
> >> >
> >> > More generally, however, similar discoverability is true for mining
> pools. An attacker performing
> >> > this attack is likely to do the replacement attack on a miner's node
> directly, potentially reducing
> >> > the reach of the intermediate transaction to only miners, such that
> the victim can never discover it
> >> > at all.
> >> >
> >> > The second mitigation is similarly pathetic. Re-signing and
> re-broadcasting the victim's transaction
> >> > in an attempt to get it to miners even if its been removed may work,
> if the attacker is super lazy
> >> > and didn't finish writing their attack system. If the attacker is
> connected to a large majority of
> >> > hashrate (which has historically been fairly doable), they can simpl=
y
> do their replacement in a
> >> > cycle aggressively and arbitrarily reduce the probability that the
> victim's transaction gets confirmed.
> >>
> >> What if the honest node aggressively fee-bumps and retransmits the
> >> HTLC-timeout as the CLTV delta deadline approaches, as suggested by
> >> Ziggie?  Say, within 10 blocks of the deadline, the honest node starts
> >> increasing the fee by 1/10th the HTLC value for each non-confirmation.
> >>
> >> This "scorched earth" approach may cost the honest node considerable
> >> fees, but it will cost the attacker even more, since each attacker
> >> replacement needs to burn at least as much as the HTLC-timeout fees,
> >> and the attacker will need to do a replacement every time the honest
> >> node fee bumps.
> >>
> >> I think this fee-bumping policy will provide sufficient defense even
> >> if the attacker is replacement-cycling directly in miners' mempools
> >> and the victim has no visibility into the attack.
> >>
> >> >
> >> > Now, the above is all true in a spherical cow kinda world, and the
> P2P network has plenty of slow
> >> > nodes and strange behavior. Its possible that these mitigations
> might, by some stroke of luck,
> >> > happen to catch such an attack and prevent it, because something too=
k
> longer than the attacker
> >> > intended or whatever. But, that's a far cry from any kind of materia=
l
> "fix" for the issue.
> >> >
> >> > Ultimately the only fix for this issue will be when miners keep a
> history of transactions they've
> >> > seen and try them again after they may be able to enter the mempool
> because of an attack like this.
> >> >
> >> > Matt
> >> >
> >> > On 10/16/23 12:57 PM, Antoine Riard wrote:
> >> > > (cross-posting mempool issues identified are exposing lightning
> chan to loss of funds risks, other
> >> > > multi-party bitcoin apps might be affected)
> >> > >
> >> > > Hi,
> >> > >
> >> > > End of last year (December 2022), amid technical discussions on
> eltoo payment channels and
> >> > > incentives compatibility of the mempool anti-DoS rules, a new
> transaction-relay jamming attack
> >> > > affecting lightning channels was discovered.
> >> > >
> >> > > After careful analysis, it turns out this attack is practical and
> immediately exposed lightning
> >> > > routing hops carrying HTLC traffic to loss of funds security risks=
,
> both legacy and anchor output
> >> > > channels. A potential exploitation plausibly happening even withou=
t
> 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 full disclosure report using
> >> > > bitcoin script timelocks or multi-party transactions, albeit no
> immediate security risk exposure as
> >> > > severe as the ones affecting lightning has been identified. Only
> cursory review of non-lightning
> >> > > applications has been conducted so far.
> >> > >
> >> > > There is a paper published summarizing replacement cycling attacks
> on the lightning network:
> >> > >
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper=
/replacement-cycling.pdf
> >> > > <
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper=
/replacement-cycling.pdf
> >
> >> > >
> >> > >   ## Problem
> >> > >
> >> > > A lightning node allows HTLCs forwarding (in bolt3's parlance
> accepted HTLC on incoming link and
> >> > > offered HTLC on outgoing link) should settle the outgoing state
> with either a success or timeout
> >> > > before the incoming state timelock becomes final and an asymmetric
> defavorable settlement might
> >> > > happen (cf "Flood & Loot: A Systematic Attack on The Lightning
> Network" section 2.3 for a classical
> >> > > exposition of this lightning security property).
> >> > >
> >> > > Failure to satisfy this settlement requirement exposes a forwardin=
g
> hop to a loss of fund risk where
> >> > > the offered HTLC is spent by the outgoing link counterparty's
> HTLC-preimage and the accepted HTLC is
> >> > > spent by the incoming link counterparty's HTLC-timeout.
> >> > >
> >> > > The specification mandates the incoming HTLC expiration timelock t=
o
> be spaced out by an interval of
> >> > > `cltv_expiry_delta` from the outgoing HTLC expiration timelock,
> this exact interval value being an
> >> > > implementation and node policy setting. As a minimal value, the
> specification recommends 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 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 height is reached.
> >> > >
> >> > > Here enter a replacement cycling attack. A malicious channel
> counterparty can broadcast its
> >> > > HTLC-preimage transaction with a higher absolute fee and higher
> feerate than the honest HTLC-timeout
> >> > > of the victim lightning node and triggers a replacement. Both for
> legacy and anchor output channels,
> >> > > a HTLC-preimage on a counterparty commitment transaction is
> malleable, i.e additional inputs or
> >> > > outputs can be added. The HTLC-preimage spends an unconfirmed and
> unrelated to the channel parent
> >> > > transaction M and conflicts its child.
> >> > >
> >> > > As the HTLC-preimage spends an unconfirmed input that was already
> included in the unconfirmed and
> >> > > unrelated child transaction (rule 2), pays an absolute higher fee
> of at least the sum paid by the
> >> > > HTLC-timeout and child transaction (rule 3) and the HTLC-preimage
> feerate is greater than all
> >> > > directly conflicting transactions (rule 6), the replacement is
> accepted. The honest HTLC-timeout is
> >> > > evicted out of the mempool.
> >> > >
> >> > > In an ulterior move, the malicious counterparty can replace the
> 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-timeout is broadcast by the counterparty's on the
> incoming link in collusion with the
> >> > > one on the outgoing link broadcasting its own HTLC-preimage.
> >> > >
> >> > > The honest Lightning node has been "double-spent" in its HTLC
> forwarding.
> >> > >
> >> > > As a notable factor impacting the success of the attack, a
> lightning node's honest HTLC-timeout
> >> > > might be included in the block template of the miner winning the
> block race and therefore realizes a
> >> > > spent of the offered 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 by economically competitive miners.
> >> > >
> >> > > A functional test exercising a simple replacement cycling of a HTL=
C
> transaction on bitcoin core
> >> > > mempool is available:
> >> > > https://github.com/ariard/bitcoin/commits/2023-test-mempool
> >> > > <https://github.com/ariard/bitcoin/commits/2023-test-mempool>
> >> > >
> >> > > ## Deployed LN mitigations
> >> > >
> >> > > Aggressive rebroadcasting: As the replacement cycling attacker
> benefits from the HTLC-timeout being
> >> > > usually broadcast by lightning nodes only once every block, or les=
s
> the replacement cycling
> >> > > malicious transactions paid only equal the sum of the absolute fee=
s
> paid by the HTLC, adjusted with
> >> > > the replacement penalty. Rebroadcasting randomly and multiple time=
s
> before the next block increases
> >> > > the absolute fee cost for the attacker.
> >> > >
> >> > > Implemented and deployed by Eclair, Core-Lightning, LND and LDK .
> >> > >
> >> > > Local-mempool preimage monitoring: As the replacement cycling
> attacker in a simple setup broadcast
> >> > > the HTLC-preimage to all the network mempools, the honest lightnin=
g
> node is able to catch on the
> >> > > flight the unconfirmed HTLC-preimage, before its subsequent mempoo=
l
> replacement. The preimage can be
> >> > > extracted from the second-stage HTLC-preimage and used to fetch th=
e
> off-chain inbound HTLC with a
> >> > > cooperative message or go on-chain with it to claim the accepted
> HTLC output.
> >> > >
> >> > > Implemented and deployed by Eclair and LND.
> >> > >
> >> > > CLTV Expiry Delta: With every jammed block comes an absolute fee
> cost paid by the attacker, a risk
> >> > > of the HTLC-preimage being detected or discovered by the honest
> lightning node, or the HTLC-timeout
> >> > > to slip in a winning block template. Bumping the default CLTV delt=
a
> hardens the odds of success of a
> >> > > simple replacement cycling attack.
> >> > >
> >> > > Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72.
> >> > >
> >> > > ## Affected Bitcoin Protocols and Applications
> >> > >
> >> > >  From my understanding the following list of Bitcoin protocols and
> applications could be affected by
> >> > > new denial-of-service vectors under some level of network mempools
> congestion. Neither tests or
> >> > > advanced review of specifications (when available) has been
> conducted for each of them:
> >> > > - on-chain DLCs
> >> > > - coinjoins
> >> > > - payjoins
> >> > > - wallets with time-sensitive paths
> >> > > - peerswap and submarine swaps
> >> > > - batch payouts
> >> > > - transaction "accelerators"
> >> > >
> >> > > Inviting their developers, maintainers and operators to investigat=
e
> how replacement cycling attacks
> >> > > might disrupt their in-mempool chain of transactions, or
> fee-bumping flows at the shortest delay.
> >> > > Simple flows and non-multi-party transactions should not be
> affected to the best of my understanding.
> >> > >
> >> > > ## Open Problems: Package Malleability
> >> > >
> >> > > Pinning attacks have been known for years as a practical vector to
> compromise lightning channels
> >> > > funds safety, under different scenarios (cf. current bip331's
> motivation section). Mitigations at
> >> > > the mempool level have been designed, discussed and are under
> implementation by the community
> >> > > (ancestor package relay + nverrsion=3D3 policy). Ideally, they sho=
uld
> constraint a pinning attacker to
> >> > > always attach a high feerate package (commitment + CPFP) to replac=
e
> the honest package, or allow a
> >> > > honest lightning node to overbid a malicious pinning package and
> get its time-sensitive transaction
> >> > > optimistically included in the chain.
> >> > >
> >> > > Replacement cycling attack seem to offer a new way to neutralize
> the design goals of package relay
> >> > > and its companion nversion=3D3 policy, where an attacker package R=
BF
> 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 wit=
h
> 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
> >> > > <https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2>
> >> > >
> >> > > ## Discovery
> >> > >
> >> > > In 2018, the issue of static fees for pre-signed lightning
> transactions is made more widely known,
> >> > > the carve-out exemption in mempool rules to mitigate in-mempool
> package limits pinning and the
> >> > > anchor output pattern are proposed.
> >> > >
> >> > > In 2019, bitcoin core 0.19 is released with carve-out support.
> Continued discussion of the anchor
> >> > > output pattern as a dynamic fee-bumping method.
> >> > >
> >> > > In 2020, draft of anchor output submitted to the bolts. Initial
> finding of economic pinning against
> >> > > lightning commitment and second-stage HTLC transactions. Subsequen=
t
> discussions of a
> >> > > preimage-overlay network or package-relay as mitigations. Public
> call made to inquiry more on
> >> > > potential other transaction-relay jamming attacks affecting
> lightning.
> >> > >
> >> > > In 2021, initial work in bitcoin core 22.0 of package acceptance.
> Continued discussion of the
> >> > > pinning attacks and shortcomings of current mempool rules during
> community-wide online workshops.
> >> > > Later the year, in light of all issues for bitcoin second-layers, =
a
> proposal is made about killing
> >> > > the mempool.
> >> > >
> >> > > In 2022, bip proposed for package relay and new proposed v3 policy
> design proposed for a review and
> >> > > implementation. Mempoolfullrbf is supported in bitcoin core 24.0
> and conceptual questions about
> >> > > alignment of mempool rules w.r.t miners incentives are investigate=
d.
> >> > >
> >> > > Along this year 2022, eltoo lightning channels design are
> discussed, implemented and reviewed. In
> >> > > this context and after discussions on mempool anti-DoS rules, I
> discovered this new replacement
> >> > > cycling attack was affecting deployed lightning channels and
> immediately reported the finding to
> >> > > some bitcoin core developers and lightning maintainers.
> >> > >
> >> > > ## Timeline
> >> > >
> >> > > - 2022-12-16: Report of the finding to Suhas Daftuar, Anthony
> Towns, Greg Sanders and Gloria Zhao
> >> > > - 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien
> Teinturier, Matt Corallo and Olaoluwa
> >> > > Osuntunkun
> >> > > - 2022-12-23: Sharing to Eugene Siegel (LND)
> >> > > - 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot
> (non-lightning potential affected projects)
> >> > > - 2022-01-14: Sharing to Gleb Naumenko (miners incentives and
> cross-layers issuers) and initial
> >> > > proposal of an early public disclosure
> >> > > - 2022-01-19: Collection of analysis if other second-layers and
> multi-party applications affected.
> >> > > LN mitigations development starts.
> >> > > - 2023-05-04: Sharing to Wilmer Paulino (LDK)
> >> > > - 2023-06-20: LN mitigations implemented and progressively
> released. Week of the 16 october proposed
> >> > > for full disclosure.
> >> > > - 2023-08-10: CVEs assigned by MITRE
> >> > > - 2023-10-05: Pre-disclosure of LN CVEs numbers and replacement
> cycling attack existence to
> >> > > security@bitcoincore.org <mailto:security@bitcoincore.org>.
> >> > > - 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2023-40232 /
> CVE-2023-40233 / CVE-2023-40234
> >> > > and replacement cycling attacks
> >> > >
> >> > > ## Conclusion
> >> > >
> >> > > Despite the line of mitigations adopted and deployed by current
> major lightning implementations, I
> >> > > believe replacement cycling attacks are still practical for
> advanced attackers. Beyond this new
> >> > > attack might come as a way to partially or completely defeat some
> of the pinning mitigations which
> >> > > have been working for years as a community.
> >> > >
> >> > > As of today, it is uncertain to me if lightning is not affected by
> a more severe long-term package
> >> > > malleability critical security issue under current consensus rules=
,
> and if any other time-sensitive
> >> > > multi-party protocol, designed or deployed isn't de facto affected
> too (loss of funds or denial of
> >> > > service).
> >> > >
> >> > > Assuming analysis on package malleability is correct, it is unclea=
r
> 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 those issues, or if any element
> >> > > has not been weighted with the adequate technical 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 jus=
t
> the same" - K.
> >> > >
> >> > > _______________________________________________
> >> > > Lightning-dev mailing list
> >> > > Lightning-dev@lists.linuxfoundation.org
> >> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >> > _______________________________________________
> >> > bitcoin-dev mailing list
> >> > bitcoin-dev@lists.linuxfoundation.org
> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">&gt; As the CLTV<br>&gt; delta deadline approaches, the fe=
es in case 2 may be 50%, 80%, even<br>&gt; 100% of the HTLC value under suc=
h a scorched earth policy.<br><div><br></div><div>A replacement-cycling att=
acker can afford to pay 100% of the HTLC value under the defender scorched =
earth policy and still realize an economic gain.</div><div><br></div><div>L=
et&#39;s say you have Alice, Bob and Caroll=C2=A0all &quot;honest&quot; rou=
ting hops targeted by an attacker. They all have 3 independent 10 000 sats =
HTLC in-flight on their outbound channels.</div><div><br></div><div>Under t=
his defensive fee scorched earth policy, Alice broadcasts her HTLC-timeout =
at T=C2=A0+ 1 with 10 000 sats committed as absolute fee.</div><div><br></d=
iv><div>It is replaced by Mallory at T+2 with a HTLC-preimage X of 200 000 =
sats (+ rbf penalty 1 sat / vb rule 4). Alice&#39;s HTLC-timeout is out of =
network mempools.</div><div><br></div><div>Bob broadcasts her HTLC-timeout =
of 200 000 sats at T+3. It is replaced by Mallory at T+4 with her HLTC-prei=
mage Y of 200 000 sats (+ rbf penalty 1 sat / vb rule 4 * 2). Bob&#39;s HTL=
C-timeout is out of network mempools. HTLC-preimage Y conflicts with HTLC-p=
reimage X too (here comes the multiplied by 2 of the rbf penalty).</div><di=
v><br></div><div>Caroll broadcasts her HTLC-timeout of 200 000 sats at T+5.=
 It is replaced by Mallory at T+6 with her HTLC-preimage Z of 200 000 sats =
(+rbf penalty 1 sat / vb rule 4 * 3). Caroll&#39;s HTLC-timeout is out of n=
etwork mempools. HTLC-preimage Z conflicts with HTLC-preimage Z too (here c=
omes the multiplied by 3 of rbf penalty).</div><div><br></div><div>At any t=
ime if Mallory&#39;s HTLC-preimage enters into the top mempool feerates gro=
up (due to the accumulated rbf penalty), one unconfirmed ancestor can be do=
uble-spent to evict out the HTLC-preimage.</div><div><br></div><div>If Mall=
ory succeeds the replacement cycling, she might be at loss of 10 000 sats=
=C2=A0+ rbf penalty cost for each rebroadcast attempt of the victim. Howeve=
r she wins Alice=C2=A0+ Bob=C2=A0+ Carol HTLC value of 200 000 sats each.</=
div><div><br></div><div>Assuming 5 rebroadcasts per block (even on random t=
imers) multiplied by 3 victims, 200 bytes of HTLC-preimage and cltv_delta o=
f 144 blocks, the total attacker cost is 432 000 sats.</div><div><br></div>=
<div>The economic gain realized is 168 000 sats. Sounds each additional vic=
tim has a cost of 144 000 sats, whatever the HTLC value targeted.</div><div=
><br></div><div>Thanks for checking the fees math and replacement rules, th=
ough it sounds correct to me.</div><div><br></div><div>(And here without in=
troducing more favorable assumptions to the attacker, like mempool spikes w=
here the &quot;honest&quot; HTLC-timeout transactions can be let floating i=
n network mempools).</div><div><br></div><div>Best,</div><div>Antoine</div>=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
Le=C2=A0jeu. 19 oct. 2023 =C3=A0=C2=A018:54, Matt Morehouse &lt;<a href=3D"=
mailto:mattmorehouse@gmail.com">mattmorehouse@gmail.com</a>&gt; a =C3=A9cri=
t=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:=
rgb(204,204,204);padding-left:1ex">On Thu, Oct 19, 2023 at 5:22=E2=80=AFPM =
Antoine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com" target=3D"_bla=
nk">antoine.riard@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi Matt,<br>
&gt;<br>
&gt; This mitigation is mentioned in the attached paper (see subsection 3.4=
 defensive fee-rebroadcasting)<br>
&gt; <a href=3D"https://github.com/ariard/mempool-research/blob/2023-10-rep=
lacement-paper/replacement-cycling.pdf" rel=3D"noreferrer" target=3D"_blank=
">https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper=
/replacement-cycling.pdf</a><br>
&gt;<br>
&gt; As soon as you start to have a bit of a mempool backlog and the defens=
ive fractional fee HTLC-timeout stays stuck, it gives the advantage to the =
attacker again.<br>
&gt;<br>
&gt; Beyond that, I think an attacker can replace-cycle multiple honest HTL=
C-timeout with a single malicious HTLC-preimage (with a sequence of replace=
ment, not concurrently) paying the absolute fee, while only encumbering the=
 RBF penalty. I didn&#39;t test this specific behavior, though the &quot;fe=
es&quot; math doesn&#39;t seem at the advantage of the defenders at first s=
ight.<br>
<br>
Right, some replacement cycles can be avoided by the attacker to<br>
reduce the cost of the attack.=C2=A0 But with the defender implementing a<b=
r>
scorched-earth fee bumping policy, eventually either (1) the<br>
HTLC-timeout *will* confirm in the next block or (2) the attacker must<br>
pay more fees than the HTLC-timeout fees to replace it.=C2=A0 As the CLTV<b=
r>
delta deadline approaches, the fees in case 2 may be 50%, 80%, even<br>
100% of the HTLC value under such a scorched earth policy.=C2=A0 So even if=
<br>
the attacker only has to do one replacement cycle right before the<br>
deadline, the attack can be made unprofitable.=C2=A0 And in practice, with<=
br>
HTLC values significantly greater than the next-block fee cost, the<br>
attacker will need to do multiple replacements as the deadline<br>
approaches.<br>
<br>
And of course this linear scorched earth policy is just an<br>
illustration.=C2=A0 We should further tune the fee bumping curve across the=
<br>
full CLTV delta to ensure minimal fees paid when not under attack.<br>
But as we approach the deadline, it makes sense to become very<br>
aggressive both to get our transaction confirmed during high mempool<br>
congestion and to punish replacement-cycling attackers.<br>
<br>
&gt;<br>
&gt; Best,<br>
&gt; Antoine<br>
&gt;<br>
&gt; Le jeu. 19 oct. 2023 =C3=A0 17:23, Matt Morehouse &lt;<a href=3D"mailt=
o:mattmorehouse@gmail.com" target=3D"_blank">mattmorehouse@gmail.com</a>&gt=
; a =C3=A9crit :<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Oct 18, 2023 at 12:34=E2=80=AFAM Matt Corallo via bitcoin-=
dev<br>
&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; There appears to be some confusion about this issue and the m=
itigations. To be clear, the deployed<br>
&gt;&gt; &gt; mitigations are not expected to fix this issue, its arguable =
if they provide anything more than a PR<br>
&gt;&gt; &gt; statement.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; There are two discussed mitigations here - mempool scanning a=
nd transaction re-signing/re-broadcasting.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Mempool scanning relies on regularly checking the mempool of =
a local node to see if we can catch the<br>
&gt;&gt; &gt; replacement cycle mid-cycle. It only works if wee see the fir=
st transaction before the second<br>
&gt;&gt; &gt; transaction replaces it.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Today, a large majority of lightning nodes run on machines wi=
th a Bitcoin node on the same IP<br>
&gt;&gt; &gt; address, making it very clear what the &quot;local node&quot;=
 of the lightning node is. An attacker can<br>
&gt;&gt; &gt; trivially use this information to connect to said local node =
and do the replacement quickly,<br>
&gt;&gt; &gt; preventing the victim from seeing the replacement.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; More generally, however, similar discoverability is true for =
mining pools. An attacker performing<br>
&gt;&gt; &gt; this attack is likely to do the replacement attack on a miner=
&#39;s node directly, potentially reducing<br>
&gt;&gt; &gt; the reach of the intermediate transaction to only miners, suc=
h that the victim can never discover it<br>
&gt;&gt; &gt; at all.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The second mitigation is similarly pathetic. Re-signing and r=
e-broadcasting the victim&#39;s transaction<br>
&gt;&gt; &gt; in an attempt to get it to miners even if its been removed ma=
y work, if the attacker is super lazy<br>
&gt;&gt; &gt; and didn&#39;t finish writing their attack system. If the att=
acker is connected to a large majority of<br>
&gt;&gt; &gt; hashrate (which has historically been fairly doable), they ca=
n simply do their replacement in a<br>
&gt;&gt; &gt; cycle aggressively and arbitrarily reduce the probability tha=
t the victim&#39;s transaction gets confirmed.<br>
&gt;&gt;<br>
&gt;&gt; What if the honest node aggressively fee-bumps and retransmits the=
<br>
&gt;&gt; HTLC-timeout as the CLTV delta deadline approaches, as suggested b=
y<br>
&gt;&gt; Ziggie?=C2=A0 Say, within 10 blocks of the deadline, the honest no=
de starts<br>
&gt;&gt; increasing the fee by 1/10th the HTLC value for each non-confirmat=
ion.<br>
&gt;&gt;<br>
&gt;&gt; This &quot;scorched earth&quot; approach may cost the honest node =
considerable<br>
&gt;&gt; fees, but it will cost the attacker even more, since each attacker=
<br>
&gt;&gt; replacement needs to burn at least as much as the HTLC-timeout fee=
s,<br>
&gt;&gt; and the attacker will need to do a replacement every time the hone=
st<br>
&gt;&gt; node fee bumps.<br>
&gt;&gt;<br>
&gt;&gt; I think this fee-bumping policy will provide sufficient defense ev=
en<br>
&gt;&gt; if the attacker is replacement-cycling directly in miners&#39; mem=
pools<br>
&gt;&gt; and the victim has no visibility into the attack.<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Now, the above is all true in a spherical cow kinda world, an=
d the P2P network has plenty of slow<br>
&gt;&gt; &gt; nodes and strange behavior. Its possible that these mitigatio=
ns might, by some stroke of luck,<br>
&gt;&gt; &gt; happen to catch such an attack and prevent it, because someth=
ing took longer than the attacker<br>
&gt;&gt; &gt; intended or whatever. But, that&#39;s a far cry from any kind=
 of material &quot;fix&quot; for the issue.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Ultimately the only fix for this issue will be when miners ke=
ep a history of transactions they&#39;ve<br>
&gt;&gt; &gt; seen and try them again after they may be able to enter the m=
empool because of an attack like this.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Matt<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On 10/16/23 12:57 PM, Antoine Riard wrote:<br>
&gt;&gt; &gt; &gt; (cross-posting mempool issues identified are exposing li=
ghtning chan to loss of funds risks, other<br>
&gt;&gt; &gt; &gt; multi-party bitcoin apps might be affected)<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Hi,<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; End of last year (December 2022), amid technical discuss=
ions on eltoo payment channels and<br>
&gt;&gt; &gt; &gt; incentives compatibility of the mempool anti-DoS rules, =
a new transaction-relay jamming attack<br>
&gt;&gt; &gt; &gt; affecting lightning channels was discovered.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; After careful analysis, it turns out this attack is prac=
tical and immediately exposed lightning<br>
&gt;&gt; &gt; &gt; routing hops carrying HTLC traffic to loss of funds secu=
rity risks, both legacy and anchor output<br>
&gt;&gt; &gt; &gt; channels. A potential exploitation plausibly happening e=
ven without network mempools congestion.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Mitigations have been designed, implemented and deployed=
 by all major lightning implementations<br>
&gt;&gt; &gt; &gt; during the last months.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Please find attached the release numbers, where the miti=
gations should be present:<br>
&gt;&gt; &gt; &gt; - LDK: v0.0.118 - CVE-2023 -40231<br>
&gt;&gt; &gt; &gt; - Eclair: v0.9.0 - CVE-2023-40232<br>
&gt;&gt; &gt; &gt; - LND: v.0.17.0-beta - CVE-2023-40233<br>
&gt;&gt; &gt; &gt; - Core-Lightning: v.23.08.01 - CVE-2023-40234<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; While neither replacement cycling attacks have been obse=
rved or reported in the wild since the last<br>
&gt;&gt; &gt; &gt; ~10 months or experimented in real-world conditions on b=
itcoin mainet, functional test is available<br>
&gt;&gt; &gt; &gt; exercising the affected lightning channel against bitcoi=
n core mempool (26.0 release cycle).<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; It is understood that a simple replacement cycling attac=
k does not demand privileged capabilities<br>
&gt;&gt; &gt; &gt; from an attacker (e.g no low-hashrate power) and only ac=
cess to basic bitcoin and lightning<br>
&gt;&gt; &gt; &gt; software. Yet I still think executing such an attack suc=
cessfully requests a fair amount of bitcoin<br>
&gt;&gt; &gt; &gt; technical know-how and decent preparation.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt;=C2=A0 From my understanding of those issues, it is yet t=
o be determined if the mitigations deployed are<br>
&gt;&gt; &gt; &gt; robust enough in face of advanced replacement cycling at=
tackers, especially ones able to combine<br>
&gt;&gt; &gt; &gt; different classes of transaction-relay jamming such as p=
innings or vetted with more privileged<br>
&gt;&gt; &gt; &gt; capabilities.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Please find a list of potential affected bitcoin applica=
tions in this full disclosure report using<br>
&gt;&gt; &gt; &gt; bitcoin script timelocks or multi-party transactions, al=
beit no immediate security risk exposure as<br>
&gt;&gt; &gt; &gt; severe as the ones affecting lightning has been identifi=
ed. Only cursory review of non-lightning<br>
&gt;&gt; &gt; &gt; applications has been conducted so far.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; There is a paper published summarizing replacement cycli=
ng attacks on the lightning network:<br>
&gt;&gt; &gt; &gt; <a href=3D"https://github.com/ariard/mempool-research/bl=
ob/2023-10-replacement-paper/replacement-cycling.pdf" rel=3D"noreferrer" ta=
rget=3D"_blank">https://github.com/ariard/mempool-research/blob/2023-10-rep=
lacement-paper/replacement-cycling.pdf</a><br>
&gt;&gt; &gt; &gt; &lt;<a href=3D"https://github.com/ariard/mempool-researc=
h/blob/2023-10-replacement-paper/replacement-cycling.pdf" rel=3D"noreferrer=
" target=3D"_blank">https://github.com/ariard/mempool-research/blob/2023-10=
-replacement-paper/replacement-cycling.pdf</a>&gt;<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt;=C2=A0 =C2=A0## Problem<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; A lightning node allows HTLCs forwarding (in bolt3&#39;s=
 parlance accepted HTLC on incoming link and<br>
&gt;&gt; &gt; &gt; offered HTLC on outgoing link) should settle the outgoin=
g state with either a success or timeout<br>
&gt;&gt; &gt; &gt; before the incoming state timelock becomes final and an =
asymmetric defavorable settlement might<br>
&gt;&gt; &gt; &gt; happen (cf &quot;Flood &amp; Loot: A Systematic Attack o=
n The Lightning Network&quot; section 2.3 for a classical<br>
&gt;&gt; &gt; &gt; exposition of this lightning security property).<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Failure to satisfy this settlement requirement exposes a=
 forwarding hop to a loss of fund risk where<br>
&gt;&gt; &gt; &gt; the offered HTLC is spent by the outgoing link counterpa=
rty&#39;s HTLC-preimage and the accepted HTLC is<br>
&gt;&gt; &gt; &gt; spent by the incoming link counterparty&#39;s HTLC-timeo=
ut.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; The specification mandates the incoming HTLC expiration =
timelock to be spaced out by an interval of<br>
&gt;&gt; &gt; &gt; `cltv_expiry_delta` from the outgoing HTLC expiration ti=
melock, this exact interval value being an<br>
&gt;&gt; &gt; &gt; implementation and node policy setting. As a minimal val=
ue, the specification recommends 34 blocks<br>
&gt;&gt; &gt; &gt; of interval. If the timelock expiration I of the inbound=
 HTLC is equal to 100 from chain tip, the<br>
&gt;&gt; &gt; &gt; timelock expiration O of the outbound HTLC must be equal=
 to 66 blocks from chain tip, giving a<br>
&gt;&gt; &gt; &gt; reasonable buffer of reaction to the lightning forwardin=
g node.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; In the lack of cooperative off-chain settlement of the H=
TLC on the outgoing link negotiated with the<br>
&gt;&gt; &gt; &gt; counterparty (either `update_fulfill_htlc` or `update_fa=
il_htlc`) when O is reached, the lightning<br>
&gt;&gt; &gt; &gt; node should broadcast its commitment transaction. Once t=
he commitment is confirmed (if anchor and<br>
&gt;&gt; &gt; &gt; the 1 CSV encumbrance is present), the lightning node br=
oadcasts and confirms its HTLC-timeout<br>
&gt;&gt; &gt; &gt; before I height is reached.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Here enter a replacement cycling attack. A malicious cha=
nnel counterparty can broadcast its<br>
&gt;&gt; &gt; &gt; HTLC-preimage transaction with a higher absolute fee and=
 higher feerate than the honest HTLC-timeout<br>
&gt;&gt; &gt; &gt; of the victim lightning node and triggers a replacement.=
 Both for legacy and anchor output channels,<br>
&gt;&gt; &gt; &gt; a HTLC-preimage on a counterparty commitment transaction=
 is malleable, i.e additional inputs or<br>
&gt;&gt; &gt; &gt; outputs can be added. The HTLC-preimage spends an unconf=
irmed and unrelated to the channel parent<br>
&gt;&gt; &gt; &gt; transaction M and conflicts its child.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; As the HTLC-preimage spends an unconfirmed input that wa=
s already included in the unconfirmed and<br>
&gt;&gt; &gt; &gt; unrelated child transaction (rule 2), pays an absolute h=
igher fee of at least the sum paid by the<br>
&gt;&gt; &gt; &gt; HTLC-timeout and child transaction (rule 3) and the HTLC=
-preimage feerate is greater than all<br>
&gt;&gt; &gt; &gt; directly conflicting transactions (rule 6), the replacem=
ent is accepted. The honest HTLC-timeout is<br>
&gt;&gt; &gt; &gt; evicted out of the mempool.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; In an ulterior move, the malicious counterparty can repl=
ace the parent transaction itself with<br>
&gt;&gt; &gt; &gt; another candidate N satisfying the replacement rules, tr=
iggering the eviction of the malicious<br>
&gt;&gt; &gt; &gt; HTLC-preimage from the mempool as it was a child of the =
parent T.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; There is no spending candidate of the offered HTLC outpu=
t for the current block laying in network<br>
&gt;&gt; &gt; &gt; mempools.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; This replacement cycling tricks can be repeated for each=
 rebroadcast attempt of the HTLC-timeout by<br>
&gt;&gt; &gt; &gt; the honest lightning node until expiration of the inboun=
d HTLC timelock I. Once this height is<br>
&gt;&gt; &gt; &gt; reached a HTLC-timeout is broadcast by the counterparty&=
#39;s on the incoming link in collusion with the<br>
&gt;&gt; &gt; &gt; one on the outgoing link broadcasting its own HTLC-preim=
age.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; The honest Lightning node has been &quot;double-spent&qu=
ot; in its HTLC forwarding.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; As a notable factor impacting the success of the attack,=
 a lightning node&#39;s honest HTLC-timeout<br>
&gt;&gt; &gt; &gt; might be included in the block template of the miner win=
ning the block race and therefore realizes a<br>
&gt;&gt; &gt; &gt; spent of the offered output. In practice, a replacement =
cycling attack might over-connect to miners&#39;<br>
&gt;&gt; &gt; &gt; mempools and public reachable nodes to succeed in a fast=
 eviction of the HTLC-timeout by its<br>
&gt;&gt; &gt; &gt; HTLC-preimage. As this latter transaction can come with =
a better ancestor-score, it should be picked<br>
&gt;&gt; &gt; &gt; up on the flight by economically competitive miners.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; A functional test exercising a simple replacement cyclin=
g of a HTLC transaction on bitcoin core<br>
&gt;&gt; &gt; &gt; mempool is available:<br>
&gt;&gt; &gt; &gt; <a href=3D"https://github.com/ariard/bitcoin/commits/202=
3-test-mempool" rel=3D"noreferrer" target=3D"_blank">https://github.com/ari=
ard/bitcoin/commits/2023-test-mempool</a><br>
&gt;&gt; &gt; &gt; &lt;<a href=3D"https://github.com/ariard/bitcoin/commits=
/2023-test-mempool" rel=3D"noreferrer" target=3D"_blank">https://github.com=
/ariard/bitcoin/commits/2023-test-mempool</a>&gt;<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; ## Deployed LN mitigations<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Aggressive rebroadcasting: As the replacement cycling at=
tacker benefits from the HTLC-timeout being<br>
&gt;&gt; &gt; &gt; usually broadcast by lightning nodes only once every blo=
ck, or less the replacement cycling<br>
&gt;&gt; &gt; &gt; malicious transactions paid only equal the sum of the ab=
solute fees paid by the HTLC, adjusted with<br>
&gt;&gt; &gt; &gt; the replacement penalty. Rebroadcasting randomly and mul=
tiple times before the next block increases<br>
&gt;&gt; &gt; &gt; the absolute fee cost for the attacker.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Implemented and deployed by Eclair, Core-Lightning, LND =
and LDK .<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Local-mempool preimage monitoring: As the replacement cy=
cling attacker in a simple setup broadcast<br>
&gt;&gt; &gt; &gt; the HTLC-preimage to all the network mempools, the hones=
t lightning node is able to catch on the<br>
&gt;&gt; &gt; &gt; flight the unconfirmed HTLC-preimage, before its subsequ=
ent mempool replacement. The preimage can be<br>
&gt;&gt; &gt; &gt; extracted from the second-stage HTLC-preimage and used t=
o fetch the off-chain inbound HTLC with a<br>
&gt;&gt; &gt; &gt; cooperative message or go on-chain with it to claim the =
accepted HTLC output.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Implemented and deployed by Eclair and LND.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; CLTV Expiry Delta: With every jammed block comes an abso=
lute fee cost paid by the attacker, a risk<br>
&gt;&gt; &gt; &gt; of the HTLC-preimage being detected or discovered by the=
 honest lightning node, or the HTLC-timeout<br>
&gt;&gt; &gt; &gt; to slip in a winning block template. Bumping the default=
 CLTV delta hardens the odds of success of a<br>
&gt;&gt; &gt; &gt; simple replacement cycling attack.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Default setting: Eclair 144, Core-Lightning 34, LND 80 a=
nd LDK 72.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; ## Affected Bitcoin Protocols and Applications<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt;=C2=A0 From my understanding the following list of Bitcoi=
n protocols and applications could be affected by<br>
&gt;&gt; &gt; &gt; new denial-of-service vectors under some level of networ=
k mempools congestion. Neither tests or<br>
&gt;&gt; &gt; &gt; advanced review of specifications (when available) has b=
een conducted for each of them:<br>
&gt;&gt; &gt; &gt; - on-chain DLCs<br>
&gt;&gt; &gt; &gt; - coinjoins<br>
&gt;&gt; &gt; &gt; - payjoins<br>
&gt;&gt; &gt; &gt; - wallets with time-sensitive paths<br>
&gt;&gt; &gt; &gt; - peerswap and submarine swaps<br>
&gt;&gt; &gt; &gt; - batch payouts<br>
&gt;&gt; &gt; &gt; - transaction &quot;accelerators&quot;<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Inviting their developers, maintainers and operators to =
investigate how replacement cycling attacks<br>
&gt;&gt; &gt; &gt; might disrupt their in-mempool chain of transactions, or=
 fee-bumping flows at the shortest delay.<br>
&gt;&gt; &gt; &gt; Simple flows and non-multi-party transactions should not=
 be affected to the best of my understanding.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; ## Open Problems: Package Malleability<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Pinning attacks have been known for years as a practical=
 vector to compromise lightning channels<br>
&gt;&gt; &gt; &gt; funds safety, under different scenarios (cf. current bip=
331&#39;s motivation section). Mitigations at<br>
&gt;&gt; &gt; &gt; the mempool level have been designed, discussed and are =
under implementation by the community<br>
&gt;&gt; &gt; &gt; (ancestor package relay + nverrsion=3D3 policy). Ideally=
, they should constraint a pinning attacker to<br>
&gt;&gt; &gt; &gt; always attach a high feerate package (commitment + CPFP)=
 to replace the honest package, or allow a<br>
&gt;&gt; &gt; &gt; honest lightning node to overbid a malicious pinning pac=
kage and get its time-sensitive transaction<br>
&gt;&gt; &gt; &gt; optimistically included in the chain.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Replacement cycling attack seem to offer a new way to ne=
utralize the design goals of package relay<br>
&gt;&gt; &gt; &gt; and its companion nversion=3D3 policy, where an attacker=
 package RBF a honest package out of the<br>
&gt;&gt; &gt; &gt; mempool to subsequently double-spend its own high-fee ch=
ild with a transaction unrelated to the<br>
&gt;&gt; &gt; &gt; channel. As the remaining commitment transaction is pre-=
signed with a minimal relay fee, it can be<br>
&gt;&gt; &gt; &gt; evicted out of the mempool.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; A functional test exercising a simple replacement cyclin=
g of a lightning channel commitment<br>
&gt;&gt; &gt; &gt; transaction on top of the nversion=3D3 code branch is av=
ailable:<br>
&gt;&gt; &gt; &gt; <a href=3D"https://github.com/ariard/bitcoin/commits/202=
3-10-test-mempool-2" rel=3D"noreferrer" target=3D"_blank">https://github.co=
m/ariard/bitcoin/commits/2023-10-test-mempool-2</a><br>
&gt;&gt; &gt; &gt; &lt;<a href=3D"https://github.com/ariard/bitcoin/commits=
/2023-10-test-mempool-2" rel=3D"noreferrer" target=3D"_blank">https://githu=
b.com/ariard/bitcoin/commits/2023-10-test-mempool-2</a>&gt;<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; ## Discovery<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; In 2018, the issue of static fees for pre-signed lightni=
ng transactions is made more widely known,<br>
&gt;&gt; &gt; &gt; the carve-out exemption in mempool rules to mitigate in-=
mempool package limits pinning and the<br>
&gt;&gt; &gt; &gt; anchor output pattern are proposed.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; In 2019, bitcoin core 0.19 is released with carve-out su=
pport. Continued discussion of the anchor<br>
&gt;&gt; &gt; &gt; output pattern as a dynamic fee-bumping method.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; In 2020, draft of anchor output submitted to the bolts. =
Initial finding of economic pinning against<br>
&gt;&gt; &gt; &gt; lightning commitment and second-stage HTLC transactions.=
 Subsequent discussions of a<br>
&gt;&gt; &gt; &gt; preimage-overlay network or package-relay as mitigations=
. Public call made to inquiry more on<br>
&gt;&gt; &gt; &gt; potential other transaction-relay jamming attacks affect=
ing lightning.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; In 2021, initial work in bitcoin core 22.0 of package ac=
ceptance. Continued discussion of the<br>
&gt;&gt; &gt; &gt; pinning attacks and shortcomings of current mempool rule=
s during community-wide online workshops.<br>
&gt;&gt; &gt; &gt; Later the year, in light of all issues for bitcoin secon=
d-layers, a proposal is made about killing<br>
&gt;&gt; &gt; &gt; the mempool.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; In 2022, bip proposed for package relay and new proposed=
 v3 policy design proposed for a review and<br>
&gt;&gt; &gt; &gt; implementation. Mempoolfullrbf is supported in bitcoin c=
ore 24.0 and conceptual questions about<br>
&gt;&gt; &gt; &gt; alignment of mempool rules w.r.t miners incentives are i=
nvestigated.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Along this year 2022, eltoo lightning channels design ar=
e discussed, implemented and reviewed. In<br>
&gt;&gt; &gt; &gt; this context and after discussions on mempool anti-DoS r=
ules, I discovered this new replacement<br>
&gt;&gt; &gt; &gt; cycling attack was affecting deployed lightning channels=
 and immediately reported the finding to<br>
&gt;&gt; &gt; &gt; some bitcoin core developers and lightning maintainers.<=
br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; ## Timeline<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; - 2022-12-16: Report of the finding to Suhas Daftuar, An=
thony Towns, Greg Sanders and Gloria Zhao<br>
&gt;&gt; &gt; &gt; - 2022-12-16: Report to LN maintainers: Rusty Russell, B=
astien Teinturier, Matt Corallo and Olaoluwa<br>
&gt;&gt; &gt; &gt; Osuntunkun<br>
&gt;&gt; &gt; &gt; - 2022-12-23: Sharing to Eugene Siegel (LND)<br>
&gt;&gt; &gt; &gt; - 2022-12-24: Sharing to James O&#39;Beirne and Antoine =
Poinsot (non-lightning potential affected projects)<br>
&gt;&gt; &gt; &gt; - 2022-01-14: Sharing to Gleb Naumenko (miners incentive=
s and cross-layers issuers) and initial<br>
&gt;&gt; &gt; &gt; proposal of an early public disclosure<br>
&gt;&gt; &gt; &gt; - 2022-01-19: Collection of analysis if other second-lay=
ers and multi-party applications affected.<br>
&gt;&gt; &gt; &gt; LN mitigations development starts.<br>
&gt;&gt; &gt; &gt; - 2023-05-04: Sharing to Wilmer Paulino (LDK)<br>
&gt;&gt; &gt; &gt; - 2023-06-20: LN mitigations implemented and progressive=
ly released. Week of the 16 october proposed<br>
&gt;&gt; &gt; &gt; for full disclosure.<br>
&gt;&gt; &gt; &gt; - 2023-08-10: CVEs assigned by MITRE<br>
&gt;&gt; &gt; &gt; - 2023-10-05: Pre-disclosure of LN CVEs numbers and repl=
acement cycling attack existence to<br>
&gt;&gt; &gt; &gt; <a href=3D"mailto:security@bitcoincore.org" target=3D"_b=
lank">security@bitcoincore.org</a> &lt;mailto:<a href=3D"mailto:security@bi=
tcoincore.org" target=3D"_blank">security@bitcoincore.org</a>&gt;.<br>
&gt;&gt; &gt; &gt; - 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-20=
23-40232 / CVE-2023-40233 / CVE-2023-40234<br>
&gt;&gt; &gt; &gt; and replacement cycling attacks<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; ## Conclusion<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Despite the line of mitigations adopted and deployed by =
current major lightning implementations, I<br>
&gt;&gt; &gt; &gt; believe replacement cycling attacks are still practical =
for advanced attackers. Beyond this new<br>
&gt;&gt; &gt; &gt; attack might come as a way to partially or completely de=
feat some of the pinning mitigations which<br>
&gt;&gt; &gt; &gt; have been working for years as a community.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; As of today, it is uncertain to me if lightning is not a=
ffected by a more severe long-term package<br>
&gt;&gt; &gt; &gt; malleability critical security issue under current conse=
nsus rules, and if any other time-sensitive<br>
&gt;&gt; &gt; &gt; multi-party protocol, designed or deployed isn&#39;t de =
facto affected too (loss of funds or denial of<br>
&gt;&gt; &gt; &gt; service).<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Assuming analysis on package malleability is correct, it=
 is unclear to me if it can be corrected by<br>
&gt;&gt; &gt; &gt; changes in replacement / eviction rules or mempool chain=
 of transactions processing strategy.<br>
&gt;&gt; &gt; &gt; Inviting my technical peers and the bitcoin community to=
 look more on this issue, including to<br>
&gt;&gt; &gt; &gt; dissent. I&#39;ll be the first one pleased if I&#39;m fu=
ndamentally wrong on those issues, or if any element<br>
&gt;&gt; &gt; &gt; has not been weighted with the adequate technical accura=
cy it deserves.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Do not trust, verify. All mistakes and opinions are my o=
wn.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Antoine<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; &quot;meet with Triumph and Disaster. And treat those tw=
o impostors just the same&quot; - K.<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; &gt; Lightning-dev mailing list<br>
&gt;&gt; &gt; &gt; <a href=3D"mailto:Lightning-dev@lists.linuxfoundation.or=
g" target=3D"_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
&gt;&gt; &gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/lis=
tinfo/lightning-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.lin=
uxfoundation.org/mailman/listinfo/lightning-dev</a><br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; bitcoin-dev mailing list<br>
&gt;&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo=
/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000da31e3060816d4d7--