From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 24 May 2024 03:59:36 -0700 Received: from mail-yb1-f184.google.com ([209.85.219.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sASe6-0004ED-In for bitcoindev@gnusha.org; Fri, 24 May 2024 03:59:36 -0700 Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-dee5f035dd6sf277609276.0 for ; Fri, 24 May 2024 03:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1716548368; x=1717153168; 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=qC3lo5xQJJX6Yy+9g3QUyG+TVqnkF8fp8OcJ+ZWb4Xo=; b=mmfgHda9K1+HcUaTnOhG9CvxttqiZL8hOCIREvMvf+Nw8g3bkAq0ZFLwU7qRqtu65r 1sR6j+mg1YIvDgwVzxQ9KEY0I4zMC4kmjeI8d0ZtES/6k57Rj24PZAbvDK1xJjHhRP7D j0yHDgJt8+5ejqund+R9lC4dv92YvRKdlR6B0KgKFTs21wYqmeNQOfA07gZr1toK4IjP aQcusmhw7/pckd0XYbSOC4M7H0kB5SFvh3/GOzwU5vjJnVAe2DEvVj7O/hP55jrLYDPk haLbrPb97zwr9B3E4IsAIYghuGSyWBR1U3fstpvx7S+wkRpPGcP0P5ave7p0/hcEA9xR Uieg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716548368; x=1717153168; 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=qC3lo5xQJJX6Yy+9g3QUyG+TVqnkF8fp8OcJ+ZWb4Xo=; b=PH9g1qs+iQAPeqLUtLQYQE2GdbedQJiVnehxaaQgSDEOpuBApWa3keSdUe476fly2v 6wypupb0Yft2tbODtllYlxrO3vglt7EEP8Izz8xyb9T5pWuqHlPiwblgjn2pyPc6b9O1 cXl2ir6952nFUSYuHSYuTGWgXiBc4ebCtrYtTU3yXqpqK1lgzUz2hR5rFTwCyZxdTInM 5nlMp8ybtqs1+XZacVFZNzGaCGtZjdxSPSli7fA1hUvPwTIKj4eLwFvN0LwJdigXTP+Q shn6zOe7GxeqQyOQUg+rf4LOazkwV60BqOZLbjof7bq4ai3h1iIa9vsRtKrEdlWpZuWe vXTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716548368; x=1717153168; 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=qC3lo5xQJJX6Yy+9g3QUyG+TVqnkF8fp8OcJ+ZWb4Xo=; b=i3F7TuMkakqDETO1FofwmWKinDlA9OVs45/kaHlnC3yfmqyZ/4LDIvEJsXrLgrCqI1 3kVRbIcqFOjfBYCCW00Qv2KoxB2C8BSDKee8e6aT02hN8Ug9BR5yPRBDMQnlUl7S9eN9 +fcVUZb1VnbBRY9CremRd8S5v9rlR5TExxARd/RpC0MCGqc4XxRPJ0ItwrMGU7sY9Ms2 uR+i1TQeOIgO9TrVoxfJZr1lUcAS8Chvs0f8rBkl7wpZ2/LtMXd9DkZQtE4SnfbDAfEg O3KwHXdHyRlkgbmLVE/boLDeJKB7lPv1ldajXbzFnwTyhFKWG2uPvsXFRL7G+mE0s5RM ESJQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCURT5cCQe7Be7tjUD9VY4DGzoJsk7KrnLBgHOggmtYjtraCWsYbY6+tHhXrNDVNidF7yRqM5KnFrAHNjwrsV5qbr60Qbik= X-Gm-Message-State: AOJu0YyEDBV/71QKJonNLjPBdsK3q9gIo5kTTm0otr01Qeb0czsAzfkZ Ik+MNUPvQsxAXPtELrK/KQhZX5VmIRew6zdl1btJ0ltWqU0uXPab X-Google-Smtp-Source: AGHT+IF5DQwcUmlyhVfJt09oT/ruevRxLNQAPFq4X5o/UZAntKwAL4MuCQz1RmHprkhtqckGEcAFMA== X-Received: by 2002:a25:690d:0:b0:dc2:5553:ca12 with SMTP id 3f1490d57ef6-df77218f621mr1766066276.14.1716548368247; Fri, 24 May 2024 03:59:28 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a5b:bcb:0:b0:df4:df8f:b50a with SMTP id 3f1490d57ef6-df76fd5cb98ls736779276.0.-pod-prod-00-us; Fri, 24 May 2024 03:59:26 -0700 (PDT) X-Received: by 2002:a25:b11a:0:b0:df4:d607:e029 with SMTP id 3f1490d57ef6-df55e6694b1mr996361276.4.1716548366725; Fri, 24 May 2024 03:59:26 -0700 (PDT) Received: by 2002:a05:690c:ec9:b0:627:7f59:2eee with SMTP id 00721157ae682-627e172aadems7b3; Thu, 23 May 2024 03:05:57 -0700 (PDT) X-Received: by 2002:a05:690c:638a:b0:618:5009:cb71 with SMTP id 00721157ae682-628344a3149mr5067037b3.5.1716458755951; Thu, 23 May 2024 03:05:55 -0700 (PDT) Date: Thu, 23 May 2024 03:05:55 -0700 (PDT) From: /dev /fd0 To: Bitcoin Development Mailing List Message-Id: <1c76a89a-3e8c-4b40-9f23-8f8e44ceaf1en@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: Analysis of Replacement Cycling Attacks Risks on L2s (beyond LN) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_66527_1651249250.1716458755686" X-Original-Sender: alicexbtong@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_66527_1651249250.1716458755686 Content-Type: multipart/alternative; boundary="----=_Part_66528_1145621345.1716458755686" ------=_Part_66528_1145621345.1716458755686 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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-servi= ce=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 = 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 how > > 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 to= =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 proce= ss. > > (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 an= =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 Alice > - 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 = 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 attack= . > > 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 coi= n=20 > spend or destination outputs to a common transaction. Each user can commi= t=20 > 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 migh= t=20 > be encumbered by relative (nSequence) or absolute timelocks (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 thing= s=20 > have been designated as a multi-party application, the second class of=20 > 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 ha= s=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 the= =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 t= he=20 > execution. > > This denial-of-service can constitute a prolonged denial-of-service of th= e=20 > targeted application / protocol, or a waste of the on-chain timevalue of= =20 > 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 vecto= r=20 > of denial-of-concern. E.g in lightning after 2016 blocks, participants to= a=20 > 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=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 leverag= ed=20 > to provoke denial-of-service among a Lightning routing node and an end-no= de=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 i= s=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 benefi= t=20 > 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 swaps= ),=20 > the protocol semantic is driven by absolute / relative timelocks=20 > initialized in a set of pre-signed transactions and finalized by the chai= n=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 contracting= =20 > protocol). > > On-chain DLC (contracting protocol): a funding transaction locks funds in= =20 > a 2-of-2. A subsequent pair of contract execution transaction encodes DLC= =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-value= =20 > DoS risk on the funding transaction or with refund if timelock miselectio= n. > > Coinjoin (multi-party application): a single joint transaction with=20 > contributions from N inputs (model: cf. "Coinjoin: Bitcoin privacy for th= e=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 up= =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: c= f.=20 > "bip65 op_checklocktimeverify" > - bips 2014). > > Wallet with time-sensitive paths risks: loss of funds risk _only if spend= =20 > path to third-party with divergent interest and timelock miselection_.=20 > Time-value DoS risk _only if spend to third-party with divergent interest= =20 > and timelock miselection_. > > Peerswap and submarine swaps (contracting protocol): a funding transactio= n=20 > locks funds in a 2-of-2. A swap can be spend by 3 subsequent transactions= =20 > (invoice, coop, csv) to settle positively or negatively the state of the= =20 > 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 with= =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 opte= ch=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 are= =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 to= =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 relevan= t=20 > diagnostic is not only saying what is affected, though also saying the ty= pe=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 patch= =20 > can disseminate across its crowds of active users. > > Furthermore, in a decentralized ecosystem where each full-node can run it= s=20 > own configuration of mempool policy rules on a wide variety of hardware= =20 > host, not all mitigation strategies are equally viable. Considerations on= =20 > the same level have already been weighted in the past e.g at the occasion= =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/1c76a89a-3e8c-4b40-9f23-8f8e44ceaf1en%40googlegroups.com. ------=_Part_66528_1145621345.1716458755686 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:
<= blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left:= 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi,

Following up = on detailing more the non-lightning bitcoin use-cases affected by replaceme= nt cycling attacks, mostly under the denial-of-service angle (cf. "All= your mempool are belong to us" - bitcoin-dev 2023).

Excerpt fr= om the original public disclosure:

>From my understanding the fol= lowing list of Bitcoin protocols and
> applications could be affected= by new denial-of-service vectors under some
> level of network mempo= ols congestion. Neither tests or advanced review of
> specifications = (when available) has been conducted for each of them:
> - on-chain DL= Cs
> - coinjoins
> - payjoins
> - wallets with time-sensi= tive paths
> - peerswap and submarine swaps
> - batch payouts> - transaction "accelerators"
>
> Inviting the= ir developers, maintainers and operators to investigate how
> replace= ment cycling attacks might disrupt their in-mempool chain of
> transa= ctions, or fee-bumping flows at the shortest delay.

Also, this post = intends to provide the lineaments of a common template to be useful in case= of future cross-layer security issues arising in the bitcoin ecosystem. Su= ch template to be leveraged by any skilled folk involved in the resolution = of a cross-layer security-issue handling process.

(To be understood:= without the necessary tangible involvement of the present author post, the= re is a sufficient number of other folks in this ecosystem with the skillse= t and _the guts_ to conduct such =C2=A0process in a reasonable fashion in t= he future).

## Replacement Cycling Attack (a quick reminder)

= The attacker goal of a replacement cycling attack is to delay the confirmat= ion of a HTLC-timeout on an outgoing link of a routing node, sufficiently t= o enable an off-chain double-spend of a HTLC-preimage on an incoming link.<= br>
The attack scenario works in the following ways:
- Assume the Mal= lory - Alice - Mallet channel topology
- Mallory forwards a HTLC of 1 BT= C to Mallet by the intermediary of Alice
- This HTLC expires at chain ti= p + 100 outgoing link, chain tip + 140 incoming link (Alice Pov)
- Malle= t receives the HTLC on the Alice-Mallet links and does not settle it
- A= t chain tip + 100, Alice broadcasts commitment tx + HTLC-timeout tx
- Ma= llet replaces Alice's HTLC-timeout tx with a HTLC-preimage tx
- Mall= et 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 =C2=A0incoming link- In parallel, Mallet broadcasts a HTLC-preimage to double-spend the forwa= rding link

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

## Conditions of Attacks Exploitation

From my unde= rstanding, protocols and applications with a subset of the following charac= teristics can be affected by a replacement cycling attack.

a) Shared= -UTXO spendings. Two or more distinct users each owns at least a spending p= ath in a redeem script encumbering a single coin.

