path: root/5c/2fedd2439f130d389cbb9c4bc9220ae1a46df4

Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0F9D5C0039;
 Fri, 17 Nov 2023 22:36:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id CC09A61238;
 Fri, 17 Nov 2023 22:36:50 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org CC09A61238
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=i/7k3a/x
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id O1osvBaOY-of; Fri, 17 Nov 2023 22:36:48 +0000 (UTC)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com
 [IPv6:2607:f8b0:4864:20::133])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 93D4060B2C;
 Fri, 17 Nov 2023 22:36:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 93D4060B2C
Received: by mail-il1-x133.google.com with SMTP id
 e9e14a558f8ab-358ff34cd9eso9470165ab.1; 
 Fri, 17 Nov 2023 14:36:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1700260607; x=1700865407;
 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=hTHu9U6Pl1As2Lx1CgLbuJIVgoowfCTBCPQnUK7mKlM=;
 b=i/7k3a/x7jq4wjZsVz1cdYfHpAp6ZiVm0HttTxfv9+KCgRFwm+3xiqYUHNi73fvn9h
 C8M8X2qHZ0CV39ch4t5o+CXKllcVT9BRLNell92DSkKmvEZyKZjwoahWbkT6ASKzuFzR
 xqROVOwTrHC0sqd/ECIYfTldIHhXXp4jzlgQkI3AmDCkINn6TjlJ9RSHoG+9ZYvVBs3x
 9P+Y5k4JeFiK8afTMPnh45pFm3GnCSN9Ys+TzBznK9yGoaC+zbzT30wmhmymCeQkEWx7
 0VkRoXVJa+aG92Jo2J7JINnpr4ibCqA0evTJGHM+6XYgrEhvkp5IttwYfMf5CVkCYOsj
 9D+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1700260607; x=1700865407;
 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=hTHu9U6Pl1As2Lx1CgLbuJIVgoowfCTBCPQnUK7mKlM=;
 b=NnUh6GfrfyEWJ9Yk06mJhsD6jMIYZMHxByzt7cHw3WxNm+nfq7Xgb+qBn1+HGFUXdq
 OrwrcqJpjqPusKC8WPb06S9AhhyC3RaZI+GhYpz8boVErCvDub5GRkUfatRIS2IIbf53
 Ubj/zm/jib/FhTHEDsi+GDYJ5yu+P6QM8afsbSL8oJzBnbkMYqnt89xYd3CAYzR2UB5r
 tqhabkD9hJGkDS8T1Edi5Ce36ujhhJtQwUGz3qtaKgLDHBpDD4GYC3Rbe300OZ/Tdq7U
 MHZU4vqdlS25MUPR9+VbFdtaa3q+wJjiVm51JO9UO01V/sLrd8PwK0RXkdZU2EfTfxb2
 8nQA==
X-Gm-Message-State: AOJu0YxnT5zpT9wEHDA5QxAlFnOdBW3CkQ+SSK9upmroMoLM/WS87O2c
 TofI860fzCPdFR2xULTIwLlwQdHtZ9lVU5PPqtNjC6Td4JN2jg==
X-Google-Smtp-Source: AGHT+IGOxHOzmU8wQ97/DXcoPFQx2OipVE3tvJ2RlRF8wBP6lP6ar9sw+ejcLGFxaYXHdB2J1VHskIgHPwHLMgkBkp4=
X-Received: by 2002:a05:6e02:1c82:b0:35a:b2a0:b8a6 with SMTP id
 w2-20020a056e021c8200b0035ab2a0b8a6mr1020517ill.31.1700260607484; Fri, 17 Nov
 2023 14:36:47 -0800 (PST)
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>
 <CALZpt+FaYop1J5Zi=42F4jCScfiPL3AZ98HWtW82Qd8ZQG=aMg@mail.gmail.com>
 <CAO3Pvs9jUr8cw0Dz35oHLREzSeMCbGyFkUDt0w8EFoW1RVZHzw@mail.gmail.com>
