MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 16 Oct 2023 17:57:36 +0100
Message-ID: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000039e7790607d84e45"
Cc: security@ariard.me
Subject: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 /
 CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
Precedence: list

--00000000000039e7790607d84e45
Content-Type: text/plain; charset="UTF-8"

(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 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

 ## 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 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 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 HTLC
transaction on bitcoin core mempool is available:
https://github.com/ariard/bitcoin/commits/2023-test-mempool

## Deployed LN mitigations

Aggressive rebroadcasting: As the replacement cycling attacker benefits
from the HTLC-timeout being usually broadcast by lightning nodes only 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 attacker in a
simple setup broadcast the HTLC-preimage to all the network mempools, the
honest lightning node is able to catch on the flight the unconfirmed
HTLC-preimage, before its 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=3 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=3 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=3 code branch is
available:
https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2

## Discovery

In 2018, the issue of static fees for pre-signed lightning transactions 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.
- 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 unclear to me
if it can be corrected by changes in replacement / eviction rules or
mempool chain of transactions processing strategy. Inviting my technical
peers and the bitcoin community to look more on this issue, including to
dissent. I'll be the first one pleased if I'm fundamentally wrong on 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 just the
same" - K.

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

<div dir=3D"ltr"><div>(cross-posting mempool issues identified are exposing=
 lightning chan to loss of funds risks, other multi-party bitcoin apps migh=
t be affected)</div><div><br></div>Hi,<div><br></div><div>End of last year =
(December 2022), amid technical discussions on eltoo payment channels and i=
ncentives compatibility of the mempool anti-DoS rules, a new transaction-re=
lay jamming attack affecting lightning channels was discovered.</div><div><=
br></div><div>After careful analysis, it turns out this attack is practical=
 and immediately=C2=A0exposed lightning routing hops carrying HTLC traffic =
to loss of funds security risks, both legacy and anchor=C2=A0output channel=
s. A potential exploitation plausibly happening even without network mempoo=
ls congestion.</div><div><br></div><div>Mitigations have been designed, imp=
lemented and deployed by all major lightning implementations during the las=
t months.</div><div><br></div><div>Please find attached the release numbers=
, where the mitigations should be present:</div><div>- LDK: v0.0.118 - CVE-=
2023 -40231</div><div>- Eclair: v0.9.0 - CVE-2023-40232</div><div>- LND: v.=
0.17.0-beta - CVE-2023-40233</div><div>- Core-Lightning: v.23.08.01 - CVE-2=
023-40234</div><div><br></div><div>While neither replacement cycling attack=
s have been observed or reported in the wild since the last ~10 months or e=
xperimented in real-world conditions on bitcoin mainet, functional test is =
available exercising the affected lightning channel against bitcoin core me=
mpool (26.0 release cycle).</div><div><br></div><div>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 bitc=
oin and lightning software. Yet I still think executing such an attack succ=
essfully requests a fair amount of bitcoin technical know-how and decent pr=
eparation.</div><div><br></div><div>From my understanding of those issues, =
it is yet to be determined if the mitigations deployed are robust enough in=
 face of advanced replacement cycling attackers, especially ones able to co=
mbine different classes of transaction-relay jamming such as pinnings or ve=
tted with more privileged capabilities.</div><div><br></div><div>Please fin=
d 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 lightni=
ng has been identified. Only cursory review of non-lightning applications h=
as been conducted so far.</div><div><br></div><div>There is a paper publish=
ed summarizing replacement cycling attacks on the lightning network:</div><=
div><a href=3D"https://github.com/ariard/mempool-research/blob/2023-10-repl=
acement-paper/replacement-cycling.pdf">https://github.com/ariard/mempool-re=
search/blob/2023-10-replacement-paper/replacement-cycling.pdf</a></div><div=
><br></div><div>=C2=A0## Problem</div><div><br></div><div>A lightning node =
allows HTLCs forwarding (in bolt3&#39;s parlance accepted HTLC on incoming =
link and offered HTLC on outgoing link) should settle the outgoing state wi=
th either a success or timeout before the incoming state timelock becomes f=
inal and an asymmetric defavorable settlement might happen (cf &quot;Flood =
&amp; Loot: A Systematic Attack on The Lightning Network&quot; section 2.3 =
for a classical exposition of this lightning security property).</div><div>=
<br></div><div>Failure to satisfy this settlement requirement exposes a for=
warding hop to a loss of fund risk where the offered HTLC is spent by the o=
utgoing link counterparty&#39;s HTLC-preimage and the accepted HTLC is spen=
t by the incoming link counterparty&#39;s HTLC-timeout.</div><div><br></div=
><div>The specification mandates the incoming HTLC expiration timelock to b=
e spaced out by an interval of `cltv_expiry_delta` from the outgoing HTLC e=
xpiration timelock, this exact interval value being an implementation and n=
ode policy setting. As a minimal value, the specification recommends 34 blo=
cks 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 reactio=
n to the lightning forwarding node.</div><div><br></div><div>In the lack of=
 cooperative off-chain settlement of the HTLC on the outgoing link negotiat=
ed with the counterparty (either `update_fulfill_htlc` or `update_fail_htlc=
`) when O is reached, the lightning node should broadcast its commitment tr=
ansaction. Once the commitment is confirmed (if anchor and the 1 CSV encumb=
rance is present), the lightning node broadcasts and confirms its HTLC-time=
out before I height is reached.</div><div><br></div><div>Here enter a repla=
cement cycling attack. A malicious channel counterparty can broadcast its H=
TLC-preimage transaction with a higher absolute fee and higher feerate than=
 the honest HTLC-timeout of the victim lightning node and triggers a replac=
ement. Both for legacy and anchor output channels, a HTLC-preimage on a cou=
nterparty commitment transaction is malleable, i.e additional inputs or out=
puts can be added. The HTLC-preimage spends an unconfirmed and unrelated to=
 the channel parent transaction M and conflicts its child.</div><div><br></=
div><div>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 chi=
ld transaction (rule 3) and the HTLC-preimage feerate is greater than all d=
irectly conflicting transactions (rule 6), the replacement is accepted. The=
 honest HTLC-timeout is evicted out of the mempool.</div><div><br></div><di=
v>In an ulterior move, the malicious counterparty can replace the parent tr=
ansaction 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.</div><div><br></div><div>There is no spend=
ing candidate of the offered HTLC output for the current block laying in ne=
twork mempools.</div><div><br></div><div>This replacement cycling tricks ca=
n be repeated for each rebroadcast attempt of the HTLC-timeout by the hones=
t lightning node until expiration of the inbound HTLC timelock I. Once this=
 height is reached a HTLC-timeout is broadcast by the counterparty&#39;s on=
 the incoming link in collusion with the one on the outgoing link broadcast=
ing its own HTLC-preimage.</div><div><br></div><div>The honest Lightning no=
de has been &quot;double-spent&quot; in its HTLC forwarding.</div><div><br>=
</div><div>As a notable factor impacting the success of the attack, a light=
ning node&#39;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-connec=
t to miners&#39; mempools and public reachable nodes to succeed in a fast e=
viction of the HTLC-timeout by its HTLC-preimage. As this latter transactio=
n can come with a better ancestor-score, it should be picked up on the flig=
ht by economically competitive miners.</div><div><br></div><div>A functiona=
l test exercising a simple replacement cycling of a HTLC transaction on bit=
coin core mempool is available:</div><div><a href=3D"https://github.com/ari=
ard/bitcoin/commits/2023-test-mempool">https://github.com/ariard/bitcoin/co=
mmits/2023-test-mempool</a><br></div><div><br></div><div>## Deployed LN mit=
igations</div><div><br></div><div>Aggressive rebroadcasting: As the replace=
ment cycling attacker benefits from the HTLC-timeout being usually broadcas=
t by lightning nodes only once every block, or less the replacement cycling=
 malicious transactions paid only equal the sum of the absolute fees paid b=
y the HTLC, adjusted with the replacement penalty. Rebroadcasting randomly =
and multiple times before the next block increases the absolute fee cost fo=
r the attacker.</div><div><br></div><div>Implemented and deployed by Eclair=
, Core-Lightning, LND and LDK .</div><div><br></div><div>Local-mempool prei=
mage monitoring: As the replacement cycling attacker in a simple setup broa=
dcast the HTLC-preimage to all the network mempools, the honest lightning n=
ode is able to catch on the flight the unconfirmed HTLC-preimage, before it=
s subsequent mempool replacement. The preimage can be extracted from the se=
cond-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 out=
put.</div><div><br></div><div>Implemented and deployed by Eclair and LND.<b=
r></div><div><br></div><div>CLTV Expiry Delta: With every jammed block come=
s an absolute fee cost paid by the attacker, a risk of the HTLC-preimage be=
ing detected or discovered by the honest lightning node, or the HTLC-timeou=
t to slip in a winning block template. Bumping the default CLTV delta harde=
ns the odds of success of a simple replacement cycling attack.</div><div><b=
r></div><div>Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK=
 72.</div><div><br></div><div>## Affected Bitcoin Protocols and Application=
s</div><div><br></div><div>From my understanding the following list of Bitc=
oin protocols and applications could be affected by new denial-of-service v=
ectors under some level of network mempools congestion. Neither tests or ad=
vanced review of specifications (when available) has been conducted for eac=
h of them:</div><div>- on-chain DLCs</div><div>- coinjoins</div><div>- payj=
oins</div><div>- wallets with time-sensitive paths</div><div>- peerswap and=
 submarine swaps</div><div>- batch payouts</div><div>- transaction &quot;ac=
celerators&quot;</div><div><br></div><div>Inviting their developers, mainta=
iners and operators to investigate how replacement cycling attacks might di=
srupt their in-mempool chain of transactions, or fee-bumping flows at the s=
hortest delay. Simple flows and non-multi-party transactions should not be =
affected to the best of my understanding.</div><div><br></div><div>## Open =
Problems: Package Malleability</div><div><br></div><div>Pinning attacks hav=
e been known for years as a practical vector to compromise lightning channe=
ls funds safety, under different scenarios (cf. current bip331&#39;s motiva=
tion section). Mitigations at the mempool level have been designed, discuss=
ed and are under implementation by the community (ancestor package relay=C2=
=A0+ nverrsion=3D3 policy). Ideally, they should constraint a pinning attac=
ker to always attach a high feerate package (commitment=C2=A0+ CPFP) to rep=
lace the honest package, or allow a honest lightning node to overbid a mali=
cious pinning package and get its time-sensitive transaction optimistically=
 included in the chain.</div><div><br></div><div>Replacement cycling attack=
 seem to offer a new way to neutralize the design goals of package relay an=
d 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 c=
hild with a transaction unrelated to the channel. As the remaining commitme=
nt transaction is pre-signed with a minimal relay fee, it can be evicted ou=
t of the mempool.</div><div><br></div><div>A functional test exercising a s=
imple replacement cycling of a lightning channel commitment transaction on =
top of the nversion=3D3 code branch is available:</div><div><a href=3D"http=
s://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2">https://githu=
b.com/ariard/bitcoin/commits/2023-10-test-mempool-2</a><br></div><div><br><=
/div><div>## Discovery</div><div><br></div><div>In 2018, the issue of stati=
c 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.</div><div><br></div><d=
iv>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.</=
div><div><br></div><div>In 2020, draft of anchor output submitted to the bo=
lts. Initial finding of economic pinning against lightning commitment and s=
econd-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.</=
div><div><br></div><div>In 2021, initial work in bitcoin core 22.0 of packa=
ge 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.</div><div><br></div><div>In 2022, bip proposed =
for package relay and new proposed v3 policy design proposed for a review a=
nd implementation. Mempoolfullrbf is supported in bitcoin core 24.0 and con=
ceptual questions about alignment of mempool rules w.r.t miners incentives =
are investigated.</div><div><br></div><div>Along this year 2022, eltoo ligh=
tning channels design are discussed, implemented and reviewed. In this cont=
ext and after discussions on mempool anti-DoS rules, I discovered this new =
replacement cycling attack was affecting deployed lightning channels and im=
mediately reported the finding to some bitcoin core developers and lightnin=
g maintainers.</div><div><br></div><div>## Timeline</div><div><br></div><di=
v>- 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns, Greg=
 Sanders and Gloria Zhao</div><div>- 2022-12-16: Report to LN maintainers: =
Rusty Russell, Bastien Teinturier, Matt Corallo and Olaoluwa Osuntunkun</di=
v><div>- 2022-12-23: Sharing to Eugene Siegel (LND)</div><div>- 2022-12-24:=
 Sharing to James O&#39;Beirne and Antoine Poinsot (non-lightning potential=
 affected projects)</div><div>- 2022-01-14: Sharing to Gleb Naumenko (miner=
s incentives and cross-layers issuers) and initial proposal of an early pub=
lic disclosure=C2=A0</div><div>- 2022-01-19: Collection of analysis if othe=
r second-layers and multi-party applications affected. LN mitigations devel=
opment starts.</div><div>- 2023-05-04: Sharing to Wilmer Paulino (LDK)</div=
><div>- 2023-06-20: LN mitigations implemented and progressively released. =
Week of the 16 october proposed for full disclosure.</div><div>- 2023-08-10=
: CVEs assigned by MITRE</div><div>- 2023-10-05: Pre-disclosure of LN CVEs =
numbers and replacement cycling attack existence to <a href=3D"mailto:secur=
ity@bitcoincore.org">security@bitcoincore.org</a>.</div><div>- 2023-10-16: =
Full disclosure of CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2=
023-40234 and replacement cycling attacks</div><div><br></div><div>## Concl=
usion=C2=A0</div><div><br></div><div>Despite the line of mitigations adopte=
d and deployed by current major lightning implementations, I believe replac=
ement cycling attacks are still practical for advanced attackers. Beyond th=
is 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.<=
/div><div><br></div><div>As of today, it is uncertain to me if lightning is=
 not affected by a more severe long-term package malleability critical secu=
rity issue under current consensus rules, and if any other time-sensitive m=
ulti-party protocol, designed or deployed isn&#39;t de facto affected too (=
loss of funds or denial of service).</div><div><br></div><div>Assuming anal=
ysis on package malleability is correct, it is unclear to me if it can be c=
orrected by changes in replacement / eviction rules or mempool chain of tra=
nsactions processing strategy. Inviting my technical peers and the bitcoin =
community to look more on this issue, including to dissent. I&#39;ll be the=
 first one pleased if I&#39;m fundamentally wrong on those issues, or if an=
y element has not been weighted with the adequate technical accuracy it des=
erves.</div><div><br></div><div>Do not trust, verify. All mistakes and opin=
ions are my own.</div><div><br></div><div>Antoine</div><div><br></div><div>=
&quot;meet with Triumph and Disaster. And treat those two impostors just th=
e same&quot; - K.</div></div>

--00000000000039e7790607d84e45--