path: root/63/28f00ee98dacca93e5d49f235549791f753b35

Delivery-date: Wed, 22 May 2024 21:09:33 -0700
Received: from mail-yb1-f188.google.com ([209.85.219.188])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRB5ECXOZAMGQEVT6ISUY@googlegroups.com>)
	id 1s9zlk-00061y-2U
	for bitcoindev@gnusha.org; Wed, 22 May 2024 21:09:33 -0700
Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-df4f3d8a461sf677155276.1
        for <bitcoindev@gnusha.org>; Wed, 22 May 2024 21:09:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1716437365; x=1717042165; 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:message-id:to:from:date:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=/fQ9MLg/wO0//mM/TOoUzjlM/KGNMcUopLvDtf97bI0=;
        b=DFSM56SNO/Hq90p8jJxrpjI7bP/0pVtGPnv3gHCRPgENLOLmpDjBZpiglQ6eJXd/VN
         aEz8T8P5FqS50XsbsW4cFH7xiOEtsYmEg4vB/zLjLVwmGbFO5Vk8fdEOpUPSkQk+2DgN
         48Gk2Ia9OX69xse7Ute46h//8e9vs1R46H2kQAZpyMgHdMCoZF5lfV4wPueGPoqDldE0
         EuQJK9IBwPG0l/vjOxRZ9bIRKsL1AJ2Jlqbdb0nw2o3gz9zXrELUAv2KlL9CRttAT7aB
         3SPOYbvEnNxBVA7gD8xeGE/cfkai0gVlLy0mjgkS6YVsKBgH6tOJ5r5HArhvRUYPapq2
         GufA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1716437365; x=1717042165; 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:message-id:to:from:date:from:to:cc:subject:date:message-id
         :reply-to;
        bh=/fQ9MLg/wO0//mM/TOoUzjlM/KGNMcUopLvDtf97bI0=;
        b=bE2QZhtWuxfpPL4AzlcKlMP7gP/xbDTwsWUp7bdsoHDCv7jWpC1+/QYsa++8opm9IR
         DUIt0S1uio+Ql059vueiUfD9zIUY/4x1TSAtOBORlREhetUR4gDwk81GBPtqm1dieu8x
         RZoQzKhG5H5eMsVQw3tbf2VoI1BpyI/G0y1O8C77Aj2pD1MjnWkufJ7AM5jCaaB3nPwZ
         qX8ilpNhRp7E0I0XdYKWIpLnsSFQL5VDzGI2FmcMME1AytENhDGSEC8L1eM3E8T83Bsl
         NHmiDZOSo0Q4tt6SI0GnLI7ghAhjIIJmL+CJ6AKDQqN+2xP+4yEW2L6CAbg1YH3A0dGS
         Yfcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1716437365; x=1717042165;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=/fQ9MLg/wO0//mM/TOoUzjlM/KGNMcUopLvDtf97bI0=;
        b=QQGtMmsytZffUxaXDrY0rfvEuFwkCVK7lHrQ3QPZ8eghEl6jk8FAyftA2Qld0+hgMz
         7kbc0PmiKihqFw5BgWTMyFLx62Hjum2F3c+XZDEzLS+atGnLPr5tHP8BXfsJPRDs9Ul5
         Q63+hQnPzfs0PA1s7Kd7SndLN9x/psUVQve9mhwT19JFZItcedYyyUZSgzj02HJzN1Ux
         K+pPpvO2yVFKWGb7DPuS2e/kL7eADLOZAVX/HhLSOgJACYBPMoJrH+3XbzO/xHRZ6ggx
         iriWVD1JFdMySsoR2qph9Qe6EzFLY3WjzizcphA5FQX5DAulTV6AUv6CqoX6DQPRxamO
         e61A==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVFFQ+hSadGdbyHFyWZDy7yYZphrxRuezz+5X1vDYXx8zyu8WoM8tlb51KpyOPVvTknoPC6ISVecXZr9QoFfc1OyvEardA=
X-Gm-Message-State: AOJu0YwtUhm5JQ2B51G/u+Xv87tVO1N3KgiZuR8XDPA1I41SPHx04Abi
	YXPbzbq7LjjImCZgASl5p21ii1SzbP5b6BckOP8IFl2o0+9C1rT1
X-Google-Smtp-Source: AGHT+IFDSEbHuzX5LPYOoFxfwOBLf1Sd/2kEpPbVGKDdOsQ9W3KZ/4L7/CUN7W0QBNxl7psIoe9kKQ==
X-Received: by 2002:a25:2d08:0:b0:df4:dce7:234b with SMTP id 3f1490d57ef6-df54222b31emr836748276.10.1716437365439;
        Wed, 22 May 2024 21:09:25 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:b10e:0:b0:dcd:202d:6be8 with SMTP id 3f1490d57ef6-df4e58c7dd9ls1125473276.2.-pod-prod-08-us;
 Wed, 22 May 2024 21:09:23 -0700 (PDT)
