📅 Original date posted:2023-10-16
🗒️ Summary of this message: The email acknowledges the recipient's efforts in reporting an issue and discusses the implementation of mitigations in the lnd software. It also mentions the discovery of a transaction-relay jamming attack affecting lightning channels and the deployment of mitigations by major lightning implementations. The email concludes by mentioning the need to determine the robustness of the deployed mitigations against advanced attackers.
📝 Original message:
Hi Antoine,
Thanks for this great write up, and also your diligence in reporting this
issue to the various implementations, and game planning with us re
mitigations and attack scenarios.
One small clarification: all of lnd's relevant mitigations were in place by
lnd v0.16.1-beta [1], which was released on April 24th 2023. Since then
we've fixed some performance regressions introduced due to some of the
mitigations (mempool watching), and in 0.17.1 we'll start to use the new
`gettxspendingprevout` RPC call with bitcoind to further reduce load.
[1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.1-beta
-- Laolu
On Mon, Oct 16, 2023 at 10:04 AM Antoine Riard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> 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 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 at 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231016/cef364c3/attachment-0001.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-10-18 13:02:09
in reply to nevent1q…gsqj
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-10-18 13:02:09Event JSON
{
"id": "80bf0a27c8e0fb67360680c04ddf16ee50f5db5e020ec7c46365f21fe1060064",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1697634129,
"kind": 1,
"tags": [
[
"e",
"30d74c5c575ec4ae2016332e3990c377c0cf8e6c512e6aed10460350de45a5d2",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2023-10-16\n🗒️ Summary of this message: The email acknowledges the recipient's efforts in reporting an issue and discusses the implementation of mitigations in the lnd software. It also mentions the discovery of a transaction-relay jamming attack affecting lightning channels and the deployment of mitigations by major lightning implementations. The email concludes by mentioning the need to determine the robustness of the deployed mitigations against advanced attackers.\n📝 Original message:\nHi Antoine,\n\nThanks for this great write up, and also your diligence in reporting this\nissue to the various implementations, and game planning with us re\nmitigations and attack scenarios.\n\nOne small clarification: all of lnd's relevant mitigations were in place by\nlnd v0.16.1-beta [1], which was released on April 24th 2023. Since then\nwe've fixed some performance regressions introduced due to some of the\nmitigations (mempool watching), and in 0.17.1 we'll start to use the new\n`gettxspendingprevout` RPC call with bitcoind to further reduce load.\n\n[1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.1-beta\n\n-- Laolu\n\nOn Mon, Oct 16, 2023 at 10:04 AM Antoine Riard via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e (cross-posting mempool issues identified are exposing lightning chan to\n\u003e loss of funds risks, other multi-party bitcoin apps might be affected)\n\u003e\n\u003e Hi,\n\u003e\n\u003e End of last year (December 2022), amid technical discussions on eltoo\n\u003e payment channels and incentives compatibility of the mempool anti-DoS\n\u003e rules, a new transaction-relay jamming attack affecting lightning channels\n\u003e was discovered.\n\u003e\n\u003e After careful analysis, it turns out this attack is practical and\n\u003e immediately exposed lightning routing hops carrying HTLC traffic to loss of\n\u003e funds security risks, both legacy and anchor output channels. A potential\n\u003e exploitation plausibly happening even without network mempools congestion.\n\u003e\n\u003e Mitigations have been designed, implemented and deployed by all major\n\u003e lightning implementations during the last months.\n\u003e\n\u003e Please find attached the release numbers, where the mitigations should be\n\u003e present:\n\u003e - LDK: v0.0.118 - CVE-2023 -40231\n\u003e - Eclair: v0.9.0 - CVE-2023-40232\n\u003e - LND: v.0.17.0-beta - CVE-2023-40233\n\u003e - Core-Lightning: v.23.08.01 - CVE-2023-40234\n\u003e\n\u003e While neither replacement cycling attacks have been observed or reported\n\u003e in the wild since the last ~10 months or experimented in real-world\n\u003e conditions on bitcoin mainet, functional test is available exercising the\n\u003e affected lightning channel against bitcoin core mempool (26.0 release\n\u003e cycle).\n\u003e\n\u003e It is understood that a simple replacement cycling attack does not demand\n\u003e privileged capabilities from an attacker (e.g no low-hashrate power) and\n\u003e only access to basic bitcoin and lightning software. Yet I still think\n\u003e executing such an attack successfully requests a fair amount of bitcoin\n\u003e technical know-how and decent preparation.\n\u003e\n\u003e From my understanding of those issues, it is yet to be determined if the\n\u003e mitigations deployed are robust enough in face of advanced replacement\n\u003e cycling attackers, especially ones able to combine different classes of\n\u003e transaction-relay jamming such as pinnings or vetted with more privileged\n\u003e capabilities.\n\u003e\n\u003e Please find a list of potential affected bitcoin applications in this full\n\u003e disclosure report using bitcoin script timelocks or multi-party\n\u003e transactions, albeit no immediate security risk exposure as severe as the\n\u003e ones affecting lightning has been identified. Only cursory review of\n\u003e non-lightning applications has been conducted so far.\n\u003e\n\u003e There is a paper published summarizing replacement cycling attacks on the\n\u003e lightning network:\n\u003e\n\u003e https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf\n\u003e\n\u003e ## Problem\n\u003e\n\u003e A lightning node allows HTLCs forwarding (in bolt3's parlance accepted\n\u003e HTLC on incoming link and offered HTLC on outgoing link) should settle the\n\u003e outgoing state with either a success or timeout before the incoming state\n\u003e timelock becomes final and an asymmetric defavorable settlement might\n\u003e happen (cf \"Flood \u0026 Loot: A Systematic Attack on The Lightning Network\"\n\u003e section 2.3 for a classical exposition of this lightning security property).\n\u003e\n\u003e Failure to satisfy this settlement requirement exposes a forwarding hop to\n\u003e a loss of fund risk where the offered HTLC is spent by the outgoing link\n\u003e counterparty's HTLC-preimage and the accepted HTLC is spent by the incoming\n\u003e link counterparty's HTLC-timeout.\n\u003e\n\u003e The specification mandates the incoming HTLC expiration timelock to be\n\u003e spaced out by an interval of `cltv_expiry_delta` from the outgoing HTLC\n\u003e expiration timelock, this exact interval value being an implementation and\n\u003e node policy setting. As a minimal value, the specification recommends 34\n\u003e blocks of interval. If the timelock expiration I of the inbound HTLC is\n\u003e equal to 100 from chain tip, the timelock expiration O of the outbound HTLC\n\u003e must be equal to 66 blocks from chain tip, giving a reasonable buffer of\n\u003e reaction to the lightning forwarding node.\n\u003e\n\u003e In the lack of cooperative off-chain settlement of the HTLC on the\n\u003e outgoing link negotiated with the counterparty (either\n\u003e `update_fulfill_htlc` or `update_fail_htlc`) when O is reached, the\n\u003e lightning node should broadcast its commitment transaction. Once the\n\u003e commitment is confirmed (if anchor and the 1 CSV encumbrance is present),\n\u003e the lightning node broadcasts and confirms its HTLC-timeout before I height\n\u003e is reached.\n\u003e\n\u003e Here enter a replacement cycling attack. A malicious channel counterparty\n\u003e can broadcast its HTLC-preimage transaction with a higher absolute fee and\n\u003e higher feerate than the honest HTLC-timeout of the victim lightning node\n\u003e and triggers a replacement. Both for legacy and anchor output channels, a\n\u003e HTLC-preimage on a counterparty commitment transaction is malleable, i.e\n\u003e additional inputs or outputs can be added. The HTLC-preimage spends an\n\u003e unconfirmed and unrelated to the channel parent transaction M and conflicts\n\u003e its child.\n\u003e\n\u003e As the HTLC-preimage spends an unconfirmed input that was already included\n\u003e in the unconfirmed and unrelated child transaction (rule 2), pays an\n\u003e absolute higher fee of at least the sum paid by the HTLC-timeout and child\n\u003e transaction (rule 3) and the HTLC-preimage feerate is greater than all\n\u003e directly conflicting transactions (rule 6), the replacement is accepted.\n\u003e The honest HTLC-timeout is evicted out of the mempool.\n\u003e\n\u003e In an ulterior move, the malicious counterparty can replace the parent\n\u003e transaction itself with another candidate N satisfying the replacement\n\u003e rules, triggering the eviction of the malicious HTLC-preimage from the\n\u003e mempool as it was a child of the parent T.\n\u003e\n\u003e There is no spending candidate of the offered HTLC output for the current\n\u003e block laying in network mempools.\n\u003e\n\u003e This replacement cycling tricks can be repeated for each rebroadcast\n\u003e attempt of the HTLC-timeout by the honest lightning node until expiration\n\u003e of the inbound HTLC timelock I. Once this height is reached a HTLC-timeout\n\u003e is broadcast by the counterparty's on the incoming link in collusion with\n\u003e the one on the outgoing link broadcasting its own HTLC-preimage.\n\u003e\n\u003e The honest Lightning node has been \"double-spent\" in its HTLC forwarding.\n\u003e\n\u003e As a notable factor impacting the success of the attack, a lightning\n\u003e node's honest HTLC-timeout might be included in the block template of the\n\u003e miner winning the block race and therefore realizes a spent of the offered\n\u003e output. In practice, a replacement cycling attack might over-connect to\n\u003e miners' mempools and public reachable nodes to succeed in a fast eviction\n\u003e of the HTLC-timeout by its HTLC-preimage. As this latter transaction can\n\u003e come with a better ancestor-score, it should be picked up on the flight by\n\u003e economically competitive miners.\n\u003e\n\u003e A functional test exercising a simple replacement cycling of a HTLC\n\u003e transaction on bitcoin core mempool is available:\n\u003e https://github.com/ariard/bitcoin/commits/2023-test-mempool\n\u003e\n\u003e ## Deployed LN mitigations\n\u003e\n\u003e Aggressive rebroadcasting: As the replacement cycling attacker benefits\n\u003e from the HTLC-timeout being usually broadcast by lightning nodes only once\n\u003e every block, or less the replacement cycling malicious transactions paid\n\u003e only equal the sum of the absolute fees paid by the HTLC, adjusted with the\n\u003e replacement penalty. Rebroadcasting randomly and multiple times before the\n\u003e next block increases the absolute fee cost for the attacker.\n\u003e\n\u003e Implemented and deployed by Eclair, Core-Lightning, LND and LDK .\n\u003e\n\u003e Local-mempool preimage monitoring: As the replacement cycling attacker in\n\u003e a simple setup broadcast the HTLC-preimage to all the network mempools, the\n\u003e honest lightning node is able to catch on the flight the unconfirmed\n\u003e HTLC-preimage, before its subsequent mempool replacement. The preimage can\n\u003e be extracted from the second-stage HTLC-preimage and used to fetch the\n\u003e off-chain inbound HTLC with a cooperative message or go on-chain with it to\n\u003e claim the accepted HTLC output.\n\u003e\n\u003e Implemented and deployed by Eclair and LND.\n\u003e\n\u003e CLTV Expiry Delta: With every jammed block comes an absolute fee cost paid\n\u003e by the attacker, a risk of the HTLC-preimage being detected or discovered\n\u003e by the honest lightning node, or the HTLC-timeout to slip in a winning\n\u003e block template. Bumping the default CLTV delta hardens the odds of success\n\u003e of a simple replacement cycling attack.\n\u003e\n\u003e Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72.\n\u003e\n\u003e ## Affected Bitcoin Protocols and Applications\n\u003e\n\u003e From my understanding the following list of Bitcoin protocols and\n\u003e applications could be affected by new denial-of-service vectors under some\n\u003e level of network mempools congestion. Neither tests or advanced review of\n\u003e specifications (when available) has been conducted for each of them:\n\u003e - on-chain DLCs\n\u003e - coinjoins\n\u003e - payjoins\n\u003e - wallets with time-sensitive paths\n\u003e - peerswap and submarine swaps\n\u003e - batch payouts\n\u003e - transaction \"accelerators\"\n\u003e\n\u003e Inviting their developers, maintainers and operators to investigate how\n\u003e replacement cycling attacks might disrupt their in-mempool chain of\n\u003e transactions, or fee-bumping flows at the shortest delay. Simple flows and\n\u003e non-multi-party transactions should not be affected to the best of my\n\u003e understanding.\n\u003e\n\u003e ## Open Problems: Package Malleability\n\u003e\n\u003e Pinning attacks have been known for years as a practical vector to\n\u003e compromise lightning channels funds safety, under different scenarios (cf.\n\u003e current bip331's motivation section). Mitigations at the mempool level have\n\u003e been designed, discussed and are under implementation by the community\n\u003e (ancestor package relay + nverrsion=3 policy). Ideally, they should\n\u003e constraint a pinning attacker to always attach a high feerate package\n\u003e (commitment + CPFP) to replace the honest package, or allow a honest\n\u003e lightning node to overbid a malicious pinning package and get its\n\u003e time-sensitive transaction optimistically included in the chain.\n\u003e\n\u003e Replacement cycling attack seem to offer a new way to neutralize the\n\u003e design goals of package relay and its companion nversion=3 policy, where an\n\u003e attacker package RBF a honest package out of the mempool to subsequently\n\u003e double-spend its own high-fee child with a transaction unrelated to the\n\u003e channel. As the remaining commitment transaction is pre-signed with a\n\u003e minimal relay fee, it can be evicted out of the mempool.\n\u003e\n\u003e A functional test exercising a simple replacement cycling of a lightning\n\u003e channel commitment transaction on top of the nversion=3 code branch is\n\u003e available:\n\u003e https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2\n\u003e\n\u003e ## Discovery\n\u003e\n\u003e In 2018, the issue of static fees for pre-signed lightning transactions is\n\u003e made more widely known, the carve-out exemption in mempool rules to\n\u003e mitigate in-mempool package limits pinning and the anchor output pattern\n\u003e are proposed.\n\u003e\n\u003e In 2019, bitcoin core 0.19 is released with carve-out support. Continued\n\u003e discussion of the anchor output pattern as a dynamic fee-bumping method.\n\u003e\n\u003e In 2020, draft of anchor output submitted to the bolts. Initial finding of\n\u003e economic pinning against lightning commitment and second-stage HTLC\n\u003e transactions. Subsequent discussions of a preimage-overlay network or\n\u003e package-relay as mitigations. Public call made to inquiry more on potential\n\u003e other transaction-relay jamming attacks affecting lightning.\n\u003e\n\u003e In 2021, initial work in bitcoin core 22.0 of package acceptance.\n\u003e Continued discussion of the pinning attacks and shortcomings of current\n\u003e mempool rules during community-wide online workshops. Later the year, in\n\u003e light of all issues for bitcoin second-layers, a proposal is made about\n\u003e killing the mempool.\n\u003e\n\u003e In 2022, bip proposed for package relay and new proposed v3 policy design\n\u003e proposed for a review and implementation. Mempoolfullrbf is supported in\n\u003e bitcoin core 24.0 and conceptual questions about alignment of mempool rules\n\u003e w.r.t miners incentives are investigated.\n\u003e\n\u003e Along this year 2022, eltoo lightning channels design are discussed,\n\u003e implemented and reviewed. In this context and after discussions on mempool\n\u003e anti-DoS rules, I discovered this new replacement cycling attack was\n\u003e affecting deployed lightning channels and immediately reported the finding\n\u003e to some bitcoin core developers and lightning maintainers.\n\u003e\n\u003e ## Timeline\n\u003e\n\u003e - 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns, Greg\n\u003e Sanders and Gloria Zhao\n\u003e - 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien Teinturier,\n\u003e Matt Corallo and Olaoluwa Osuntunkun\n\u003e - 2022-12-23: Sharing to Eugene Siegel (LND)\n\u003e - 2022-12-24: Sharing to James O'Beirne and Antoine Poinsot (non-lightning\n\u003e potential affected projects)\n\u003e - 2022-01-14: Sharing to Gleb Naumenko (miners incentives and cross-layers\n\u003e issuers) and initial proposal of an early public disclosure\n\u003e - 2022-01-19: Collection of analysis if other second-layers and\n\u003e multi-party applications affected. LN mitigations development starts.\n\u003e - 2023-05-04: Sharing to Wilmer Paulino (LDK)\n\u003e - 2023-06-20: LN mitigations implemented and progressively released. Week\n\u003e of the 16 october proposed for full disclosure.\n\u003e - 2023-08-10: CVEs assigned by MITRE\n\u003e - 2023-10-05: Pre-disclosure of LN CVEs numbers and replacement cycling\n\u003e attack existence to security at bitcoincore.org.\n\u003e - 2023-10-16: Full disclosure of CVE-2023-40231 / CVE-2023-40232 /\n\u003e CVE-2023-40233 / CVE-2023-40234 and replacement cycling attacks\n\u003e\n\u003e ## Conclusion\n\u003e\n\u003e Despite the line of mitigations adopted and deployed by current major\n\u003e lightning implementations, I believe replacement cycling attacks are still\n\u003e practical for advanced attackers. Beyond this new attack might come as a\n\u003e way to partially or completely defeat some of the pinning mitigations which\n\u003e have been working for years as a community.\n\u003e\n\u003e As of today, it is uncertain to me if lightning is not affected by a more\n\u003e severe long-term package malleability critical security issue under current\n\u003e consensus rules, and if any other time-sensitive multi-party protocol,\n\u003e designed or deployed isn't de facto affected too (loss of funds or denial\n\u003e of service).\n\u003e\n\u003e Assuming analysis on package malleability is correct, it is unclear to me\n\u003e if it can be corrected by changes in replacement / eviction rules or\n\u003e mempool chain of transactions processing strategy. Inviting my technical\n\u003e peers and the bitcoin community to look more on this issue, including to\n\u003e dissent. I'll be the first one pleased if I'm fundamentally wrong on those\n\u003e issues, or if any element has not been weighted with the adequate technical\n\u003e accuracy it deserves.\n\u003e\n\u003e Do not trust, verify. All mistakes and opinions are my own.\n\u003e\n\u003e Antoine\n\u003e\n\u003e \"meet with Triumph and Disaster. And treat those two impostors just the\n\u003e same\" - K.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231016/cef364c3/attachment-0001.html\u003e",
"sig": "64728a3950e917684d0c1c8f80163f21c2f3c3313195ab7922826fbe6fc8ab10ae63731791ed4b4f7fd0ba2e947c409eda7402f1c42a47ef098f9807d6847fbe"
}