In-Reply-To: <CAO3Pvs9jUr8cw0Dz35oHLREzSeMCbGyFkUDt0w8EFoW1RVZHzw@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 17 Nov 2023 22:36:35 +0000
Message-ID: <CALZpt+F411Qv=8znxXzv6O3r21ZdD9h24RJL2Oq6O-mdBTaYww@mail.gmail.com>
To: Olaoluwa Osuntokun <laolu32@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000088e82c060a60c5a7"
X-Mailman-Approved-At: Sat, 18 Nov 2023 14:03:10 +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: Fri, 17 Nov 2023 22:36:51 -0000

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

> IIRC correctly, in your scenario, you're dealing with Carol -> Bob ->
Alice.
> Mallory can only replace an HTLC-timeout transaction if she's directly
> connected with the peer she's targeting via a direct channel. She cannot
> unilaterally replace any transaction in the mempool solely with knowledge
of
> the preimage. All HTLC transactions are two party contracts, with the
public
> keys of both participants hard coded into the contract. A third party
cannot
> unilaterally sweep an HTLC given only a preimage.

> I think it's worth taking a minute to step back here so we can establish
> some fundamental context. Once the timelock of an HTLC expires, and the
> receiver has direct knowledge of the preimage, a bidding war begins.  If
the
> receiver is able to confirm their success transaction in time, then they
> gain the funds, and the sender is able to pipeline the preimage backwards
in
> the route, making all parties whole. If the sender is the one that wins
out,
> then it's as if nothing happened, sans the fees paid at the last mile, al=
l
> other hops are able to safely cancel their HTLC back on the chain.

> As mentioned elsewhere in the thread, most implementations today will
watch
> the mempool for preimages, so they can resolve the incoming HTLC as
quickly
> as possible off chain. The attack described critically relies on the
ability
> of an attacker to pull off very precise transaction replacement globally
> across "the mempool". If any of the honest parties see the preimage, in
the
> mempool, then the attack ends as they can settle back off chain, and if
> their timeout is able to confirm first, then the defender has actually
> gained funds.

Correct mostly so far, a part of the globally across "the mempool".

> In addition, such an attack needs to be executed perfectly, for hours if
not
> days. Within the LN, all nodes set a security parameter, the CLTV delta,
> that dictates how much time they have before the outgoing and incoming
HTLCs
> expire. Increasing this value makes the attack more difficult, as they
must
> maintain the superposition of: fees low enough to not get mined, but high
> enough to replace the defender's transaction, but not _too_ high, as then
> it'll be mined and everything is over. With each iteration, the attacker
is
> also forced to increase the amount of fees they pay, increasing the likel=
y
> hood that the transaction will be mined. If mined, the attack is moot.

The attacker just has to overbid the parent of the HTLC-preimage with a
higher fee replacement parent. This replacement parent can be confirmed at
any time, even if the attacker realizes a higher economic gain if this
replacement transaction is delayed as much as possible. Or the absolute fee
consumed to batch attack multiple targets. So I think your assumption on
the attack difficulty is not correct.

> As mentioned in the OP, one thing the attacker can do is try and locate
the
> defender's node to launch the replacement attack directly in their
mempool.
> However, by replacing directly in the mempool of the defender, the
defender
> will learn of the preimage! They can use that to just settle everything
> back, thereby completing the payment, and stopping the attack short. Even
> ignoring direct access to the defender's mempool, the attacker needs to
> somehow iteratively execute the replacement across a real network, with
all
> the network jitter, propagation delay, and geographic heterogeneity that
> entails. If they're off by milliseconds, then either a confirmation
occurs,
> or the preimage is revealed in the mempool. A canned local regtest env is
> one thing, the distributed system that is the Internet is another.

The attacker can blind the defender mempool by locating the associated
full-node with its lightning node, then broadcast a conflicting parent of
the HTLC-preimage, partitioning the mempool from the rest of the network.
The HTLC-preimage will never enter the defender's mempool, as some spent
inputs are missing.