X-Received: by 2002:a25:bc47:0:b0:dcb:e4a2:1ab1 with SMTP id 3f1490d57ef6-df7610da23amr117631276.11.1716437363664;
        Wed, 22 May 2024 21:09:23 -0700 (PDT)
Received: by 2002:a05:690c:d86:b0:627:88fc:61e2 with SMTP id 00721157ae682-62788fc643cms7b3;
        Thu, 16 May 2024 20:30:07 -0700 (PDT)
X-Received: by 2002:a05:690c:6905:b0:61b:e6d8:1c01 with SMTP id 00721157ae682-622b003849amr55812717b3.10.1715916604530;
        Thu, 16 May 2024 20:30:04 -0700 (PDT)
Date: Thu, 16 May 2024 20:30:04 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <ca8d99a0-c445-4af3-854d-4ce524434b4bn@googlegroups.com>
Subject: [bitcoindev] Analysis of Replacement Cycling Attacks Risks on L2s
 (beyond LN)
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_11160_799059929.1715916604131"
X-Original-Sender: antoine.riard@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_11160_799059929.1715916604131
Content-Type: multipart/alternative; 
	boundary="----=_Part_11161_31407919.1715916604131"

------=_Part_11161_31407919.1715916604131
Content-Type: text/plain; charset="UTF-8"

Hi,

Following up on detailing more the non-lightning bitcoin use-cases affected 
by replacement cycling attacks, mostly under the denial-of-service 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 some
> level of network mempools congestion. Neither tests or advanced review of
> specifications (when available) has been conducted for each of them:
> - on-chain DLCs
> - coinjoins
> - payjoins
> - wallets with time-sensitive paths
> - peerswap and submarine swaps
> - batch payouts
> - transaction "accelerators"
> 
> Inviting their developers, maintainers and operators to investigate how
> replacement cycling attacks might disrupt their in-mempool chain of
> transactions, or fee-bumping flows at the shortest delay.

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. Such 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, there is a sufficient number of other folks in this 
ecosystem with the skillset and _the guts_ to conduct such  process in a 
reasonable fashion in the future).

## Replacement Cycling Attack (a quick reminder)

The attacker 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.

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 
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 
 incoming link
- In parallel, Mallet broadcasts a HTLC-preimage to double-spend the 
forwarding 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 understanding, protocols and applications with a subset of the 
following characteristics can be affected by a replacement cycling attack.

a) Shared-UTXO spendings. 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 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 encumbered 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 been designated as a multi-party application, the second class of 
things a contracting protocol (e.g on the effects of mempool policy 
changes).

This distinction mostly matters in term of security models. All of them 
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 time-value 
denial-of-service in a target application or protocol phase has already 
been considered many times in the past.

