Delivery-date: Sat, 25 May 2024 01:57:08 -0700 Received: from mail-yw1-f186.google.com ([209.85.128.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sAnD7-0001qV-OO for bitcoindev@gnusha.org; Sat, 25 May 2024 01:57:07 -0700 Received: by mail-yw1-f186.google.com with SMTP id 00721157ae682-627956be166sf18543997b3.0 for ; Sat, 25 May 2024 01:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1716627419; x=1717232219; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=JJsN0jwuNGjLq5xPsye7bLaGHfNFOgjvh43BR35bMvY=; b=VzdhVUHBYPTUWvQRqc9vzFo+DRWeHrbKFndeldoXUQWQ8Eh52QA9VF66dDt5nyu/vs g9qOW3L5oQFJxqeeW72MSxPsN8qe7R4Qw/R0X6rrWDzUWvj8j9lgYQg12I9bSMFjrtO/ WthCDgh+55HUa6DzXdZ1mbJ+vwOrp+ECLbIUDmOBqovMRl0ypflff1QHuglw6ftkWAa5 k90UlKmW60FoM/ZMner8UlB3X0ISJq19Qt/bET6Nt9KvcOKpKB88e4yHDRL68Tn+1CPk rDYRx7+8p5rjtn3GauIX89ChBBNuGPDDGFxsh+cLHJGhIkpE149q7KSmQjMZs471knJm IWyg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716627419; x=1717232219; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=JJsN0jwuNGjLq5xPsye7bLaGHfNFOgjvh43BR35bMvY=; b=i6JC7YfyRpAf7ydRDWq6mna+mqHHpNj0IuAUexmJ3pIcztB+SAH5imyo99sGdGbRMJ wnLoctDzWNzP9QJwz1uukyJwWcwKPoEmJ9RaqObhGHcmHjf1vMs/jGSIlnBiUI6e0Bnb qJFWxNDm61nqj3HDXAXJ9uK3jkoRIC6LWWOkkys5KeDKv+pODLxf0oVdHSKKvvvx2uPt GGC/WrbCAKjZk/71pqNOYWefDpz1ei37UWwCQDCFPoeO0YEm+ryP1xoKTZMr2NusMDCw pBKczinE1/jJ3u2rZ6Ju55Y3gfV2PiCEPcKXcXgo9AGpnQBnGkma8tt6lSca0u/7cC2d vt4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716627419; x=1717232219; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=JJsN0jwuNGjLq5xPsye7bLaGHfNFOgjvh43BR35bMvY=; b=Mvb+0Eo7JfuoYgsjUDN+71DYaU8IEpEae3Lc2aGOeOUTMUIDa0ft1dHeNGf2042DIZ oEzKZq3sEDtMv0vNkrQaqXOzB3VowNwWGrFRRWdG716tG6X1NO5N7PdfmugtIS5TwWaS NhbbefPb5sMZfuK66cb6rfmMtvASO0ij1mNHwOOmeZntNuUdyOIhzRtLT6Tbj+6u38xU QM1LhY7UxUQs+qyyCIdkOFx8tU+8AhWOGa/AdWeJ5+HOk4+GVpe9msG0OV88+sIOWZO1 Dritz1kSOZjdLuuaDZAUTxcP+EOI+dEw6hsieH3CGpcUY+v6MMilP3Y+fT1SrqbTuz7k bEOA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWALTDwyM6yBf6aHcjQvZni9/6h8IZbHzNFWO7YuglEW3lEx8+Z9aciO3pnMEJQXaukjTCBxXxRzso9FsW8OZofyUAcMbg= X-Gm-Message-State: AOJu0Yyn2sOBlYsOp1oBZ0uDO3RKYnQGDb4hgdpIbelII1Uu1QCHOP4C hWG++tM1EiLSHDqp8154i5aGsiL03ZqHRW3fuwLST0g5QMky0dAC X-Google-Smtp-Source: AGHT+IF90zDwVzG2nHHyPq/8jC0vLEszsUybjr+vBSswuz4ZjS05MFEkiK3IFbnlTz7VwbZFH8dTKA== X-Received: by 2002:a25:ab0e:0:b0:df4:eb0b:8fc with SMTP id 3f1490d57ef6-df77221668fmr4291969276.43.1716627418989; Sat, 25 May 2024 01:56:58 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:84cb:0:b0:df7:71d2:bccb with SMTP id 3f1490d57ef6-df771d2be6els10169276.1.-pod-prod-00-us; Sat, 25 May 2024 01:56:57 -0700 (PDT) X-Received: by 2002:a05:690c:600b:b0:611:5a9d:bb0e with SMTP id 00721157ae682-62a076284d6mr11125577b3.4.1716627417281; Sat, 25 May 2024 01:56:57 -0700 (PDT) Received: by 2002:a05:690c:2b83:b0:620:26bb:319f with SMTP id 00721157ae682-62a0b4bcbe4ms7b3; Fri, 24 May 2024 16:54:24 -0700 (PDT) X-Received: by 2002:a25:df8c:0:b0:dee:7f2c:ad90 with SMTP id 3f1490d57ef6-df7721f9d09mr1007425276.10.1716594862958; Fri, 24 May 2024 16:54:22 -0700 (PDT) Date: Fri, 24 May 2024 16:54:22 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <1c76a89a-3e8c-4b40-9f23-8f8e44ceaf1en@googlegroups.com> References: <1c76a89a-3e8c-4b40-9f23-8f8e44ceaf1en@googlegroups.com> Subject: [bitcoindev] Re: Analysis of Replacement Cycling Attacks Risks on L2s (beyond LN) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_78197_1136865387.1716594862611" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_78197_1136865387.1716594862611 Content-Type: multipart/alternative; boundary="----=_Part_78198_1250213256.1716594862611" ------=_Part_78198_1250213256.1716594862611 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi /dev/fd0 From my understanding of coinswap (model: cf. "Detailed protocol design for= =20 routed multi-transaction CoinSwap"), the contract transaction can be spend= =20 by either Alice timeout or Bob preimage. Belcher's coinswap (a contracting= =20 protocol) does not strictly restrain the second-stage transaction spending= =20 the contract transaction. Let's say you have Caroll -> Alice -> Bob as a routed coinswap topology.=20 Bob can broadcast a contract transaction, get it confirmed, then engage in= =20 replacement cycling attack by leveraging a child transaction spending the= =20 preimage path (it's only Bob private key), then continuously replacing this= =20 child by.conflicting a UTXO non related to the coinswap. At expiration of= =20 the relative timelock on C-A link, Caroll clawback the swapped UTXO with=20 the timeout path. If this transaction flow is the correct one, coinswap suffers from loss of= =20 funds and denial-of-service risks, at the image of lightning. Scaling up=20 timelocks or monitoring the local mempool for preimage might be imperfect,= =20 yet practical mitigations hardening against exploitations. Best, Antoine Le vendredi 24 mai 2024 =C3=A0 11:59:28 UTC+1, /dev /fd0 a =C3=A9crit : > Hi Antoine, > > Does this also affect coinswap=20 > ?=20 > If yes, what are the risks involved? > > /dev/fd0 > floppy disk guy > > On Thursday, May 23, 2024 at 4:09:25=E2=80=AFAM UTC Antoine Riard wrote: > >> Hi, >> >> Following up on detailing more the non-lightning bitcoin use-cases=20 >> affected by replacement cycling attacks, mostly under the denial-of-serv= ice=20 >> angle (cf. "All your mempool are belong to us" - bitcoin-dev 2023). >> >> Excerpt from the original public disclosure: >> >> >From my understanding the following list of Bitcoin protocols and >> > applications could be affected by new denial-of-service vectors under= =20 >> some >> > level of network mempools congestion. Neither tests or advanced review= =20 >> 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" >> >=20 >> > Inviting their developers, maintainers and operators to investigate ho= w >> > replacement cycling attacks might disrupt their in-mempool chain of >> > transactions, or fee-bumping flows at the shortest delay. >> >> Also, this post intends to provide the lineaments of a common template t= o=20 >> be useful in case of future cross-layer security issues arising in the= =20 >> bitcoin ecosystem. Such template to be leveraged by any skilled folk=20 >> involved in the resolution of a cross-layer security-issue handling proc= ess. >> >> (To be understood: without the necessary tangible involvement of the=20 >> present author post, there is a sufficient number of other folks in this= =20 >> ecosystem with the skillset and _the guts_ to conduct such process in a= =20 >> reasonable fashion in the future). >> >> ## Replacement Cycling Attack (a quick reminder) >> >> The attacker goal of a replacement cycling attack is to delay the=20 >> confirmation of a HTLC-timeout on an outgoing link of a routing node,=20 >> sufficiently to enable an off-chain double-spend of a HTLC-preimage on a= n=20 >> incoming link. >> >> The attack scenario works in the following ways: >> - Assume the Mallory - Alice - Mallet channel topology >> - Mallory forwards a HTLC of 1 BTC to Mallet by the intermediary of Alic= e >> - This HTLC expires at chain tip + 100 outgoing link, chain tip + 140=20 >> incoming link (Alice Pov) >> - Mallet receives the HTLC on the Alice-Mallet links and does not settle= =20 >> it >> - At chain tip + 100, Alice broadcasts commitment tx + HTLC-timeout tx >> - Mallet replaces Alice's HTLC-timeout tx with a HTLC-preimage tx >> - Mallet then replaces HTLC-preimage with a conflicting double-spend >> - Mallet repeats this trick until chain tip reaches tip + 140 >> - When chain tip + 140, Mallory broadcasts HTLC-timeout to double-spend= =20 >> incoming link >> - In parallel, Mallet broadcasts a HTLC-preimage to double-spend the=20 >> forwarding link >> >> This is a rough summary of one of the simplest scenario, for further=20 >> details refers back to the original public disclosure, already cf. above= . >> >> ## Conditions of Attacks Exploitation >> >> From my understanding, protocols and applications with a subset of the= =20 >> following characteristics can be affected by a replacement cycling attac= k. >> >> a) Shared-UTXO spendings. Two or more distinct users each owns at least = a=20 >> spending path in a redeem script encumbering a single coin. >> >> b) Join-UTXO spendings. Two or more distinct users each contributes a=20 >> coin spend or destination outputs to a common transaction. Each user can= =20 >> commit more than one coin to the common transaction. >> >> c) Pre-signed transactions. The group of users is pre-signing a chain of= =20 >> transactions to execute the protocol steps during an interactive phase.= =20 >> After this phase, any user can broadcast the transaction at any time,=20 >> without further interactivity. >> >> d) Absolute / Relative Timelocks. The set of pre-signed transactiosn=20 >> might be encumbered by relative (nSequence) or absolute timelocks=20 >> (nLockTime). >> >> If you combine b) + c) you have things like coinjoins. If you combine a)= =20 >> + c) + d) you have things like lightning. Usually, the first class of=20 >> things have been designated as a multi-party application, the second cla= ss=20 >> of things a contracting protocol (e.g on the effects of mempool policy= =20 >> changes). >> >> This distinction mostly matters in term of security models. All of them= =20 >> sounds to present some vector of transaction or package malleability. >> >> ## Time-value Denial-of-Service Risks >> >> Leveraging transaction-relay and mempools mechanism to trigger a=20 >> time-value denial-of-service in a target application or protocol phase h= as=20 >> already been considered many times in the past. >> >> E.g reaching hypothetical replacement limits to DoS payment channels=20 >> participants (cf. "Anti DoS for tx replacement" - bitcoin-dev 2013) or= =20 >> DoSing a multi-party transaction by opt-ing out from replacement with a= =20 >> double-spend (cf. "On Mempool Funny Games against Multi-Party Funded=20 >> Transactions" - lightning-dev 2021). >> >> Under current mempool rules (i.e ones deployed on 99% of network over th= e=20 >> last years), a replacement cycling opens a new generic way to trigger a= =20 >> denial-of-service in a Bitcoin application or protocol flow to paralyze = the=20 >> execution. >> >> This denial-of-service can constitute a prolonged denial-of-service of= =20 >> the targeted application / protocol, or a waste of the on-chain timevalu= e=20 >> of the coins consumed by the application / protocol. Here again, risks= =20 >> exposures is function of the application / protocol concrete combination= of=20 >> characteristics. >> >> Some protocols have lightweight anti-DoS measures to alleviate this=20 >> vector of denial-of-concern. E.g in lightning after 2016 blocks,=20 >> participants to a payment channel can forget the funding transaction=20 >> (BOLT2). >> >> ## Time-value Denial-of-Service Risks: The Lightning One-Link Case >> >> Let's see a concrete example of a time-value DoS triggered by a=20 >> replacement cycling. >> >> The public disclosure of replacement cycling attack has been mostly=20 >> centered on loss of funds risks affecting HTLC forwarding over Lightning= =20 >> routing nodes. Independently, a replacement cycling attack can be levera= ged=20 >> to provoke denial-of-service among a Lightning routing node and an end-n= ode=20 >> on a spoke link. >> >> The attack works in the following fashion (offered HTLC on outgoing link= )=20 >> as it was not fully fleshed out in the disclosure communications: >> - Alice and Bob are lightning nodes, they share a funded chan >> - Alice forwads a HTLC to Bob for further routing to Caroll >> - Bob forwards the HTLC to Caroll and gets the HTLC preimage >> - Bob witholds settltement on Alice - Bob link until chain tip height=20 >> reaches `cltv_expiry` >> - Alice broadcast a HTLC-timeout to recover her funds >> - Bob engages in a replacement cycling by repeatedly rebroadcasting the= =20 >> HTLC-preimage and double-spending it >> >> Alice is stuck with her HTLC funds that cannot be recovered on-chain.=20 >> While Bob is paying a replacement penalty every time it happens, there= =20 >> might be a scaling effect targeting many HTLC-timeout with a single HTLC= =20 >> preimage (`option_anchors_zero_fee_htlc_tx`). >> >> It should be noted that in matters of offered HTLC expiration on an=20 >> outgoing link, each lightning implementation has its own logic, as this = is=20 >> not something standardized (e.g ldk's `LATENCY_GRACE_PERIOD_BLOCKS`). >> >> It is left as an open question how an an attacker can economically=20 >> benefit from this denial-of-service. >> >> ## Loss of Funds Risks >> >> As it has been exposed during the public disclosure of the replacement= =20 >> cycling attack, it can be leveraged to steal users funds from lightning= =20 >> payment channels, as one protocol affected. >> >> As an extension, it can affect any other contracting protocol=20 >> (characterisics a. + c. + d.). On those protocols (e.g lightning or swap= s),=20 >> the protocol semantic is driven by absolute / relative timelocks=20 >> initialized in a set of pre-signed transactions and finalized by the cha= in=20 >> tip height or epoch time. >> >> The underlying funds security is conditional on the time-sensitive=20 >> broadcast and inclusion of the pre-signed transactions to execute an=20 >> off-chain state. Failing to fulfill this time-sensitive requirement can= =20 >> lead to loss of funds. >> >> Generally, loss of funds risks affecting a multi-party application /=20 >> contracting protocols still depends on the usage of "short duration" of= =20 >> relative / absolute timelocks. >> >> ## Second-Layers and Use-Cases >> >> We're further surveying deployed second-layers and use-cases either=20 >> affected by time-value DoS or loss of funds risks. >> >> (Transaction-relay technique like "transaction accelerators" have been= =20 >> excluded from the list of potentially affected second-layers initially= =20 >> published, actually it's neither a multi-party application or contractin= g=20 >> protocol). >> >> On-chain DLC (contracting protocol): a funding transaction locks funds i= n=20 >> a 2-of-2. A subsequent pair of contract execution transaction encodes DL= C=20 >> result from oracle contribution. There can be a refund transaction under= =20 >> timelocks (model: cf. "dlcspecs" - github 2020). >> >> On-chain DLC risks: loss of funds _only if oracle gets wrong_. Time-valu= e=20 >> DoS risk on the funding transaction or with refund if timelock miselecti= on. >> >> Coinjoin (multi-party application): a single joint transaction with=20 >> contributions from N inputs (model: cf. "Coinjoin: Bitcoin privacy for t= he=20 >> real world" - bitcointalkg.org 2013) >> >> Coinjoin risks: no loss of funds risks. Time-value DoS risk, if a=20 >> fee-bumping of the joint transaction can be done by any user. >> >> Payjoin (multi-party application): a single joint transaction with=20 >> contributions from N inputs owned by a single user paying another user= =20 >> (model: cf. "improving privacy using pay-to-endpoint" - blockstream blog= =20 >> 2018). >> >> Payjoin risks: no loss of funds risks. Time-value DoS risk, if a=20 >> fee-bumping of the joint transaction can be done by any user. >> >> Wallet with time-sensitive paths (contracting protocols): a user locks u= p=20 >> funds with a set of pre-signed transactions. Each pre-signed transaction= =20 >> can have unique spending conditions and/or send to another user (model: = cf.=20 >> "bip65 op_checklocktimeverify" >> - bips 2014). >> >> Wallet with time-sensitive paths risks: loss of funds risk _only if spen= d=20 >> path to third-party with divergent interest and timelock miselection_.= =20 >> Time-value DoS risk _only if spend to third-party with divergent interes= t=20 >> and timelock miselection_. >> >> Peerswap and submarine swaps (contracting protocol): a funding=20 >> transaction locks funds in a 2-of-2. A swap can be spend by 3 subsequent= =20 >> transactions (invoice, coop, csv) to settle positively or negatively the= =20 >> state of the swap (model: cf. "peerswap" - element github 2022). >> >> Peerswap and submarine swaps risks: loss of funds risk if timelock=20 >> miselection. Time value DoS risk. >> >> Batch payouts (multi-party application): a single joint transactions wit= h=20 >> contributions from N inputs owned by a singler user paying a N number of= =20 >> users (model: cf. "scaling bitcoin using payment batching" - bitcoin opt= ech=20 >> 2021). >> >> Batch payouts risks: no loss of funds risks. Time-value DoS risk, if a= =20 >> fee-bumping of the joint transaction can be done by any user. >> >> For all those second-layers and use-cases risks identification, I think = a=20 >> replacement cycling attack is plausible, independently of the level of= =20 >> network mempools congestion. >> >> On this area, thanks to the insights and observation from folks who have= =20 >> participated in the initial security-handling around February 2023 - All= =20 >> names have already been listed in the initial email. >> >> ## Conclusion >> >> A transaction-relay jamming can be identified as a protocol counterparty= =20 >> or application participant interfering with the relay of transaction. If= =20 >> the transactions are time-sensitive per the protocol semantic, this=20 >> interference can constitute a loss of funds risk. If the transactions ar= e=20 >> only collaboratively built, this interference can constitute a timevalue= =20 >> DoS risk. Replacement cycling attack constitutes one variant of class of= =20 >> attacks, of which pinning is the other well-known variant. >> >> Additionally, in this context of class of attacks arising from the=20 >> interfacing of bitcoin applications and protocols with the base-layer=20 >> transaction-relay network and its mempools rules, it can be noteworthy t= o=20 >> under-light some observations concerning >> security-issue handling process. >> >> Firstly, there is not only a difficulty of diagnosticing correctly what= =20 >> specific bitcoin software is potentially affected. Establishing a releva= nt=20 >> diagnostic is not only saying what is affected, though also saying the t= ype=20 >> of risk exposures (e.g plain loss of funds, fee griefing, bandwidth=20 >> denial-of-service) grieving each specific software. >> >> Secondly, once the diagnostic is done, there is the curative phase where= =20 >> mitigation patches are developed and included in the codebase. Each=20 >> codebase is unique (e.g have its own language) and it can have its own= =20 >> usual release schedule, indicating a the rate at which a mitigation patc= h=20 >> can disseminate across its crowds of active users. >> >> Furthermore, in a decentralized ecosystem where each full-node can run= =20 >> its own configuration of mempool policy rules on a wide variety of hardw= are=20 >> host, not all mitigation strategies are equally viable. Considerations o= n=20 >> the same level have already been weighted in the past e.g at the occasio= n=20 >> of CVE-2021-31876 (replacement inheritance defect on bitcoin core). >> >> Don't trust, verify. All mistakes and opinions are my own. >> >> Cheers, >> Antoine >> > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/f9ac65db-9756-4c85-b376-6b6a286a2b2cn%40googlegroups.com. ------=_Part_78198_1250213256.1716594862611 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi /dev/fd0

From my understanding of coinswap (model: = cf. "Detailed protocol design for routed multi-transaction CoinSwap"), the = contract transaction can be spend by either Alice timeout or Bob preimage. = Belcher's coinswap (a contracting protocol) does not strictly restrain the = second-stage transaction spending the contract transaction.

Let's say you have Caroll -> Alice -> Bob as a routed coi= nswap topology. Bob can broadcast a contract transaction, get it confirmed,= then engage in replacement cycling attack by leveraging a child transactio= n spending the preimage path (it's only Bob private key), then continuously= replacing this child by.conflicting a UTXO non related to the coinswap. At= expiration of the relative timelock on C-A link, Caroll clawback the swapp= ed UTXO with the timeout path.

If this transacti= on flow is the correct one, coinswap suffers from loss of funds and denial-= of-service risks, at the image of lightning. Scaling up timelocks or monito= ring the local mempool for preimage might be imperfect, yet practical mitig= ations hardening against exploitations.

Best,
Antoine

Le vendredi 24 mai 2024 =C3=A0 11:59:28 UTC+1, /dev= /fd0 a =C3=A9crit=C2=A0:
Hi Antoine,

Does this also affect coinswap? If yes, what are the risks involved= ?

/dev/fd0
floppy disk guy

=
On Thursd= ay, May 23, 2024 at 4:09:25=E2=80=AFAM UTC Antoine Riard wrote:
Hi,

Following up on detail= ing more the non-lightning bitcoin use-cases affected by replacement cyclin= g attacks, mostly under the denial-of-service angle (cf. "All your mem= pool are belong to us" - bitcoin-dev 2023).

Excerpt from the or= iginal public disclosure:

>From my understanding the following li= st of Bitcoin protocols and
> applications could be affected by new d= enial-of-service vectors under some
> level of network mempools conge= stion. Neither tests or advanced review of
> specifications (when ava= ilable) has been conducted for each of them:
> - on-chain DLCs
>= ; - coinjoins
> - payjoins
> - wallets with time-sensitive path= s
> - peerswap and submarine swaps
> - batch payouts
> - = transaction "accelerators"
>
> Inviting their develo= pers, maintainers and operators to investigate how
> replacement cycl= ing attacks might disrupt their in-mempool chain of
> transactions, o= r fee-bumping flows at the shortest delay.

Also, this post intends t= o provide the lineaments of a common template to be useful in case of futur= e cross-layer security issues arising in the bitcoin ecosystem. Such templa= te to be leveraged by any skilled folk involved in the resolution of a cros= s-layer security-issue handling process.

(To be understood: without = the necessary tangible involvement of the present author post, there is a s= ufficient number of other folks in this ecosystem with the skillset and _th= e guts_ to conduct such =C2=A0process in a reasonable fashion in the future= ).

## Replacement Cycling Attack (a quick reminder)

The attac= ker goal of a replacement cycling attack is to delay the confirmation of a = HTLC-timeout on an outgoing link of a routing node, sufficiently to enable = an off-chain double-spend of a HTLC-preimage on an incoming link.

Th= e attack scenario works in the following ways:
- Assume the Mallory - Al= ice - Mallet channel topology
- Mallory forwards a HTLC of 1 BTC to Mall= et by the intermediary of Alice
- This HTLC expires at chain tip + 100 o= utgoing link, chain tip + 140 incoming link (Alice Pov)
- Mallet receive= s the HTLC on the Alice-Mallet links and does not settle it
- At chain t= ip + 100, Alice broadcasts commitment tx + HTLC-timeout tx
- Mallet repl= aces Alice's HTLC-timeout tx with a HTLC-preimage tx
- Mallet then r= eplaces HTLC-preimage with a conflicting double-spend
- Mallet repeats t= his trick until chain tip reaches tip + 140
- When chain tip + 140, Mall= ory broadcasts HTLC-timeout to double-spend =C2=A0incoming link
- In par= allel, Mallet broadcasts a HTLC-preimage to double-spend the forwarding lin= k

This is a rough summary of one of the simplest scenario, for furth= er details refers back to the original public disclosure, already cf. above= .

## Conditions of Attacks Exploitation

From my understanding= , protocols and applications with a subset of the following characteristics= can be affected by a replacement cycling attack.

a) Shared-UTXO spe= ndings. Two or more distinct users each owns at least a spending path in a = redeem script encumbering a single coin.