All the considerations on network jitter, propagation delay and geographic
heterogeneity are irrelevant as network mempools are in practice a
distributed system of logically equivalent state machines to favor
propagation of high-fees paying transactions, on top of raw TCP/IP
connections. Propagation works quite deterministically on average if you
have ever used a bitcoin wallet to pay with zero-conf and see the
transaction showing up as unconfirmed on the payment processor. Policy
divergences across implementations and versions does not matter here.

The p2p stack of Bitcoin Core has some propagation delay in the order of
seconds for outbound / inbound connections transaction-relay connections. I
think they're at the advantage of the attacker, as they can be bypassed to
quickly evict the honest HTLC-timeout bypassing them with mass connections.

The p2p transaction-relay is a public network of nodes running common open
software, where their inbound slots can be occupied at low-cost and their
network address might be publicly announced. All at the advantage of the
attacker.

> Returning back to the bidding war: for anchor channels, the second level
> HTLCs allow the defender to attach arbitrary inputs for fee bumping
> purposes. Using this, they can iteratively increase their fee (via RBF) a=
s
> the expiry deadline approaches. With each step, they further increase the
> cost for the attacker. On top of that, this attack cannot be launched
> indiscriminately across the network. Instead, it requires a per-node set
up by
> the attacker, as they need to consume UTXOs to create a chain of
> transactions they'll use to launch the replacement attack. These also nee=
d
> to be maintained in a similar state of non-confirming superposition.

As said elsewhere, I'll maintain this is a practical and critical attack on
lightning, I don't doubt you have the level of expertise in this attack by
yourself and re-think if it's a fragile one or bring new insights to the
conversation.

There are no requirements of an "extremely precise timing and execution",
the most adversarial event that an attacker might hit is a block being
mined in the order of few seconds between a HTLC-timeout hit the block
template and a block is mined. On average, you have a 10 min block interval
so probabilities are in favor of the attacker.

It is correct that miners can broadcast any of the preimage replacement
transactions, however this is not at all a deployed mechanism today by the
mining ecosystem. DoS-robustness of such a scheme is very unclear.

One more mitigation that can be done by lightning nodes today is
duplicating the mempool-monitoring mitigation to their watchtower backends,
assuming those ones are already running on top of a full-node. For each new
watchtower deployed, this is one more entity to mempool-partition by the
attacker and all of them must be well-partitioned along the attack. This
can still be neutralized by sophisticated attackers, though it's notably
raising the bar to mount a successful replacement attack.

Recommending to LN softwares to adapt this last mitigation, especially if
your implementation is used by high-value routing nodes or LSPs.

Best,
Antoine

Le sam. 21 oct. 2023 =C3=A0 01:19, Olaoluwa Osuntokun <laolu32@gmail.com> a
=C3=A9crit :

