path: root/76/eb71531826d99db021854338f0604362e37e20

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 8B1F3C0032;
 Thu, 19 Oct 2023 17:22:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 541E34060C;
 Thu, 19 Oct 2023 17:22:17 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 541E34060C
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=DxxBtShQ
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id AMgX4-TBLY9f; Thu, 19 Oct 2023 17:22:13 +0000 (UTC)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com
 [IPv6:2607:f8b0:4864:20::12e])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 4A4C04019D;
 Thu, 19 Oct 2023 17:22:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4A4C04019D
Received: by mail-il1-x12e.google.com with SMTP id
 e9e14a558f8ab-3528bc102adso30522495ab.2; 
 Thu, 19 Oct 2023 10:22:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1697736132; x=1698340932;
 darn=lists.linuxfoundation.org; 
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=xW2ITEgmwPkr/h+lsSeDj1ZeM94awEmIc0f0YYIBVdw=;
 b=DxxBtShQJN25RnHFfG3vqB3NPgzOI9SXgX/UdnVQ1KkM5FY5ES6A5xf1YyeJlGY2eE
 tIzAjOyf9nGH0EOv7Q/W4r+yA3Ht0ZjzTcE6fjEmjtwSOWeeR3Xe+DWYntFG6snHUWVk
 38dUuFovHF6zP0Hd/2WbdHwc+B3AsF4DII9o6TPICH4/NK8eo1jhZnLOvBLzS+tLhxw+
 +omJRY2SEEKKeSQY6NItOrHMFqfus3TmwwE3My84HgNoijbX/85AYCWLrGzrfndFxvS5
 OmDFqFfTwFdcgXKRp++VKmne0ql3ltLuFiO2Bl7zexu8gb32MVFCnXYetVb8sEUS6M5G
 itqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1697736132; x=1698340932;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=xW2ITEgmwPkr/h+lsSeDj1ZeM94awEmIc0f0YYIBVdw=;
 b=Hpb6dcW4XjFtvb6HNzRl6pvzh8R1MqIvZIkXDWEq5gAS8e9GxzyRDkzIF/wBSwOi8w
 pN//fe+ZGqkGsb5jtwrtWIG3pAf9TdzzqxklYww2dTvSDbXgt24owPxUnxq2Xp6ghSPX
 bsFLb1qycdTgz3uy2/V08kmwD02lP7Dh3K2yypk7MVmnVPH27IVB3M4M1KgZs6VRkbzm
 MK3TxrVFqypgLYOZJk2/PAxM0tM2OnVkqTEIfYqttsPvsilFKu/FCdUyOtb/Dmar9zoo
 ySc30RNi+82fluNvcT0PtMJuJzI7oArL0DRjBkk+2c7KyiDZAT6gD9DDYMmq7/P1Afxe
 8+Ew==
X-Gm-Message-State: AOJu0Yzesz3AKBbvQBUpn3oDFxHIdaha8SaCzYR+9wY4MsN3UaRAJSP1
 5tRZtX3SN/9ImJR2vm0NK0ubdmzOULtJYMXsrgy2LODmobexFQ==
X-Google-Smtp-Source: AGHT+IHRkopE9WO6S0ZDlmnQIQ04G3gy836wwLR/Wy7u/5rJb8cliv6zWCyVb4x31pJwA7ypCi0mc+NcKLYJfdsT99E=
X-Received: by 2002:a92:d78d:0:b0:357:a8cc:44dd with SMTP id
 d13-20020a92d78d000000b00357a8cc44ddmr3043946iln.31.1697736132196; Thu, 19
 Oct 2023 10:22:12 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <ece6f28b-5b14-4f9c-a115-945082a63d68@mattcorallo.com>
 <CAGyamEWnSNAwJ1HpcgiYtNYwUqWOBn7RzhfR_W8460B_9n=qng@mail.gmail.com>
In-Reply-To: <CAGyamEWnSNAwJ1HpcgiYtNYwUqWOBn7RzhfR_W8460B_9n=qng@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 19 Oct 2023 18:22:01 +0100
Message-ID: <CALZpt+GaLGk_Yrnb9+CNm6psLdtiqw_DBkQt+gg8FGh87uN+0Q@mail.gmail.com>
To: Matt Morehouse <mattmorehouse@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000150479060814ffd5"
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 17:22:17 -0000

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