b) Join-UTXO spendings. Two= or more distinct users each contributes a coin spend or destination output= s to a common transaction. Each user can commit more than one coin to the c= ommon transaction.

c) Pre-signed transactions. The group of users is= pre-signing a chain of transactions to execute the protocol steps during a= n interactive phase. After this phase, any user can broadcast the transacti= on at any time, without further interactivity.

d) Absolute / Relativ= e Timelocks. The set of pre-signed transactiosn might be encumbered by rela= tive (nSequence) or absolute timelocks (nLockTime).

If you combine b= ) + c) you have things like coinjoins. If you combine a) + c) + d) you have= things like lightning. Usually, the first class of things have been design= ated as a multi-party application, the second class of things a contracting= protocol (e.g on the effects of mempool policy changes).

This disti= nction mostly matters in term of security models. All of them sounds to pre= sent some vector of transaction or package malleability.

## Time-val= ue Denial-of-Service Risks

Leveraging transaction-relay and mempools= mechanism to trigger a time-value denial-of-service in a target applicatio= n or protocol phase has already been considered many times in the past.
=
E.g reaching hypothetical replacement limits to DoS payment channels pa= rticipants (cf. "Anti DoS for tx replacement" - bitcoin-dev 2013)= or DoSing a multi-party transaction by opt-ing out from replacement with a= double-spend (cf. "On Mempool Funny Games against Multi-Party Funded = Transactions" - lightning-dev 2021).

