path: root/54/aaace717bd0a30816800d26ed5329ea37c1dbd

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 <bitcoindev+bncBCU2P6FJ3EBBBD7GYGZAMGQERBGUYRY@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <alicexbtong@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <1c76a89a-3e8c-4b40-9f23-8f8e44ceaf1en@googlegroups.com>
In-Reply-To: <ca8d99a0-c445-4af3-854d-4ce524434b4bn@googlegroups.com>
References: <ca8d99a0-c445-4af3-854d-4ce524434b4bn@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_66527_1651249250.1716458755686"
X-Original-Sender: alicexbtong@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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
<https://github.com/utxo-teleport/teleport-transactions/blob/master/docs/de=
v-book.md#how-coinswap-works>?=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,<div><br /></div><div>Does this also affect <a href=3D"https://g=
ithub.com/utxo-teleport/teleport-transactions/blob/master/docs/dev-book.md#=
how-coinswap-works">coinswap</a>? If yes, what are the risks involved?</div=
><div><br /></div><div>/dev/fd0</div><div>floppy disk guy<br /><br /></div>=
<div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Thursd=
ay, May 23, 2024 at 4:09:25=E2=80=AFAM UTC Antoine Riard wrote:<br/></div><=
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,<br><br>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. &quot;All=
 your mempool are belong to us&quot; - bitcoin-dev 2023).<br><br>Excerpt fr=
om the original public disclosure:<br><br>&gt;From my understanding the fol=
lowing list of Bitcoin protocols and<br>&gt; applications could be affected=
 by new denial-of-service vectors under some<br>&gt; level of network mempo=
ols congestion. Neither tests or advanced review of<br>&gt; specifications =
(when available) has been conducted for each of them:<br>&gt; - on-chain DL=
Cs<br>&gt; - coinjoins<br>&gt; - payjoins<br>&gt; - wallets with time-sensi=
tive paths<br>&gt; - peerswap and submarine swaps<br>&gt; - batch payouts<b=
r>&gt; - transaction &quot;accelerators&quot;<br>&gt; <br>&gt; Inviting the=
ir developers, maintainers and operators to investigate how<br>&gt; replace=
ment cycling attacks might disrupt their in-mempool chain of<br>&gt; transa=
ctions, or fee-bumping flows at the shortest delay.<br><br>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.<br><br>(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).<br><br>## Replacement Cycling Attack (a quick reminder)<br><br>=
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><br>The attack scenario works in the following ways:<br>- Assume the Mal=
lory - Alice - Mallet channel topology<br>- Mallory forwards a HTLC of 1 BT=
C to Mallet by the intermediary of Alice<br>- This HTLC expires at chain ti=
p + 100 outgoing link, chain tip + 140 incoming link (Alice Pov)<br>- Malle=
t receives the HTLC on the Alice-Mallet links and does not settle it<br>- A=
t chain tip + 100, Alice broadcasts commitment tx + HTLC-timeout tx<br>- Ma=
llet replaces Alice&#39;s HTLC-timeout tx with a HTLC-preimage tx<br>- Mall=
et then replaces HTLC-preimage with a conflicting double-spend<br>- Mallet =
repeats this trick until chain tip reaches tip + 140<br>- When chain tip + =
140, Mallory broadcasts HTLC-timeout to double-spend =C2=A0incoming link<br=
>- In parallel, Mallet broadcasts a HTLC-preimage to double-spend the forwa=
rding link<br><br>This is a rough summary of one of the simplest scenario, =
for further details refers back to the original public disclosure, already =
cf. above.<br><br>## Conditions of Attacks Exploitation<br><br>From my unde=
rstanding, protocols and applications with a subset of the following charac=
teristics can be affected by a replacement cycling attack.<br><br>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.<br><br>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.<br><br>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.<br><br>d) Absolute =
/ Relative Timelocks. The set of pre-signed transactiosn might be encumbere=
d by relative (nSequence) or absolute timelocks (nLockTime).<br><br>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).<br><br>T=
his distinction mostly matters in term of security models. All of them soun=
ds to present some vector of transaction or package malleability.<br><br>##=
 Time-value Denial-of-Service Risks<br><br>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.<br><br>E.g reaching hypothetical replacement limits to DoS payment ch=