b) Join-UTXO spend= ings. Two or more distinct users each contributes a coin spend or destinati= on outputs to a common transaction. Each user can commit more than one coin= to the common transaction.

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

d) Absolute = / Relative Timelocks. The set of pre-signed transactiosn might be encumbere= d by relative (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 be= en designated as a multi-party application, the second class of things a co= ntracting protocol (e.g on the effects of mempool policy changes).

T= his distinction mostly matters in term of security models. All of them soun= ds to present some vector of transaction or package malleability.

##= Time-value Denial-of-Service Risks

Leveraging transaction-relay and= mempools mechanism to trigger a time-value denial-of-service in a target a= pplication or protocol phase has already been considered many times in the = past.

E.g reaching hypothetical replacement limits to DoS payment ch= annels participants (cf. "Anti DoS for tx replacement" - bitcoin-= dev 2013) or DoSing a multi-party transaction by opt-ing out from replaceme= nt with a double-spend (cf. "On Mempool Funny Games against Multi-Part= y Funded Transactions" - lightning-dev 2021).

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

Th= is denial-of-service can constitute a prolonged denial-of-service of the ta= rgeted application / protocol, or a waste of the on-chain timevalue of the = coins consumed by the application / protocol. Here again, risks exposures i= s function of the application / protocol concrete combination of characteri= stics.

Some protocols have lightweight anti-DoS measures to alleviat= e this vector of denial-of-concern. E.g in lightning after 2016 blocks, par= ticipants to a payment channel can forget the funding transaction (BOLT2).<= br>
## 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 r= eplacement cycling.

The public disclosure of replacement cycling att= ack has been mostly centered on loss of funds risks affecting HTLC forwardi= ng over Lightning routing nodes. Independently, a replacement cycling attac= k can be leveraged to provoke denial-of-service among a Lightning routing n= ode and an end-node on a spoke link.

The attack works in the followi= ng fashion (offered HTLC on outgoing link) as it was not fully fleshed out = in the disclosure communications:
- Alice and Bob are lightning nodes, t= hey share a funded chan
- Alice forwads a HTLC to Bob for further routin= g to Caroll
- Bob forwards the HTLC to Caroll and gets the HTLC preimage=
- Bob witholds settltement on Alice - Bob link until chain tip height r= eaches `cltv_expiry`
- Alice broadcast a HTLC-timeout to recover her fun= ds
- Bob engages in a replacement cycling by repeatedly rebroadcasting t= he HTLC-preimage and double-spending it

Alice is stuck with her HTLC= funds that cannot be recovered on-chain. While Bob is paying a replacement= penalty every time it happens, there might be a scaling effect targeting m= any 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 outgoing link, each lightning implementation has its own logic, as t= his is not something standardized (e.g ldk's `LATENCY_GRACE_PERIOD_BLOC= KS`).

It is left as an open question how an an attacker can economic= ally benefit from this denial-of-service.

## Loss of Funds Risks
=
As it has been exposed during the public disclosure of the replacement = cycling attack, it can be leveraged to steal users funds from lightning pay= ment channels, as one protocol affected.

As an extension, it can aff= ect any other contracting protocol (characterisics a. + c. + d.). On those = protocols (e.g lightning or swaps), the protocol semantic is driven by abso= lute / relative timelocks initialized in a set of pre-signed transactions a= nd finalized by the chain tip height or epoch time.

The underlying f= unds security is conditional on the time-sensitive broadcast and inclusion = of the pre-signed transactions to execute an off-chain state. Failing to fu= lfill this time-sensitive requirement can lead to loss of funds.

Gen= erally, loss of funds risks affecting a multi-party application / contracti= ng protocols still depends on the usage of "short duration" of re= lative / absolute timelocks.

## Second-Layers and Use-Cases

W= e're further surveying deployed second-layers and use-cases either affe= cted by time-value DoS or loss of funds risks.

(Transaction-relay te= chnique like "transaction accelerators" have been excluded from t= he list of potentially affected second-layers initially published, actually= it's neither a multi-party application or contracting protocol).
On-chain DLC (contracting protocol): a funding transaction locks funds in= a 2-of-2. A subsequent pair of contract execution transaction encodes DLC = result from oracle contribution. There can be a refund transaction under ti= melocks (model: cf. "dlcspecs" - github 2020).

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

Coin= join (multi-party application): a single joint transaction with contributio= ns from N inputs (model: cf. "Coinjoin: Bitcoin privacy for the real w= orld" - bitcointalkg.org 2013)

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

Payjoin (multi-par= ty application): a single joint transaction with contributions from N input= s owned by a single user paying another user (model: cf. "improving pr= ivacy using pay-to-endpoint" - blockstream blog 2018).

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

Wallet with time-sensiti= ve paths (contracting protocols): a user locks up funds with a set of pre-s= igned transactions. Each pre-signed transaction can have unique spending co= nditions and/or send to another user (model: cf. "bip65 op_checklockti= meverify"
- bips 2014).

Wallet with time-sensitive paths ris= ks: loss of funds risk _only if spend path to third-party with divergent in= terest and timelock miselection_. Time-value DoS risk _only if spend to thi= rd-party with divergent interest and timelock miselection_.

Peerswap= and submarine swaps (contracting protocol): a funding transaction locks fu= nds 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 subm= arine swaps risks: loss of funds risk if timelock miselection. Time value D= oS risk.

Batch payouts (multi-party application): a single joint tra= nsactions with contributions from N inputs owned by a singler user paying a= N number of users (model: cf. "scaling bitcoin using payment batching= " - bitcoin optech 2021).

Batch payouts risks: no loss of funds= risks. Time-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= identification, I think a replacement cycling attack is plausible, indepen= dently of the level of network mempools congestion.

On this area, th= anks to the insights and observation from folks who have participated in th= e initial security-handling around February 2023 - All names have already b= een listed in the initial email.

## Conclusion

A transaction-= relay jamming can be identified as a protocol counterparty or application p= articipant interfering with the relay of transaction. If the transactions a= re time-sensitive per the protocol semantic, this interference can constitu= te a loss of funds risk. If the transactions are only collaboratively built= , this interference can constitute a timevalue DoS risk. Replacement cyclin= g attack constitutes one variant of class of attacks, of which pinning is t= he other well-known variant.

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

Firstly, there is not only a difficulty of d= iagnosticing correctly what specific bitcoin software is potentially affect= ed. Establishing a relevant diagnostic is not only saying what is affected,= though also saying the type of risk exposures (e.g plain loss of funds, fe= e griefing, bandwidth denial-of-service) grieving each specific software.
Secondly, once the diagnostic is done, there is the curative phase wh= ere mitigation patches are developed and included in the codebase. Each cod= ebase is unique (e.g have its own language) and it can have its own usual r= elease schedule, indicating a the rate at which a mitigation patch can diss= eminate across its crowds of active users.

Furthermore, in a decentr= alized ecosystem where each full-node can run its own configuration of memp= ool policy rules on a wide variety of hardware host, not all mitigation str= ategies are equally viable. Considerations on the same level have already b= een weighted in the past e.g at the occasion of CVE-2021-31876 (replacement= inheritance defect on bitcoin core).

Don't trust, verify. All m= istakes 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/1c76a89a-3e8c-4b40-9f23-8f8e44ceaf1en%40googlegroups.com.=
------=_Part_66528_1145621345.1716458755686-- ------=_Part_66527_1651249250.1716458755686--