> > 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.
>
> > 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.
>
> IIRC correctly, in your scenario, you're dealing with Carol -> Bob ->
> Alice.
> Mallory can only replace an HTLC-timeout transaction if she's directly
> connected with the peer she's targeting via a direct channel. She cannot
> unilaterally replace any transaction in the mempool solely with knowledge
> of
> the preimage. All HTLC transactions are two party contracts, with the
> public
> keys of both participants hard coded into the contract. A third party
> cannot
> unilaterally sweep an HTLC given only a preimage.
>
> I think it's worth taking a minute to step back here so we can establish
> some fundamental context. Once the timelock of an HTLC expires, and the
> receiver has direct knowledge of the preimage, a bidding war begins.  If
> the
> receiver is able to confirm their success transaction in time, then they
> gain the funds, and the sender is able to pipeline the preimage backwards
> in
> the route, making all parties whole. If the sender is the one that wins
> out,
> then it's as if nothing happened, sans the fees paid at the last mile, al=
l
> other hops are able to safely cancel their HTLC back on the chain.
>
> As mentioned elsewhere in the thread, most implementations today will wat=
ch
> the mempool for preimages, so they can resolve the incoming HTLC as quick=
ly
> as possible off chain. The attack described critically relies on the
> ability
> of an attacker to pull off very precise transaction replacement globally
> across "the mempool". If any of the honest parties see the preimage, in t=
he
> mempool, then the attack ends as they can settle back off chain, and if
> their timeout is able to confirm first, then the defender has actually
> gained funds.
>
> In addition, such an attack needs to be executed perfectly, for hours if
> not
> days. Within the LN, all nodes set a security parameter, the CLTV delta,
> that dictates how much time they have before the outgoing and incoming
> HTLCs
> expire. Increasing this value makes the attack more difficult, as they mu=
st
> maintain the superposition of: fees low enough to not get mined, but high
> enough to replace the defender's transaction, but not _too_ high, as then
> it'll be mined and everything is over. With each iteration, the attacker =
is
> also forced to increase the amount of fees they pay, increasing the likel=
y
> hood that the transaction will be mined. If mined, the attack is moot.
>
> As mentioned in the OP, one thing the attacker can do is try and locate t=
he
> defender's node to launch the replacement attack directly in their mempoo=
l.
> However, by replacing directly in the mempool of the defender, the defend=
er
> will learn of the preimage! They can use that to just settle everything
> back, thereby completing the payment, and stopping the attack short. Even
> ignoring direct access to the defender's mempool, the attacker needs to
> somehow iteratively execute the replacement across a real network, with a=
ll
> the network jitter, propagation delay, and geographic heterogeneity that
> entails. If they're off by milliseconds, then either a confirmation occur=
s,
> or the preimage is revealed in the mempool. A canned local regtest env is
> one thing, the distributed system that is the Internet is another.
>
> Returning back to the bidding war: for anchor channels, the second level
> HTLCs allow the defender to attach arbitrary inputs for fee bumping
> purposes. Using this, they can iteratively increase their fee (via RBF) a=
s
> the expiry deadline approaches. With each step, they further increase the
> cost for the attacker. On top of that, this attack cannot be launched
> indiscriminately across the network. Instead, it requires per-node set up
> by
> the attacker, as they need to consume UTXOs to create a chain of
> transactions they'll use to launch the replacement attack. These also nee=
d
> to be maintained in a similar state of non-confirming superposition.
>
> That's all to say that imo, this is a rather fragile attack, which
> requires:
> per-node setup, extremely precise timing and execution, non-confirming
> superposition of all transactions, and instant propagation across the
> entire
> network of the replacement transaction (somehow also being obscured from
> the
> PoV of the defender). The attack can be launched directly with a miner, o=
r
> "into" their mempool, but that weakens the attack as if the miner
> broadcasts
> any of the preimage replacement transactions, then the defender can once
> again use that to extract the preimage and settle the incoming HTLC.
>
> -- Laolu
>

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

<div dir=3D"ltr">&gt; IIRC correctly, in your scenario, you&#39;re dealing =
with Carol -&gt; Bob -&gt; Alice.<br>&gt; Mallory can only replace an HTLC-=
timeout transaction if she&#39;s directly<br>&gt; connected with the peer s=
he&#39;s targeting via a direct channel. She cannot<br>&gt; unilaterally re=
place any transaction in the mempool solely with knowledge of<br>&gt; the p=
reimage. All HTLC transactions are two party contracts, with the public<br>=
&gt; keys of both participants hard coded into the contract. A third party =
cannot<br>&gt; unilaterally sweep an HTLC given only a preimage.<span class=
=3D"gmail-Apple-converted-space">=C2=A0</span><br><br>&gt; I think it&#39;s=
 worth taking a minute to step back here so we can establish<br>&gt; some f=
undamental context. Once the timelock of an HTLC expires, and the<br>&gt; r=
eceiver has direct knowledge of the preimage, a bidding war begins.=C2=A0 I=
f the<br>&gt; receiver is able to confirm their success transaction in time=
, then they<br>&gt; gain the funds, and the sender is able to pipeline the =
preimage backwards in<br>&gt; the route, making all parties whole. If the s=
ender is the one that wins out,<br>&gt; then it&#39;s as if nothing happene=
d, sans the fees paid at the last mile, all<br>&gt; other hops are able to =
safely cancel their HTLC back on the chain.<br><br>&gt; As mentioned elsewh=
ere in the thread, most implementations today will watch<br>&gt; the mempoo=
l for preimages, so they can resolve the incoming HTLC as quickly<br>&gt; a=
s possible off chain. The attack described critically relies on the ability=
<br>&gt; of an attacker to pull off very precise transaction replacement gl=
obally<br>&gt; across &quot;the mempool&quot;. If any of the honest parties=
 see the preimage, in the<br>&gt; mempool, then the attack ends as they can=
 settle back off chain, and if<br>&gt; their timeout is able to confirm fir=