E.g reaching hypothetical replacement limits to DoS payment channels 
participants (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 rules (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 application / protocol, or a waste of the on-chain timevalue of 
the coins consumed by the application / protocol. Here again, risks 
exposures is function of the application / protocol concrete combination of 
characteristics.

Some protocols have lightweight anti-DoS measures to alleviate this vector 
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 replacement 
cycling.

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

The attack works in the following fashion (offered HTLC on outgoing link) 
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 
reaches `cltv_expiry`
- Alice broadcast a HTLC-timeout to recover her funds
- Bob engages in a replacement cycling by repeatedly rebroadcasting the 
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 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 
outgoing link, each lightning implementation has its own logic, as this is 
not something standardized (e.g ldk's `LATENCY_GRACE_PERIOD_BLOCKS`).

It is left as an open question how an an attacker can economically 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 
payment channels, as one protocol affected.

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

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

Generally, loss of funds risks affecting a multi-party application / 
contracting protocols 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 time-value DoS or loss of funds risks.

(Transaction-relay technique like "transaction accelerators" have been 
excluded from the 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 
timelocks (model: cf. "dlcspecs" - github 2020).

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

Coinjoin (multi-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 joint transaction can be done by any user.

Payjoin (multi-party application): 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 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-sensitive paths (contracting protocols): a user locks up 
funds with a set of pre-signed transactions. Each pre-signed transaction 
can have unique spending conditions and/or send to another user (model: cf. 
"bip65 op_checklocktimeverify"
- 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 with divergent interest 
and timelock miselection_.

Peerswap and submarine 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 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, independently of the level of 
network mempools congestion.

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

## Conclusion

A transaction-relay jamming can be identified as a protocol counterparty or 
application participant interfering with the relay of transaction. If the 
transactions are time-sensitive per the protocol semantic, this 
interference can constitute a loss of funds risk. If the transactions are 
only collaboratively built, this interference can constitute a timevalue 
DoS risk. Replacement cycling attack constitutes one variant of class of 
attacks, of which pinning is the other well-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 noteworthy to 
under-light some observations concerning
security-issue handling process.

Firstly, there is not only a difficulty of diagnosticing correctly what 
specific bitcoin software is potentially affected. 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, fee griefing, bandwidth 
denial-of-service) grieving each specific software.

Secondly, once the diagnostic is done, there is the curative phase where 
mitigation patches are developed and included in the codebase. Each 
codebase is unique (e.g have its own language) and it can have its own 
usual release schedule, indicating a the rate at which a mitigation patch 
can disseminate across its crowds of active users.

Furthermore, in a decentralized ecosystem 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 weighted in the past e.g at the occasion 
of CVE-2021-31876 (replacement inheritance 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 "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ca8d99a0-c445-4af3-854d-4ce524434b4bn%40googlegroups.com.

------=_Part_11161_31407919.1715916604131
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,<br /><br />Following up on detailing more the non-lightning bitcoin use=
-cases affected by replacement cycling attacks, mostly under the denial-of-=
service angle (cf. "All your mempool are belong to us" - bitcoin-dev 2023).=
<br /><br />Excerpt from the original public disclosure:<br /><br />&gt;Fro=
m my understanding the following list of Bitcoin protocols and<br />&gt; ap=
plications could be affected by new denial-of-service vectors under some<br=
 />&gt; level of network mempools congestion. Neither tests or advanced rev=
iew of<br />&gt; specifications (when available) has been conducted for eac=
h of them:<br />&gt; - on-chain DLCs<br />&gt; - coinjoins<br />&gt; - payj=
oins<br />&gt; - wallets with time-sensitive paths<br />&gt; - peerswap and=
 submarine swaps<br />&gt; - batch payouts<br />&gt; - transaction "acceler=
ators"<br />&gt; <br />&gt; Inviting their developers, maintainers and oper=
ators to investigate how<br />&gt; replacement cycling attacks might disrup=
t their in-mempool chain of<br />&gt; transactions, or fee-bumping flows at=
 the shortest delay.<br /><br />Also, this post intends to provide the line=
aments of a common template to be useful in case of future cross-layer secu=
rity issues arising in the bitcoin ecosystem. Such template to be leveraged=
 by any skilled folk involved in the resolution of a cross-layer security-i=
ssue handling process.<br /><br />(To be understood: without the necessary =
tangible involvement of the present author post, there is a sufficient numb=
er of other folks in this ecosystem with the skillset and _the guts_ to con=
duct such =C2=A0process in a reasonable fashion in the future).<br /><br />=
## Replacement Cycling Attack (a quick reminder)<br /><br />The attacker go=
al of a replacement cycling attack is to delay the confirmation of a HTLC-t=
imeout on an outgoing link of a routing node, sufficiently to 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 Mallory - Al=
ice - Mallet channel topology<br />- Mallory forwards a HTLC of 1 BTC to Ma=
llet by the intermediary of Alice<br />- This HTLC expires at chain tip + 1=
00 outgoing link, chain tip + 140 incoming link (Alice Pov)<br />- Mallet r=
eceives the HTLC on the Alice-Mallet links and does not settle it<br />- At=
 chain tip + 100, Alice broadcasts commitment tx + HTLC-timeout tx<br />- M=
allet replaces Alice's HTLC-timeout tx with a HTLC-preimage tx<br />- Malle=
t 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 =
forwarding link<br /><br />This is a rough summary of one of the simplest s=
cenario, for further details refers back to the original public disclosure,=
 already cf. above.<br /><br />## Conditions of Attacks Exploitation<br /><=
br />From my understanding, protocols and applications with a subset of the=
 following characteristics 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 path in a redeem script encumbering a single coin.<br /=
><br />b) Join-UTXO spendings. Two or more distinct users each contributes =
a coin spend or destination outputs to a common transaction. Each user can =
commit more than one coin to the common transaction.<br /><br />c) Pre-sign=
ed 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 inter=
activity.<br /><br />d) Absolute / Relative Timelocks. The set of pre-signe=
d transactiosn might be encumbered by relative (nSequence) or absolute time=
locks (nLockTime).<br /><br />If you combine b) + c) you have things like c=
oinjoins. If you combine a) + c) + d) you have things like lightning. Usual=
ly, the first class of things have been designated as a multi-party applica=
tion, the second class of things a contracting protocol (e.g on the effects=
 of mempool policy changes).<br /><br />This distinction mostly matters in =