Under current mempool rule= s (i.e ones deployed on 99% of network over the last years), a replacement = cycling opens a new generic way to trigger a denial-of-service in a Bitcoin= application or protocol flow to paralyze the execution.

This denial= -of-service can constitute a prolonged denial-of-service of the targeted ap= plication / protocol, or a waste of the on-chain timevalue of the coins con= sumed by the application / protocol. Here again, risks exposures is functio= n of the application / protocol concrete combination of characteristics.
Some protocols have lightweight anti-DoS measures to alleviate this ve= ctor of denial-of-concern. E.g in lightning after 2016 blocks, participants= to a payment channel can forget the funding transaction (BOLT2).

##= Time-value Denial-of-Service Risks: The Lightning One-Link Case

Let= 's see a concrete example of a time-value DoS triggered by a replacemen= t cycling.

The public disclosure of replacement cycling attack has b= een mostly centered on loss of funds risks affecting HTLC forwarding over L= ightning routing nodes. Independently, a replacement cycling attack can be = leveraged to provoke denial-of-service among a Lightning routing node and a= n end-node on a spoke link.

The attack works in the following fashio= n (offered HTLC on outgoing link) as it was not fully fleshed out in the di= sclosure communications:
- Alice and Bob are lightning nodes, they share= a funded chan
- Alice forwads a HTLC to Bob for further routing to Caro= ll
- Bob forwards the HTLC to Caroll and gets the HTLC preimage
- Bob= witholds settltement on Alice - Bob link until chain tip height reaches `c= ltv_expiry`
- Alice broadcast a HTLC-timeout to recover her funds
- B= ob engages in a replacement cycling by repeatedly rebroadcasting the HTLC-p= reimage and double-spending it