st, then the defender has actually<br>&gt; gained funds.<br><div><br></div>=
<div>Correct mostly so far, a part of the globally across &quot;the mempool=
&quot;.</div><div><br></div><div>&gt; In addition, such an attack needs to =
be executed perfectly, for hours if not<br>&gt; days. Within the LN, all no=
des set a security parameter, the CLTV delta,<br>&gt; that dictates how muc=
h time they have before the outgoing and incoming HTLCs<br>&gt; expire. Inc=
reasing this value makes the attack more difficult, as they must<br>&gt; ma=
intain the superposition of: fees low enough to not get mined, but high<br>=
&gt; enough to replace the defender&#39;s transaction, but not _too_ high, =
as then<br>&gt; it&#39;ll be mined and everything is over. With each iterat=
ion, the attacker is<br>&gt; also forced to increase the amount of fees the=
y pay, increasing the likely<br>&gt; hood that the transaction will be mine=
d. If mined, the attack is moot.<br></div><div><br></div><div>The attacker =
just has to overbid the parent of the HTLC-preimage with a higher fee repla=
cement parent. This replacement parent can be confirmed at any time, even i=
f the attacker realizes a higher economic gain if this replacement transact=
ion is delayed as much as possible. Or the absolute fee consumed to batch a=
ttack multiple targets. So I think your assumption on the attack difficulty=
 is not correct.</div><div><br></div><div>&gt; As mentioned in the OP, one =
thing the attacker can do is try and locate the<br>&gt; defender&#39;s node=
 to launch the replacement attack directly in their mempool.<br>&gt; Howeve=
r, by replacing directly in the mempool of the defender, the defender<br>&g=
t; will learn of the preimage! They can use that to just settle everything<=
br>&gt; back, thereby completing the payment, and stopping the attack short=
. Even<br>&gt; ignoring direct access to the defender&#39;s mempool, the at=
tacker needs to<br>&gt; somehow iteratively execute the replacement across =
a real network, with all<br>&gt; the network jitter, propagation delay, and=
 geographic heterogeneity that<br>&gt; entails. If they&#39;re off by milli=
seconds, then either a confirmation occurs,<br>&gt; or the preimage is reve=
aled in the mempool. A canned local regtest env is<br>&gt; one thing, the d=
istributed system that is the Internet is another.<br></div><div><br></div>=
<div>The attacker can blind the defender mempool by locating the associated=
 full-node with its lightning node, then broadcast a conflicting parent of =
the HTLC-preimage, partitioning the mempool from the rest of the network. T=
he HTLC-preimage will never enter the defender&#39;s mempool, as some spent=
 inputs are missing.</div><div><br></div><div>All the considerations on net=
work jitter, propagation delay and geographic heterogeneity are irrelevant =
as network mempools are in practice a distributed system of logically equiv=
alent state machines to favor propagation of high-fees paying transactions,=
 on top of raw TCP/IP connections. Propagation works quite deterministicall=
y on average if you have ever used a bitcoin wallet to pay with zero-conf a=
nd see the transaction showing up as unconfirmed on the payment processor. =
Policy divergences across implementations and versions does not matter here=
.</div><div><br></div><div>The p2p stack of Bitcoin Core has some propagati=
on delay in the order of seconds for outbound / inbound connections transac=
tion-relay connections. I think they&#39;re at the advantage of the attacke=
r, as they can be bypassed to quickly evict the honest HTLC-timeout bypassi=
ng them with mass connections.</div><div><br></div><div>The p2p transaction=
-relay is a public network of nodes running common open software, where the=
ir inbound slots can be occupied at low-cost and their network address migh=
t be publicly announced. All at the advantage of the attacker.</div><div><b=
r></div><div>&gt; Returning back to the bidding war: for anchor channels, t=
he second level<br>&gt; HTLCs allow the defender to attach arbitrary inputs=
 for fee bumping<br>&gt; purposes. Using this, they can iteratively increas=