term of security models. All of them sounds to present some vector of trans=
action or package malleability.<br /><br />## Time-value Denial-of-Service =
Risks<br /><br />Leveraging transaction-relay and mempools mechanism to tri=
gger a time-value denial-of-service in a target application or protocol pha=
se has already been considered many times in the past.<br /><br />E.g reach=
ing hypothetical replacement limits to DoS payment channels participants (c=
f. "Anti DoS for tx replacement" - bitcoin-dev 2013) or DoSing a multi-part=
y transaction by opt-ing out from replacement with a double-spend (cf. "On =
Mempool Funny Games against Multi-Party Funded Transactions" - lightning-de=
v 2021).<br /><br />Under current mempool rules (i.e ones deployed on 99% o=
f network over the last years), a replacement cycling opens a new generic w=
ay to trigger a denial-of-service in a Bitcoin application or protocol flow=
 to paralyze the execution.<br /><br />This denial-of-service can constitut=
e a prolonged denial-of-service of the targeted application / protocol, or =
a waste of the on-chain timevalue of the coins consumed by the application =
/ protocol. Here again, risks exposures is function of the application / pr=
otocol concrete combination of characteristics.<br /><br />Some protocols h=
ave lightweight anti-DoS measures to alleviate this vector of denial-of-con=
cern. E.g in lightning after 2016 blocks, participants to a payment channel=
 can forget the funding transaction (BOLT2).<br /><br />## Time-value Denia=