Alice is stuck with her HTLC funds th= at cannot be recovered on-chain. While Bob is paying a replacement penalty = every time it happens, there might be a scaling effect targeting many HTLC-= timeout with a single HTLC preimage (`option_anchors_zero_fee_htlc_tx`).
It should be noted that in matters of offered HTLC expiration on an ou= tgoing link, each lightning implementation has its own logic, as this is no= t something standardized (e.g ldk's `LATENCY_GRACE_PERIOD_BLOCKS`).
=
It is left as an open question how an an attacker can economically bene= fit from this denial-of-service.

## Loss of Funds Risks

As it= has been exposed during the public disclosure of the replacement cycling a= ttack, it can be leveraged to steal users funds from lightning payment chan= nels, as one protocol affected.

As an extension, it can affect any o= ther contracting protocol (characterisics a. + c. + d.). On those protocols= (e.g lightning or swaps), the protocol semantic is driven by absolute / re= lative timelocks initialized in a set of pre-signed transactions and finali= zed by the chain tip height or epoch time.

The underlying funds secu= rity is conditional on the time-sensitive broadcast and inclusion of the pr= e-signed transactions to execute an off-chain state. Failing to fulfill thi= s time-sensitive requirement can lead to loss of funds.

Generally, l= oss of funds risks affecting a multi-party application / contracting protoc= ols still depends on the usage of "short duration" of relative / = absolute timelocks.

## Second-Layers and Use-Cases

We're = further surveying deployed second-layers and use-cases either affected by t= ime-value DoS or loss of funds risks.

(Transaction-relay technique l= ike "transaction accelerators" have been excluded from the list o= f potentially affected second-layers initially published, actually it's= neither a multi-party application or contracting protocol).

On-chai= n DLC (contracting protocol): a funding transaction locks funds in a 2-of-2= . A subsequent pair of contract execution transaction encodes DLC result fr= om oracle contribution. There can be a refund transaction under timelocks (= model: cf. "dlcspecs" - github 2020).

On-chain DLC risks: = loss of funds _only if oracle gets wrong_. Time-value DoS risk on the fundi= ng transaction or with refund if timelock miselection.

Coinjoin (mul= ti-party application): a single joint transaction with contributions from N= inputs (model: cf. "Coinjoin: Bitcoin privacy for the real world"= ; - bitcointalkg.org 2013)

Coinjoin risks= : no loss of funds risks. Time-value DoS risk, if a fee-bumping of the join= t transaction can be done by any user.

Payjoin (multi-party applicat= ion): a single joint transaction with contributions from N inputs owned by = a single user paying another user (model: cf. "improving privacy using= pay-to-endpoint" - blockstream blog 2018).

Payjoin risks: no l= oss of funds risks. Time-value DoS risk, if a fee-bumping of the joint tran= saction can be done by any user.

Wallet with time-sensitive paths (c= ontracting protocols): a user locks up funds with a set of pre-signed trans= actions. Each pre-signed transaction can have unique spending conditions an= d/or send to another user (model: cf. "bip65 op_checklocktimeverify&qu= ot;
- bips 2014).

Wallet with time-sensitive paths risks: loss of= funds risk _only if spend path to third-party with divergent interest and = timelock miselection_. Time-value DoS risk _only if spend to third-party wi= th divergent interest and timelock miselection_.

Peerswap and submar= ine swaps (contracting protocol): a funding transaction locks funds in a 2-= of-2. A swap can be spend by 3 subsequent transactions (invoice, coop, csv)= to settle positively or negatively the state of the swap (model: cf. "= ;peerswap" - element github 2022).

Peerswap and submarine swaps= risks: loss of funds risk if timelock miselection. Time value DoS risk.
Batch payouts (multi-party application): a single joint transactions w= ith contributions from N inputs owned by a singler user paying a N number o= f users (model: cf. "scaling bitcoin using payment batching" - bi= tcoin optech 2021).

Batch payouts risks: no loss of funds risks. Tim= e-value DoS risk, if a fee-bumping of the joint transaction can be done by = any user.

For all those second-layers and use-cases risks identifica= tion, I think a replacement cycling attack is plausible, independently of t= he level of network mempools congestion.

On this area, thanks to the= insights and observation from folks who have participated in the initial s= ecurity-handling around February 2023 - All names have already been listed = in the initial email.

## Conclusion

A transaction-relay jammi= ng can be identified as a protocol counterparty or application participant = interfering with the relay of transaction. If the transactions are time-sen= sitive per the protocol semantic, this interference can constitute a loss o= f funds risk. If the transactions are only collaboratively built, this inte= rference can constitute a timevalue DoS risk. Replacement cycling attack co= nstitutes one variant of class of attacks, of which pinning is the other we= ll-known variant.

Additionally, in this context of class of attacks = arising from the interfacing of bitcoin applications and protocols with the= base-layer transaction-relay network and its mempools rules, it can be not= eworthy to under-light some observations concerning
security-issue handl= ing process.

Firstly, there is not only a difficulty of diagnosticin= g correctly what specific bitcoin software is potentially affected. Establi= shing a relevant diagnostic is not only saying what is affected, though als= o saying the type of risk exposures (e.g plain loss of funds, fee griefing,= bandwidth denial-of-service) grieving each specific software.

Secon= dly, once the diagnostic is done, there is the curative phase where mitigat= ion patches are developed and included in the codebase. Each codebase is un= ique (e.g have its own language) and it can have its own usual release sche= dule, indicating a the rate at which a mitigation patch can disseminate acr= oss its crowds of active users.

Furthermore, in a decentralized ecos= ystem where each full-node can run its own configuration of mempool policy = rules on a wide variety of hardware host, not all mitigation strategies are= equally viable. Considerations on the same level have already been weighte= d in the past e.g at the occasion of CVE-2021-31876 (replacement inheritanc= e defect on bitcoin core).

Don't trust, verify. All mistakes and= opinions are my own.

Cheers,
Antoine

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/f9ac65db-9756-4c85-b376-6b6a286a2b2cn%40googlegroups.com.=
------=_Part_78198_1250213256.1716594862611-- ------=_Part_78197_1136865387.1716594862611--