annels participants (cf. &quot;Anti DoS for tx replacement&quot; - bitcoin-=
dev 2013) or DoSing a multi-party transaction by opt-ing out from replaceme=
nt with a double-spend (cf. &quot;On Mempool Funny Games against Multi-Part=
y Funded Transactions&quot; - lightning-dev 2021).<br><br>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.<br><br>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.<br><br>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><br>## Time-value Denial-of-Service Risks: The Lightning One-Link Case<b=
r><br>Let&#39;s see a concrete example of a time-value DoS triggered by a r=
eplacement cycling.<br><br>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.<br><br>The attack works in the followi=
ng fashion (offered HTLC on outgoing link) as it was not fully fleshed out =
in the disclosure communications:<br>- Alice and Bob are lightning nodes, t=
hey share a funded chan<br>- Alice forwads a HTLC to Bob for further routin=
g to Caroll<br>- Bob forwards the HTLC to Caroll and gets the HTLC preimage=
<br>- Bob witholds settltement on Alice - Bob link until chain tip height r=
eaches `cltv_expiry`<br>- Alice broadcast a HTLC-timeout to recover her fun=
ds<br>- Bob engages in a replacement cycling by repeatedly rebroadcasting t=
he HTLC-preimage and double-spending it<br><br>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`).<br><br>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&#39;s `LATENCY_GRACE_PERIOD_BLOC=
KS`).<br><br>It is left as an open question how an an attacker can economic=
ally benefit from this denial-of-service.<br><br>## Loss of Funds Risks<br>=
<br>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.<br><br>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.<br><br>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.<br><br>Gen=
erally, loss of funds risks affecting a multi-party application / contracti=
ng protocols still depends on the usage of &quot;short duration&quot; of re=
lative / absolute timelocks.<br><br>## Second-Layers and Use-Cases<br><br>W=
e&#39;re further surveying deployed second-layers and use-cases either affe=
cted by time-value DoS or loss of funds risks.<br><br>(Transaction-relay te=
chnique like &quot;transaction accelerators&quot; have been excluded from t=
he list of potentially affected second-layers initially published, actually=
 it&#39;s neither a multi-party application or contracting protocol).<br><b=
r>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. &quot;dlcspecs&quot; - github 2020).<br><br>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.<br><br>Coin=
join (multi-party application): a single joint transaction with contributio=
ns from N inputs (model: cf. &quot;Coinjoin: Bitcoin privacy for the real w=
orld&quot; - <a href=3D"http://bitcointalkg.org" target=3D"_blank" rel=3D"n=
ofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
=3Dhttp://bitcointalkg.org&amp;source=3Dgmail&amp;ust=3D1716544617694000&am=
p;usg=3DAOvVaw3M5yeySU5ZOZ1b7a7hUZnb">bitcointalkg.org</a> 2013)<br><br>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.<br><br>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. &quot;improving pr=
ivacy using pay-to-endpoint&quot; - blockstream blog 2018).<br><br>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.<br><br>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. &quot;bip65 op_checklockti=
meverify&quot;<br>- bips 2014).<br><br>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_.<br><br>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. &quot;peerswap&quot; - element github 2022).<br><br>Peerswap and subm=
arine swaps risks: loss of funds risk if timelock miselection. Time value D=
oS risk.<br><br>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. &quot;scaling bitcoin using payment batching=
&quot; - bitcoin optech 2021).<br><br>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.<br><br>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.<br><br>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.<br><br>## Conclusion<br><br>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.<br><br>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<br>security-=
issue handling process.<br><br>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.<b=
r><br>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.<br><br>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).<br><br>Don&#39;t trust, verify. All m=
istakes and opinions are my own.<br><br>Cheers,<br>Antoine<br></blockquote>=
</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/1c76a89a-3e8c-4b40-9f23-8f8e44ceaf1en%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/1c76a89a-3e8c-4b40-9f23-8f8e44ceaf1en%40googlegroups.com</a>.=
<br />

------=_Part_66528_1145621345.1716458755686--

------=_Part_66527_1651249250.1716458755686--