l-of-Service Risks: The Lightning One-Link Case<br /><br />Let's see a conc=
rete example of a time-value DoS triggered by a replacement cycling.<br /><=
br />The public disclosure of replacement cycling attack has been mostly ce=
ntered on loss of funds risks affecting HTLC forwarding over Lightning rout=
ing nodes. Independently, a replacement cycling attack can be leveraged to =
provoke denial-of-service among a Lightning routing node and an end-node on=
 a spoke link.<br /><br />The attack works in the following fashion (offere=
d HTLC on outgoing link) as it was not fully fleshed out in the disclosure =
communications:<br />- Alice and Bob are lightning nodes, they share a fund=
ed chan<br />- Alice forwads a HTLC to Bob for further routing 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 reaches `cl=
tv_expiry`<br />- Alice broadcast a HTLC-timeout to recover her funds<br />=
- Bob engages in a replacement cycling by repeatedly rebroadcasting the HTL=
C-preimage and double-spending it<br /><br />Alice is stuck with her HTLC f=
unds that cannot be recovered on-chain. While Bob is paying a replacement p=
enalty every time it happens, there might be a scaling effect targeting man=
y HTLC-timeout with a single HTLC preimage (`option_anchors_zero_fee_htlc_t=
x`).<br /><br />It should be noted that in matters of offered HTLC expirati=
on on an outgoing link, each lightning implementation has its own logic, as=
 this is not something standardized (e.g ldk's `LATENCY_GRACE_PERIOD_BLOCKS=
`).<br /><br />It is left as an open question how an an attacker can econom=
ically benefit from this denial-of-service.<br /><br />## Loss of Funds Ris=
ks<br /><br />As it has been exposed during the public disclosure of the re=
placement cycling attack, it can be leveraged to steal users funds from lig=
htning payment channels, as one protocol affected.<br /><br />As an extensi=
on, it can affect any other contracting protocol (characterisics a. + c. + =
d.). On those protocols (e.g lightning or swaps), the protocol semantic is =
driven by absolute / relative timelocks initialized in a set of pre-signed =
transactions and finalized by the chain tip height or epoch time.<br /><br =
/>The underlying funds security is conditional on the time-sensitive broadc=
ast and inclusion of the pre-signed transactions to execute an off-chain st=
ate. Failing to fulfill this time-sensitive requirement can lead to loss of=
 funds.<br /><br />Generally, loss of funds risks affecting a multi-party a=
pplication / contracting protocols still depends on the usage of "short dur=
ation" of relative / absolute timelocks.<br /><br />## Second-Layers and Us=
e-Cases<br /><br />We're further surveying deployed second-layers and use-c=
ases either affected by time-value DoS or loss of funds risks.<br /><br />(=
Transaction-relay technique like "transaction accelerators" have been exclu=
ded from the list of potentially affected second-layers initially published=
, actually it's neither a multi-party application or contracting protocol).=
<br /><br />On-chain DLC (contracting protocol): a funding transaction lock=
s funds in a 2-of-2. A subsequent pair of contract execution transaction en=
codes DLC result from oracle contribution. There can be a refund transactio=
n under timelocks (model: cf. "dlcspecs" - github 2020).<br /><br />On-chai=
n DLC risks: loss of funds _only if oracle gets wrong_. Time-value DoS risk=
 on the funding transaction or with refund if timelock miselection.<br /><b=
r />Coinjoin (multi-party application): a single joint transaction with con=
tributions from N inputs (model: cf. "Coinjoin: Bitcoin privacy for the rea=
l world" - bitcointalkg.org 2013)<br /><br />Coinjoin risks: no loss of fun=
ds risks. Time-value DoS risk, if a fee-bumping of the joint transaction ca=
n be done by any user.<br /><br />Payjoin (multi-party application): a sing=
le joint transaction with contributions from N inputs owned by a single use=
r paying another user (model: cf. "improving privacy using pay-to-endpoint"=
 - 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 don=
e by any user.<br /><br />Wallet with time-sensitive paths (contracting pro=
tocols): a user locks up funds with a set of pre-signed transactions. Each =
pre-signed transaction can have unique spending conditions and/or send to a=
nother user (model: cf. "bip65 op_checklocktimeverify"<br />- bips 2014).<b=
r /><br />Wallet with time-sensitive paths risks: loss of funds risk _only =
if spend path to third-party with divergent interest and timelock miselecti=
on_. Time-value DoS risk _only if spend to third-party with divergent inter=
est and timelock miselection_.<br /><br />Peerswap and submarine swaps (con=
tracting protocol): a funding transaction locks funds in a 2-of-2. A swap c=
an be spend by 3 subsequent transactions (invoice, coop, csv) to settle pos=
itively or negatively the state of the swap (model: cf. "peerswap" - elemen=
t github 2022).<br /><br />Peerswap and submarine swaps risks: loss of fund=
s risk if timelock miselection. Time value DoS risk.<br /><br />Batch payou=
ts (multi-party application): a single joint transactions with contribution=
s from N inputs owned by a singler user paying a N number of users (model: =
cf. "scaling bitcoin using payment batching" - 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 />F=
or all those second-layers and use-cases risks identification, I think a re=
placement cycling attack is plausible, independently of the level of networ=
k mempools congestion.<br /><br />On this area, thanks to the insights and =
observation from folks who have participated in the initial security-handli=
ng around February 2023 - All names have already been listed in the initial=
 email.<br /><br />## Conclusion<br /><br />A transaction-relay jamming can=
 be identified as a protocol counterparty or application participant interf=
ering with the relay of transaction. If the transactions are time-sensitive=
 per the protocol semantic, this interference can constitute a loss of fund=
s risk. If the transactions are only collaboratively built, this interferen=
ce can constitute a timevalue DoS risk. Replacement cycling attack constitu=
tes one variant of class of attacks, of which pinning is the other well-kno=
wn variant.<br /><br />Additionally, in this context of class of attacks ar=
ising from the interfacing of bitcoin applications and protocols with the b=
ase-layer transaction-relay network and its mempools rules, it can be notew=
orthy to under-light some observations concerning<br />security-issue handl=
ing process.<br /><br />Firstly, there is not only a difficulty of diagnost=
icing correctly what specific bitcoin software is potentially affected. Est=
ablishing a relevant diagnostic is not only saying what is affected, though=
 also saying the type of risk exposures (e.g plain loss of funds, fee grief=
ing, bandwidth denial-of-service) grieving each specific software.<br /><br=
 />Secondly, once the diagnostic is done, there is the curative phase where=
 mitigation patches are developed and included in the codebase. Each codeba=
se is unique (e.g have its own language) and it can have its own usual rele=
ase schedule, indicating a the rate at which a mitigation patch can dissemi=
nate across its crowds of active users.<br /><br />Furthermore, in a decent=
ralized ecosystem where each full-node can run its own configuration of mem=
pool policy rules on a wide variety of hardware host, not all mitigation st=
rategies are equally viable. Considerations on the same level have already =
been weighted in the past e.g at the occasion of CVE-2021-31876 (replacemen=
t inheritance defect on bitcoin core).<br /><br />Don't trust, verify. All =
mistakes and opinions are my own.<br /><br />Cheers,<br />Antoine<br />

<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/ca8d99a0-c445-4af3-854d-4ce524434b4bn%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/ca8d99a0-c445-4af3-854d-4ce524434b4bn%40googlegroups.com</a>.=
<br />

------=_Part_11161_31407919.1715916604131--

------=_Part_11160_799059929.1715916604131--