e their fee (via RBF) as<br>&gt; the expiry deadline approaches. With each =
step, they further increase the<br>&gt; cost for the attacker. On top of th=
at, this attack cannot be launched<br>&gt; indiscriminately across the netw=
ork. Instead, it requires a per-node set up by<br>&gt; the attacker, as the=
y need to consume UTXOs to create a chain of<br>&gt; transactions they&#39;=
ll use to launch the replacement attack. These also need<br>&gt; to be main=
tained in a similar state of non-confirming superposition.<br></div><div><b=
r></div><div>As said elsewhere, I&#39;ll maintain this is a practical and c=
ritical attack on lightning, I don&#39;t doubt you have the level of expert=
ise in this attack by yourself and re-think if it&#39;s a fragile one or br=
ing new insights to the conversation.</div><div><br></div><div>There are no=
 requirements of an &quot;extremely precise timing and execution&quot;, the=
 most adversarial event that an attacker might hit is a block being mined i=
n the order of few seconds between a HTLC-timeout hit the block template an=
d a block is mined. On average, you have a 10 min block interval so probabi=
lities=C2=A0are in favor of the attacker.</div><div><br></div><div>It is co=
rrect that miners can broadcast any of the preimage replacement transaction=
s, however this is not at all a deployed mechanism today by the mining ecos=
ystem. DoS-robustness of such a scheme is very unclear.</div><div><br></div=
><div>One more mitigation that can be done by lightning nodes today is dupl=
icating the mempool-monitoring mitigation to their watchtower backends, ass=
uming those ones are already running on top of a full-node. For each new wa=
tchtower deployed, this is one more entity to mempool-partition by the atta=
cker and all of them must be well-partitioned along the attack. This can st=
ill be neutralized by sophisticated attackers, though it&#39;s notably rais=
ing the bar to mount a successful replacement attack.</div><div><br></div><=
div>Recommending to LN softwares to adapt this last mitigation, especially =
if your implementation is used by high-value routing nodes or LSPs.</div><d=
iv><br></div><div>Best,</div><div>Antoine</div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0sam. 21 oct. 2023 =
=C3=A0=C2=A001:19, Olaoluwa Osuntokun &lt;<a href=3D"mailto:laolu32@gmail.c=
om">laolu32@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr">&gt; Let&#39;s say you have Alice, Bob and Caroll all &qu=
ot;honest&quot; routing hops<br>&gt; targeted by an attacker. They all have=
 3 independent 10 000 sats HTLC<br>&gt; in-flight on their outbound channel=
s.<br><br>&gt; It is replaced by Mallory at T+2 with a HTLC-preimage X of 2=
00 000 sats (+<br>&gt; rbf penalty 1 sat / vb rule 4). Alice&#39;s HTLC-tim=
eout is out of network<br>&gt; mempools.<br><br>&gt; Bob broadcasts her HTL=
C-timeout of 200 000 sats at T+3. It is replaced by<br>&gt; Mallory at T+4 =
with her HLTC-preimage Y of 200 000 sats (+ rbf penalty 1<br>&gt; sat / vb =
rule 4 * 2). Bob&#39;s HTLC-timeout is out of network mempools. <br><br>IIR=
C correctly, in your scenario, you&#39;re dealing with Carol -&gt; Bob -&gt=
; Alice.<br>Mallory can only replace an HTLC-timeout transaction if she&#39=
;s directly<br>connected with the peer she&#39;s targeting via a direct cha=
nnel. She cannot<br>unilaterally replace any transaction in the mempool sol=
ely with knowledge of<br>the preimage. All HTLC transactions are two party =
contracts, with the public<br>keys of both participants hard coded into the=
 contract. A third party cannot<br>unilaterally sweep an HTLC given only a =