Hi Matt,

This mitigation is mentioned in the attached paper (see subsection 3.4
defensive fee-rebroadcasting)
https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/r=
eplacement-cycling.pdf

As soon as you start to have a bit of a mempool backlog and the defensive
fractional fee HTLC-timeout stays stuck, it gives the advantage to the
attacker again.

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

Best,
Antoine

Le jeu. 19 oct. 2023 =C3=A0 17:23, Matt Morehouse <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 simply d=
o
> their replacement in a
> > cycle aggressively and arbitrarily reduce the probability that the
> victim's transaction gets confirmed.
>
> What if the honest node aggressively fee-bumps and retransmits the
> HTLC-timeout as the CLTV delta deadline approaches, as suggested by
> Ziggie?  Say, within 10 blocks of the deadline, the honest node starts
> increasing the fee by 1/10th the HTLC value for each non-confirmation.
>
> This "scorched earth" approach may cost the honest node considerable
> fees, but it will cost the attacker even more, since each attacker
> replacement needs to burn at least as much as the HTLC-timeout fees,
> and the attacker will need to do a replacement every time the honest
> node fee bumps.
>
> I think this fee-bumping policy will provide sufficient defense even
> if the attacker is replacement-cycling directly in miners' mempools
> and the victim has no visibility into the attack.
>
> >
> > Now, the above is all true in a spherical cow kinda world, and the P2P
> network has plenty of slow
> > nodes and strange behavior. Its possible that these mitigations might,
> by some stroke of luck,
> > happen to catch such an attack and prevent it, because something took
> longer than the attacker
> > intended or whatever. But, that's a far cry from any kind of material
> "fix" for the issue.
> >
> > Ultimately the only fix for this issue will be when miners keep a
> history of transactions they've
> > seen and try them again after they may be able to enter the mempool
> because of an attack like this.
> >
> > Matt
> >
> > On 10/16/23 12:57 PM, Antoine Riard wrote:
> > > (cross-posting mempool issues identified are exposing lightning chan
> to loss of funds risks, other
> > > multi-party bitcoin apps might be affected)
> > >
> > > Hi,
> > >
> > > End of last year (December 2022), amid technical discussions on eltoo
> payment channels and
> > > incentives compatibility of the mempool anti-DoS rules, a new
> transaction-relay jamming attack
> > > affecting lightning channels was discovered.
> > >
> > > After careful analysis, it turns out this attack is practical and
> immediately exposed lightning
> > > routing hops carrying HTLC traffic to loss of funds security risks,
> both legacy and anchor output
> > > channels. A potential exploitation plausibly happening even without
> network mempools congestion.
> > >
> > > Mitigations have been designed, implemented and deployed by all major
> lightning implementations
> > > during the last months.
> > >
> > > Please find attached the release numbers, where the mitigations shoul=
d
> be present:
> > > - LDK: v0.0.118 - CVE-2023 -40231
> > > - Eclair: v0.9.0 - CVE-2023-40232
> > > - LND: v.0.17.0-beta - CVE-2023-40233
> > > - Core-Lightning: v.23.08.01 - CVE-2023-40234
> > >
> > > While neither replacement cycling attacks have been observed or
> reported in the wild since the last
> > > ~10 months or experimented in real-world conditions on bitcoin mainet=
,
> functional test is available
> > > exercising the affected lightning channel against bitcoin core mempoo=
l
> (26.0 release cycle).
> > >
> > > It is understood that a simple replacement cycling attack does not
> demand privileged capabilities
> > > from an attacker (e.g no low-hashrate power) and only access to basic
> bitcoin and lightning
> > > software. Yet I still think executing such an attack successfully
> requests a fair amount of bitcoin
> > > technical know-how and decent preparation.
> > >
> > >  From my understanding of those issues, it is yet to be determined if
> the mitigations deployed are
> > > robust enough in face of advanced replacement cycling attackers,
> especially ones able to combine
> > > different classes of transaction-relay jamming such as pinnings or
> vetted with more privileged
> > > capabilities.
> > >
> > > Please find a list of potential affected bitcoin applications in this
> full disclosure report using
> > > bitcoin script timelocks or multi-party transactions, albeit no
> immediate security risk exposure as
> > > severe as the ones affecting lightning has been identified. Only
> cursory review of non-lightning
> > > applications has been conducted so far.
> > >
> > > There is a paper published summarizing replacement cycling attacks on
> the lightning network:
> > >
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper=
/replacement-cycling.pdf
> > > <
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper=
/replacement-cycling.pdf
> >
> > >
> > >   ## Problem
> > >
> > > A lightning node allows HTLCs forwarding (in bolt3's parlance accepte=
d
> HTLC on incoming link and
> > > offered HTLC on outgoing link) should settle the outgoing state with
> either a success or timeout
> > > before the incoming state timelock becomes final and an asymmetric
> defavorable settlement might
> > > happen (cf "Flood & Loot: A Systematic Attack on The Lightning
> Network" section 2.3 for a classical
> > > exposition of this lightning security property).
> > >
> > > Failure to satisfy this settlement requirement exposes a forwarding
> hop to a loss of fund risk where
> > > the offered HTLC is spent by the outgoing link counterparty's
> HTLC-preimage and the accepted HTLC is
> > > spent by the incoming link counterparty's HTLC-timeout.
> > >
> > > The specification mandates the incoming HTLC expiration timelock to b=
e
> spaced out by an interval of
> > > `cltv_expiry_delta` from the outgoing HTLC expiration timelock, this
> exact interval value being an
> > > implementation and node policy setting. As a minimal value, the
> specification recommends 34 blocks
> > > of interval. If the timelock expiration I of the inbound HTLC is equa=
l
> to 100 from chain tip, the
> > > timelock expiration O of the outbound HTLC must be equal to 66 blocks
> from chain tip, giving a
> > > reasonable buffer of reaction to the lightning forwarding node.
> > >
> > > In the lack of cooperative off-chain settlement of the HTLC on the
> outgoing link negotiated with the
> > > counterparty (either `update_fulfill_htlc` or `update_fail_htlc`) whe=
n
> O is reached, the lightning
> > > node should broadcast its commitment transaction. Once the commitment
> is confirmed (if anchor and
> > > the 1 CSV encumbrance is present), the lightning node broadcasts and
> confirms its HTLC-timeout
> > > before I height is reached.
> > >
> > > Here enter a replacement cycling attack. A malicious channel
> counterparty can broadcast its
> > > HTLC-preimage transaction with a higher absolute fee and higher
> feerate than the honest HTLC-timeout
> > > of the victim lightning node and triggers a replacement. Both for
> legacy and anchor output channels,
> > > a HTLC-preimage on a counterparty commitment transaction is malleable=
,
> i.e additional inputs or
> > > outputs can be added. The HTLC-preimage spends an unconfirmed and
> unrelated to the channel parent
> > > transaction M and conflicts its child.
> > >
> > > As the HTLC-preimage spends an unconfirmed input that was already
> included in the unconfirmed and
> > > unrelated child transaction (rule 2), pays an absolute higher fee of
> at least the sum paid by the
> > > HTLC-timeout and child transaction (rule 3) and the HTLC-preimage
> feerate is greater than all
> > > directly conflicting transactions (rule 6), the replacement is
> accepted. The honest HTLC-timeout is
> > > evicted out of the mempool.
> > >
> > > In an ulterior move, the malicious counterparty can replace the paren=
t
> transaction itself with
> > > another candidate N satisfying the replacement rules, triggering the
> eviction of the malicious
> > > HTLC-preimage from the mempool as it was a child of the parent T.
> > >
> > > There is no spending candidate of the offered HTLC output for the
> current block laying in network
> > > mempools.
> > >
> > > This replacement cycling tricks can be repeated for each rebroadcast
> attempt of the HTLC-timeout by
> > > the honest lightning node until expiration of the inbound HTLC
> timelock I. Once this height is
> > > reached a HTLC-timeout is broadcast by the counterparty's on the
> incoming link in collusion with the
> > > one on the outgoing link broadcasting its own HTLC-preimage.
> > >
> > > The honest Lightning node has been "double-spent" in its HTLC
> forwarding.
> > >
> > > As a notable factor impacting the success of the attack, a lightning
> node's honest HTLC-timeout
> > > might be included in the block template of the miner winning the bloc=
k
> race and therefore realizes a
> > > spent of the offered output. In practice, a replacement cycling attac=
k
> might over-connect to miners'
> > > mempools and public reachable nodes to succeed in a fast eviction of
> the HTLC-timeout by its
> > > HTLC-preimage. As this latter transaction can come with a better
> ancestor-score, it should be picked
> > > up on the flight by economically competitive miners.
> > >
> > > A functional test exercising a simple replacement cycling of a HTLC
> transaction on bitcoin core
> > > mempool is available:
> > > https://github.com/ariard/bitcoin/commits/2023-test-mempool
> > > <https://github.com/ariard/bitcoin/commits/2023-test-mempool>
> > >
> > > ## Deployed LN mitigations
> > >
> > > Aggressive rebroadcasting: As the replacement cycling attacker
> benefits from the HTLC-timeout being
> > > usually broadcast by lightning nodes only once every block, or less
> the replacement cycling
> > > malicious transactions paid only equal the sum of the absolute fees
> paid by the HTLC, adjusted with
> > > the replacement penalty. Rebroadcasting randomly and multiple times
> before the next block increases
> > > the absolute fee cost for the attacker.
> > >
> > > Implemented and deployed by Eclair, Core-Lightning, LND and LDK .
> > >
> > > Local-mempool preimage monitoring: As the replacement cycling attacke=
r
> in a simple setup broadcast
> > > the HTLC-preimage to all the network mempools, the honest lightning
> node is able to catch on the
> > > flight the unconfirmed HTLC-preimage, before its subsequent mempool
> replacement. The preimage can be
> > > extracted from the second-stage HTLC-preimage and used to fetch the
> off-chain inbound HTLC with a
> > > cooperative message or go on-chain with it to claim the accepted HTLC
> output.
> > >
> > > Implemented and deployed by Eclair and LND.
> > >
> > > CLTV Expiry Delta: With every jammed block comes an absolute fee cost
> paid by the attacker, a risk
> > > of the HTLC-preimage being detected or discovered by the honest
> lightning node, or the HTLC-timeout
> > > to slip in a winning block template. Bumping the default CLTV delta
> hardens the odds of success of a
> > > simple replacement cycling attack.
> > >
> > > Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72.
> > >
> > > ## Affected Bitcoin Protocols and Applications
> > >
> > >  From my understanding the following list of Bitcoin protocols and
> applications could be affected by
> > > new denial-of-service vectors under some level of network mempools
> congestion. Neither tests or
> > > advanced review of specifications (when available) has been conducted
> for each of them:
> > > - on-chain DLCs
> > > - coinjoins
> > > - payjoins
> > > - wallets with time-sensitive paths
> > > - peerswap and submarine swaps
> > > - batch payouts
> > > - transaction "accelerators"
> > >
> > > Inviting their developers, maintainers and operators to investigate
> how replacement cycling attacks
> > > might disrupt their in-mempool chain of transactions, or fee-bumping
> flows at the shortest delay.
> > > Simple flows and non-multi-party transactions should not be affected
> to the best of my understanding.
> > >
> > > ## Open Problems: Package Malleability
> > >
> > > Pinning attacks have been known for years as a practical vector to
> compromise lightning channels
> > > funds safety, under different scenarios (cf. current bip331's
> motivation section). Mitigations at
> > > the mempool level have been designed, discussed and are under
> implementation by the community
> > > (ancestor package relay + nverrsion=3D3 policy). Ideally, they should
> constraint a pinning attacker to
> > > always attach a high feerate package (commitment + CPFP) to replace
> the honest package, or allow a
> > > honest lightning node to overbid a malicious pinning package and get
> its time-sensitive transaction
> > > optimistically included in the chain.
> > >
> > > Replacement cycling attack seem to offer a new way to neutralize the
> design goals of package relay
> > > and its companion nversion=3D3 policy, where an attacker package RBF =
a
> honest package out of the
> > > mempool to subsequently double-spend its own high-fee child with a
> transaction unrelated to the
> > > channel. As the remaining commitment transaction is pre-signed with a
> minimal relay fee, it can be
> > > evicted out of the mempool.
> > >
> > > A functional test exercising a simple replacement cycling of a
> lightning channel commitment
> > > transaction on top of the nversion=3D3 code branch is available:
> > > https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2
> > > <https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2>
> > >
> > > ## Discovery
> > >
> > > In 2018, the issue of static fees for pre-signed lightning
> transactions is made more widely known,
> > > the carve-out exemption in mempool rules to mitigate in-mempool
> package limits pinning and the
> > > anchor output pattern are proposed.
> > >
> > > In 2019, bitcoin core 0.19 is released with carve-out support.
> Continued discussion of the anchor
> > > output pattern as a dynamic fee-bumping method.
> > >
> > > In 2020, draft of anchor output submitted to the bolts. Initial
> finding of economic pinning against
> > > lightning commitment and second-stage HTLC transactions. Subsequent
> discussions of a
> > > preimage-overlay network or package-relay as mitigations. Public call
> made to inquiry more on
> > > potential other transaction-relay jamming attacks affecting lightning=
.
> > >
> > > In 2021, initial work in bitcoin core 22.0 of package acceptance.
> Continued discussion of the
> > > pinning attacks and shortcomings of current mempool rules during
> community-wide online workshops.
> > > Later the year, in light of all issues for bitcoin second-layers, a
> proposal is made about killing
> > > the mempool.
> > >
> > > In 2022, bip proposed for package relay and new proposed v3 policy
> design proposed for a review and
> > > implementation. Mempoolfullrbf is supported in bitcoin core 24.0 and
> conceptual questions about
> > > alignment of mempool rules w.r.t miners incentives are investigated.
> > >
> > > Along this year 2022, eltoo lightning channels design are discussed,
> implemented and reviewed. In
> > > this context and after discussions on mempool anti-DoS rules, I
> discovered this new replacement
> > > cycling attack was affecting deployed lightning channels and
> immediately reported the finding to
> > > some bitcoin core developers and lightning maintainers.
> > >
> > > ## Timeline
> > >
> > > - 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns,
> Greg Sanders and Gloria Zhao
> > > - 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien
> Teinturier, Matt Corallo and Olaoluwa
> > > Osuntunkun
> > > - 2022-12-23: Sharing to Eugene Siegel (LND)
> > > - 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot
> (non-lightning potential affected projects)
> > > - 2022-01-14: Sharing to Gleb Naumenko (miners incentives and
> cross-layers issuers) and initial
> > > proposal of an early public disclosure
> > > - 2022-01-19: Collection of analysis if other second-layers and
> multi-party applications affected.
> > > LN mitigations development starts.
> > > - 2023-05-04: Sharing to Wilmer Paulino (LDK)
> > > - 2023-06-20: LN mitigations implemented and progressively released.
> Week of the 16 october proposed
> > > for full disclosure.
> > > - 2023-08-10: CVEs assigned by MITRE
> > > - 2023-10-05: Pre-disclosure of LN CVEs numbers and replacement
> cycling attack existence to
> > > security@bitcoincore.org <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 to=
o
> (loss of funds or denial of
> > > service).
> > >
> > > Assuming analysis on package malleability is correct, it is unclear t=
o
> me if it can be corrected by
> > > changes in replacement / eviction rules or mempool chain of
> transactions processing strategy.
> > > Inviting my technical peers and the bitcoin community to look more on
> this issue, including to
> > > dissent. I'll be the first one pleased if I'm fundamentally wrong on
> those issues, or if any element
> > > has not been weighted with the adequate technical accuracy it deserve=
s.
> > >
> > > Do not trust, verify. All mistakes and opinions are my own.
> > >
> > > Antoine
> > >
> > > "meet with Triumph and Disaster. And treat those two impostors just
> the same" - K.
> > >
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

--000000000000150479060814ffd5--