preimage. <br><br>I think it&#39;s worth taking a minute to step back here =
so we can establish<br>some fundamental context. Once the timelock of an HT=
LC expires, and the<br>receiver has direct knowledge of the preimage, a bid=
ding war begins.=C2=A0 If the<br>receiver is able to confirm their success =
transaction in time, then they<br>gain the funds, and the sender is able to=
 pipeline the preimage backwards in<br>the route, making all parties whole.=
 If the sender is the one that wins out,<br>then it&#39;s as if nothing hap=
pened, sans the fees paid at the last mile, all<br>other hops are able to s=
afely cancel their HTLC back on the chain.<br><br>As mentioned elsewhere in=
 the thread, most implementations today will watch<br>the mempool for preim=
ages, so they can resolve the incoming HTLC as quickly<br>as possible off c=
hain. The attack described critically relies on the ability<br>of an attack=
er to pull off very precise transaction replacement globally<br>across &quo=
t;the mempool&quot;. If any of the honest parties see the preimage, in the<=
br>mempool, then the attack ends as they can settle back off chain, and if<=
br>their timeout is able to confirm first, then the defender has actually<b=
r>gained funds.<br><br>In addition, such an attack needs to be executed per=
fectly, for hours if not<br>days. Within the LN, all nodes set a security p=
arameter, the CLTV delta,<br>that dictates how much time they have before t=
he outgoing and incoming HTLCs<br>expire. Increasing this value makes the a=
ttack more difficult, as they must<br>maintain the superposition of: fees l=
ow enough to not get mined, but high<br>enough to replace the defender&#39;=
s transaction, but not _too_ high, as then<br>it&#39;ll be mined and everyt=
hing is over. With each iteration, the attacker is<br>also forced to increa=
se the amount of fees they pay, increasing the likely<br>hood that the tran=
saction will be mined. If mined, the attack is moot.<br><br>As mentioned in=
 the OP, one thing the attacker can do is try and locate the<br>defender&#3=
9;s node to launch the replacement attack directly in their mempool.<br>How=
ever, by replacing directly in the mempool of the defender, the defender<br=
>will learn of the preimage! They can use that to just settle everything<br=
>back, thereby completing the payment, and stopping the attack short. Even<=
br>ignoring direct access to the defender&#39;s mempool, the attacker needs=
 to<br>somehow iteratively execute the replacement across a real network, w=
ith all<br>the network jitter, propagation delay, and geographic heterogene=
ity that<br>entails. If they&#39;re off by milliseconds, then either a conf=
irmation occurs,<br>or the preimage is revealed in the mempool. A canned lo=
cal regtest env is<br>one thing, the distributed system that is the Interne=
t is another.<br><br>Returning back to the bidding war: for anchor channels=
, the second level<br>HTLCs allow the defender to attach arbitrary inputs f=
or fee bumping<br>purposes. Using this, they can iteratively increase their=
 fee (via RBF) as<br>the expiry deadline approaches. With each step, they f=
urther increase the<br>cost for the attacker. On top of that, this attack c=
annot be launched<br>indiscriminately across the network. Instead, it requi=
res per-node set up by<br>the attacker, as they need to consume UTXOs to cr=
eate a chain of<br>transactions they&#39;ll use to launch the replacement a=
ttack. These also need<br>to be maintained in a similar state of non-confir=
ming superposition.<br><br>That&#39;s all to say that imo, this is a rather=
 fragile attack, which requires:<br>per-node setup, extremely precise timin=
g and execution, non-confirming<br>superposition of all transactions, and i=
nstant propagation across the entire<br>network of the replacement transact=
ion (somehow also being obscured from the<br>PoV of the defender). The atta=
ck can be launched directly with a miner, or<br>&quot;into&quot; their memp=
ool, but that weakens the attack as if the miner broadcasts<br>any of the p=
reimage replacement transactions, then the defender can once<br>again use t=
hat to extract the preimage and settle the incoming HTLC.<br><br>-- Laolu<b=
r></div>
</blockquote></div>

--00000000000088e82c060a60c5a7--