path: root/72/51d7d3e25d22933e3ab36f67b9c6cf070a77ca

Delivery-date: Sat, 25 May 2024 01:57:08 -0700
Received: from mail-yw1-f186.google.com ([209.85.128.186])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBWOPY2ZAMGQEOV7TAUQ@googlegroups.com>)
	id 1sAnD7-0001qV-OO
	for bitcoindev@gnusha.org; Sat, 25 May 2024 01:57:07 -0700
Received: by mail-yw1-f186.google.com with SMTP id 00721157ae682-627956be166sf18543997b3.0
        for <bitcoindev@gnusha.org>; Sat, 25 May 2024 01:57:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1716627419; x=1717232219; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=JJsN0jwuNGjLq5xPsye7bLaGHfNFOgjvh43BR35bMvY=;
        b=VzdhVUHBYPTUWvQRqc9vzFo+DRWeHrbKFndeldoXUQWQ8Eh52QA9VF66dDt5nyu/vs
         g9qOW3L5oQFJxqeeW72MSxPsN8qe7R4Qw/R0X6rrWDzUWvj8j9lgYQg12I9bSMFjrtO/
         WthCDgh+55HUa6DzXdZ1mbJ+vwOrp+ECLbIUDmOBqovMRl0ypflff1QHuglw6ftkWAa5
         k90UlKmW60FoM/ZMner8UlB3X0ISJq19Qt/bET6Nt9KvcOKpKB88e4yHDRL68Tn+1CPk
         rDYRx7+8p5rjtn3GauIX89ChBBNuGPDDGFxsh+cLHJGhIkpE149q7KSmQjMZs471knJm
         IWyg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1716627419; x=1717232219; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=JJsN0jwuNGjLq5xPsye7bLaGHfNFOgjvh43BR35bMvY=;
        b=i6JC7YfyRpAf7ydRDWq6mna+mqHHpNj0IuAUexmJ3pIcztB+SAH5imyo99sGdGbRMJ
         wnLoctDzWNzP9QJwz1uukyJwWcwKPoEmJ9RaqObhGHcmHjf1vMs/jGSIlnBiUI6e0Bnb
         qJFWxNDm61nqj3HDXAXJ9uK3jkoRIC6LWWOkkys5KeDKv+pODLxf0oVdHSKKvvvx2uPt
         GGC/WrbCAKjZk/71pqNOYWefDpz1ei37UWwCQDCFPoeO0YEm+ryP1xoKTZMr2NusMDCw
         pBKczinE1/jJ3u2rZ6Ju55Y3gfV2PiCEPcKXcXgo9AGpnQBnGkma8tt6lSca0u/7cC2d
         vt4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1716627419; x=1717232219;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=JJsN0jwuNGjLq5xPsye7bLaGHfNFOgjvh43BR35bMvY=;
        b=Mvb+0Eo7JfuoYgsjUDN+71DYaU8IEpEae3Lc2aGOeOUTMUIDa0ft1dHeNGf2042DIZ
         oEzKZq3sEDtMv0vNkrQaqXOzB3VowNwWGrFRRWdG716tG6X1NO5N7PdfmugtIS5TwWaS
         NhbbefPb5sMZfuK66cb6rfmMtvASO0ij1mNHwOOmeZntNuUdyOIhzRtLT6Tbj+6u38xU
         QM1LhY7UxUQs+qyyCIdkOFx8tU+8AhWOGa/AdWeJ5+HOk4+GVpe9msG0OV88+sIOWZO1
         Dritz1kSOZjdLuuaDZAUTxcP+EOI+dEw6hsieH3CGpcUY+v6MMilP3Y+fT1SrqbTuz7k
         bEOA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWALTDwyM6yBf6aHcjQvZni9/6h8IZbHzNFWO7YuglEW3lEx8+Z9aciO3pnMEJQXaukjTCBxXxRzso9FsW8OZofyUAcMbg=
X-Gm-Message-State: AOJu0Yyn2sOBlYsOp1oBZ0uDO3RKYnQGDb4hgdpIbelII1Uu1QCHOP4C
	hWG++tM1EiLSHDqp8154i5aGsiL03ZqHRW3fuwLST0g5QMky0dAC
X-Google-Smtp-Source: AGHT+IF90zDwVzG2nHHyPq/8jC0vLEszsUybjr+vBSswuz4ZjS05MFEkiK3IFbnlTz7VwbZFH8dTKA==
X-Received: by 2002:a25:ab0e:0:b0:df4:eb0b:8fc with SMTP id 3f1490d57ef6-df77221668fmr4291969276.43.1716627418989;
        Sat, 25 May 2024 01:56:58 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:84cb:0:b0:df7:71d2:bccb with SMTP id 3f1490d57ef6-df771d2be6els10169276.1.-pod-prod-00-us;
 Sat, 25 May 2024 01:56:57 -0700 (PDT)
X-Received: by 2002:a05:690c:600b:b0:611:5a9d:bb0e with SMTP id 00721157ae682-62a076284d6mr11125577b3.4.1716627417281;
        Sat, 25 May 2024 01:56:57 -0700 (PDT)
Received: by 2002:a05:690c:2b83:b0:620:26bb:319f with SMTP id 00721157ae682-62a0b4bcbe4ms7b3;
        Fri, 24 May 2024 16:54:24 -0700 (PDT)
X-Received: by 2002:a25:df8c:0:b0:dee:7f2c:ad90 with SMTP id 3f1490d57ef6-df7721f9d09mr1007425276.10.1716594862958;
        Fri, 24 May 2024 16:54:22 -0700 (PDT)
Date: Fri, 24 May 2024 16:54:22 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <f9ac65db-9756-4c85-b376-6b6a286a2b2cn@googlegroups.com>
In-Reply-To: <1c76a89a-3e8c-4b40-9f23-8f8e44ceaf1en@googlegroups.com>
References: <ca8d99a0-c445-4af3-854d-4ce524434b4bn@googlegroups.com>
 <1c76a89a-3e8c-4b40-9f23-8f8e44ceaf1en@googlegroups.com>
Subject: [bitcoindev] Re: Analysis of Replacement Cycling Attacks Risks on L2s
 (beyond LN)
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_78197_1136865387.1716594862611"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <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_78197_1136865387.1716594862611
Content-Type: multipart/alternative; 
	boundary="----=_Part_78198_1250213256.1716594862611"

------=_Part_78198_1250213256.1716594862611
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi /dev/fd0

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

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

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

Best,
Antoine

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

> Hi Antoine,
>
> Does this also affect coinswap=20
> <https://github.com/utxo-teleport/teleport-transactions/blob/master/docs/=
dev-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-serv=
ice=20
>> angle (cf. "All your mempool are belong to us" - bitcoin-dev 2023).
>>
>> Excerpt from the original public disclosure:
>>
>> >From my understanding the following list of Bitcoin protocols and
>> > applications could be affected by new denial-of-service vectors under=
=20
>> some
>> > level of network mempools congestion. Neither tests or advanced review=
=20
>> of
>> > specifications (when available) has been conducted for each of them:
>> > - on-chain DLCs
>> > - coinjoins
>> > - payjoins
>> > - wallets with time-sensitive paths
>> > - peerswap and submarine swaps
>> > - batch payouts
>> > - transaction "accelerators"
>> >=20
>> > Inviting their developers, maintainers and operators to investigate ho=
w
>> > replacement cycling attacks might disrupt their in-mempool chain of
>> > transactions, or fee-bumping flows at the shortest delay.
>>
>> Also, this post intends to provide the lineaments of a common template t=
o=20
>> be useful in case of future cross-layer security issues arising in the=
=20
>> bitcoin ecosystem. Such template to be leveraged by any skilled folk=20
>> involved in the resolution of a cross-layer security-issue handling proc=
ess.
>>
>> (To be understood: without the necessary tangible involvement of the=20
>> present author post, there is a sufficient number of other folks in this=
=20
>> ecosystem with the skillset and _the guts_ to conduct such  process in a=
=20
>> reasonable fashion in the future).
>>
>> ## Replacement Cycling Attack (a quick reminder)
>>
>> The attacker goal of a replacement cycling attack is to delay the=20
>> confirmation of a HTLC-timeout on an outgoing link of a routing node,=20
>> sufficiently to enable an off-chain double-spend of a HTLC-preimage on a=
n=20
>> incoming link.
>>
>> The attack scenario works in the following ways:
>> - Assume the Mallory - Alice - Mallet channel topology
>> - Mallory forwards a HTLC of 1 BTC to Mallet by the intermediary of Alic=
e
>> - This HTLC expires at chain tip + 100 outgoing link, chain tip + 140=20
>> incoming link (Alice Pov)
>> - Mallet receives the HTLC on the Alice-Mallet links and does not settle=
=20
>> it
>> - At chain tip + 100, Alice broadcasts commitment tx + HTLC-timeout tx
>> - Mallet replaces Alice's HTLC-timeout tx with a HTLC-preimage tx
>> - Mallet then replaces HTLC-preimage with a conflicting double-spend
>> - Mallet repeats this trick until chain tip reaches tip + 140
>> - When chain tip + 140, Mallory broadcasts HTLC-timeout to double-spend=
=20
>>  incoming link
>> - In parallel, Mallet broadcasts a HTLC-preimage to double-spend the=20
>> forwarding link
>>
>> This is a rough summary of one of the simplest scenario, for further=20
>> details refers back to the original public disclosure, already cf. above=
.
>>
>> ## Conditions of Attacks Exploitation
>>
>> From my understanding, protocols and applications with a subset of the=
=20
>> following characteristics can be affected by a replacement cycling attac=
k.
>>
>> a) Shared-UTXO spendings. Two or more distinct users each owns at least =
a=20
>> spending path in a redeem script encumbering a single coin.
>>
>> b) Join-UTXO spendings. Two or more distinct users each contributes a=20
>> coin spend or destination outputs to a common transaction. Each user can=
=20
>> commit more than one coin to the common transaction.
>>
>> c) Pre-signed transactions. The group of users is pre-signing a chain of=
=20
>> transactions to execute the protocol steps during an interactive phase.=
=20
>> After this phase, any user can broadcast the transaction at any time,=20
>> without further interactivity.
>>
>> d) Absolute / Relative Timelocks. The set of pre-signed transactiosn=20
>> might be encumbered by relative (nSequence) or absolute timelocks=20
>> (nLockTime).
>>
>> If you combine b) + c) you have things like coinjoins. If you combine a)=
=20
>> + c) + d) you have things like lightning. Usually, the first class of=20
>> things have been designated as a multi-party application, the second cla=
ss=20
>> of things a contracting protocol (e.g on the effects of mempool policy=
=20
>> changes).
>>
>> This distinction mostly matters in term of security models. All of them=
=20
>> sounds to present some vector of transaction or package malleability.
>>
>> ## Time-value Denial-of-Service Risks
>>
>> Leveraging transaction-relay and mempools mechanism to trigger a=20
>> time-value denial-of-service in a target application or protocol phase h=
as=20
>> already been considered many times in the past.
>>
>> E.g reaching hypothetical replacement limits to DoS payment channels=20
>> participants (cf. "Anti DoS for tx replacement" - bitcoin-dev 2013) or=
=20
>> DoSing a multi-party transaction by opt-ing out from replacement with a=
=20
>> double-spend (cf. "On Mempool Funny Games against Multi-Party Funded=20
>> Transactions" - lightning-dev 2021).
>>
>> Under current mempool rules (i.e ones deployed on 99% of network over th=
e=20
>> last years), a replacement cycling opens a new generic way to trigger a=
=20
>> denial-of-service in a Bitcoin application or protocol flow to paralyze =
the=20
>> execution.
>>
>> This denial-of-service can constitute a prolonged denial-of-service of=
=20
>> the targeted application / protocol, or a waste of the on-chain timevalu=
e=20
>> of the coins consumed by the application / protocol. Here again, risks=
=20
>> exposures is function of the application / protocol concrete combination=
 of=20
>> characteristics.
>>
>> Some protocols have lightweight anti-DoS measures to alleviate this=20
>> vector of denial-of-concern. E.g in lightning after 2016 blocks,=20
>> participants to a payment channel can forget the funding transaction=20
>> (BOLT2).
>>
>> ## Time-value Denial-of-Service Risks: The Lightning One-Link Case
>>
>> Let's see a concrete example of a time-value DoS triggered by a=20
>> replacement cycling.
>>
>> The public disclosure of replacement cycling attack has been mostly=20
>> centered on loss of funds risks affecting HTLC forwarding over Lightning=
=20
>> routing nodes. Independently, a replacement cycling attack can be levera=
ged=20
>> to provoke denial-of-service among a Lightning routing node and an end-n=
ode=20
>> on a spoke link.
>>
>> The attack works in the following fashion (offered HTLC on outgoing link=
)=20
>> as it was not fully fleshed out in the disclosure communications:
>> - Alice and Bob are lightning nodes, they share a funded chan
>> - Alice forwads a HTLC to Bob for further routing to Caroll
>> - Bob forwards the HTLC to Caroll and gets the HTLC preimage
>> - Bob witholds settltement on Alice - Bob link until chain tip height=20
>> reaches `cltv_expiry`
>> - Alice broadcast a HTLC-timeout to recover her funds
>> - Bob engages in a replacement cycling by repeatedly rebroadcasting the=
=20
>> HTLC-preimage and double-spending it
>>
>> Alice is stuck with her HTLC funds that cannot be recovered on-chain.=20
>> While Bob is paying a replacement penalty every time it happens, there=
=20
>> might be a scaling effect targeting many HTLC-timeout with a single HTLC=
=20
>> preimage (`option_anchors_zero_fee_htlc_tx`).
>>
>> It should be noted that in matters of offered HTLC expiration on an=20
>> outgoing link, each lightning implementation has its own logic, as this =
is=20
>> not something standardized (e.g ldk's `LATENCY_GRACE_PERIOD_BLOCKS`).
>>
>> It is left as an open question how an an attacker can economically=20
>> benefit from this denial-of-service.
>>
>> ## Loss of Funds Risks
>>
>> As it has been exposed during the public disclosure of the replacement=
=20
>> cycling attack, it can be leveraged to steal users funds from lightning=
=20
>> payment channels, as one protocol affected.
>>
>> As an extension, it can affect any other contracting protocol=20
>> (characterisics a. + c. + d.). On those protocols (e.g lightning or swap=
s),=20
>> the protocol semantic is driven by absolute / relative timelocks=20
>> initialized in a set of pre-signed transactions and finalized by the cha=
in=20
>> tip height or epoch time.
>>
>> The underlying funds security is conditional on the time-sensitive=20
>> broadcast and inclusion of the pre-signed transactions to execute an=20
>> off-chain state. Failing to fulfill this time-sensitive requirement can=
=20
>> lead to loss of funds.
>>
>> Generally, loss of funds risks affecting a multi-party application /=20
>> contracting protocols still depends on the usage of "short duration" of=
=20
>> relative / absolute timelocks.
>>
>> ## Second-Layers and Use-Cases
>>
>> We're further surveying deployed second-layers and use-cases either=20
>> affected by time-value DoS or loss of funds risks.
>>
>> (Transaction-relay technique like "transaction accelerators" have been=
=20
>> excluded from the list of potentially affected second-layers initially=
=20
>> published, actually it's neither a multi-party application or contractin=
g=20
>> protocol).
>>
>> On-chain DLC (contracting protocol): a funding transaction locks funds i=
n=20
>> a 2-of-2. A subsequent pair of contract execution transaction encodes DL=
C=20
>> result from oracle contribution. There can be a refund transaction under=
=20
>> timelocks (model: cf. "dlcspecs" - github 2020).
>>
>> On-chain DLC risks: loss of funds _only if oracle gets wrong_. Time-valu=
e=20
>> DoS risk on the funding transaction or with refund if timelock miselecti=
on.
>>
>> Coinjoin (multi-party application): a single joint transaction with=20
>> contributions from N inputs (model: cf. "Coinjoin: Bitcoin privacy for t=
he=20
>> real world" - bitcointalkg.org 2013)
>>
>> Coinjoin risks: no loss of funds risks. Time-value DoS risk, if a=20
>> fee-bumping of the joint transaction can be done by any user.
>>
>> Payjoin (multi-party application): a single joint transaction with=20
>> contributions from N inputs owned by a single user paying another user=
=20
>> (model: cf. "improving privacy using pay-to-endpoint" - blockstream blog=
=20
>> 2018).
>>
>> Payjoin risks: no loss of funds risks. Time-value DoS risk, if a=20
>> fee-bumping of the joint transaction can be done by any user.
>>
>> Wallet with time-sensitive paths (contracting protocols): a user locks u=
p=20
>> funds with a set of pre-signed transactions. Each pre-signed transaction=
=20
>> can have unique spending conditions and/or send to another user (model: =
cf.=20
>> "bip65 op_checklocktimeverify"
>> - bips 2014).
>>
>> Wallet with time-sensitive paths risks: loss of funds risk _only if spen=
d=20
>> path to third-party with divergent interest and timelock miselection_.=
=20
>> Time-value DoS risk _only if spend to third-party with divergent interes=
t=20
>> and timelock miselection_.
>>
>> Peerswap and submarine swaps (contracting protocol): a funding=20
>> transaction locks funds in a 2-of-2. A swap can be spend by 3 subsequent=
=20
>> transactions (invoice, coop, csv) to settle positively or negatively the=
=20
>> state of the swap (model: cf. "peerswap" - element github 2022).
>>
>> Peerswap and submarine swaps risks: loss of funds risk if timelock=20
>> miselection. Time value DoS risk.
>>
>> Batch payouts (multi-party application): a single joint transactions wit=
h=20
>> contributions from N inputs owned by a singler user paying a N number of=
=20
>> users (model: cf. "scaling bitcoin using payment batching" - bitcoin opt=
ech=20
>> 2021).
>>
>> Batch payouts risks: no loss of funds risks. Time-value DoS risk, if a=
=20
>> fee-bumping of the joint transaction can be done by any user.
>>
>> For all those second-layers and use-cases risks identification, I think =
a=20
>> replacement cycling attack is plausible, independently of the level of=
=20
>> network mempools congestion.
>>
>> On this area, thanks to the insights and observation from folks who have=
=20
>> participated in the initial security-handling around February 2023 - All=
=20
>> names have already been listed in the initial email.
>>
>> ## Conclusion
>>
>> A transaction-relay jamming can be identified as a protocol counterparty=
=20
>> or application participant interfering with the relay of transaction. If=
=20
>> the transactions are time-sensitive per the protocol semantic, this=20
>> interference can constitute a loss of funds risk. If the transactions ar=
e=20
>> only collaboratively built, this interference can constitute a timevalue=
=20
>> DoS risk. Replacement cycling attack constitutes one variant of class of=
=20
>> attacks, of which pinning is the other well-known variant.
>>
>> Additionally, in this context of class of attacks arising from the=20
>> interfacing of bitcoin applications and protocols with the base-layer=20
>> transaction-relay network and its mempools rules, it can be noteworthy t=
o=20
>> under-light some observations concerning
>> security-issue handling process.
>>
>> Firstly, there is not only a difficulty of diagnosticing correctly what=
=20
>> specific bitcoin software is potentially affected. Establishing a releva=
nt=20
>> diagnostic is not only saying what is affected, though also saying the t=
ype=20
>> of risk exposures (e.g plain loss of funds, fee griefing, bandwidth=20
>> denial-of-service) grieving each specific software.
>>
>> Secondly, once the diagnostic is done, there is the curative phase where=
=20
>> mitigation patches are developed and included in the codebase. Each=20
>> codebase is unique (e.g have its own language) and it can have its own=
=20
>> usual release schedule, indicating a the rate at which a mitigation patc=
h=20
>> can disseminate across its crowds of active users.
>>
>> Furthermore, in a decentralized ecosystem where each full-node can run=
=20
>> its own configuration of mempool policy rules on a wide variety of hardw=
are=20
>> host, not all mitigation strategies are equally viable. Considerations o=
n=20
>> the same level have already been weighted in the past e.g at the occasio=
n=20
>> of CVE-2021-31876 (replacement inheritance defect on bitcoin core).
>>
>> Don't trust, verify. All mistakes and opinions are my own.
>>
>> Cheers,
>> Antoine
>>
>

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

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

Hi /dev/fd0<div><br /></div><div>From my understanding of coinswap (model: =
cf. "Detailed protocol design for routed multi-transaction CoinSwap"), the =
contract transaction can be spend by either Alice timeout or Bob preimage. =
Belcher's coinswap (a contracting protocol) does not strictly restrain the =
second-stage transaction spending the contract transaction.</div><div><br /=
></div><div>Let's say you have Caroll -&gt; Alice -&gt; Bob as a routed coi=
nswap topology. Bob can broadcast a contract transaction, get it confirmed,=
 then engage in replacement cycling attack by leveraging a child transactio=
n spending the preimage path (it's only Bob private key), then continuously=
 replacing this child by.conflicting a UTXO non related to the coinswap. At=
 expiration of the relative timelock on C-A link, Caroll clawback the swapp=
ed UTXO with the timeout path.</div><div><br /></div><div>If this transacti=
on flow is the correct one, coinswap suffers from loss of funds and denial-=
of-service risks, at the image of lightning. Scaling up timelocks or monito=
ring the local mempool for preimage might be imperfect, yet practical mitig=
ations hardening against exploitations.</div><div><br /></div><div>Best,</d=
iv><div>Antoine<br /><br /></div><div class=3D"gmail_quote"><div dir=3D"aut=
o" class=3D"gmail_attr">Le vendredi 24 mai 2024 =C3=A0 11:59:28 UTC+1, /dev=
 /fd0 a =C3=A9crit=C2=A0:<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 Antoine,<div><br></div><div>Does this also affect <a href=
=3D"https://github.com/utxo-teleport/teleport-transactions/blob/master/docs=
/dev-book.md#how-coinswap-works" target=3D"_blank" rel=3D"nofollow" data-sa=
feredirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.=
com/utxo-teleport/teleport-transactions/blob/master/docs/dev-book.md%23how-=
coinswap-works&amp;source=3Dgmail&amp;ust=3D1716680915198000&amp;usg=3DAOvV=
aw3TPEqcQTwsUSzk-YPHWawR">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><b=
lockquote 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 detail=
ing more the non-lightning bitcoin use-cases affected by replacement cyclin=
g attacks, mostly under the denial-of-service angle (cf. &quot;All your mem=
pool are belong to us&quot; - bitcoin-dev 2023).<br><br>Excerpt from the or=
iginal public disclosure:<br><br>&gt;From my understanding the following li=
st of Bitcoin protocols and<br>&gt; applications could be affected by new d=
enial-of-service vectors under some<br>&gt; level of network mempools conge=
stion. Neither tests or advanced review of<br>&gt; specifications (when ava=
ilable) has been conducted for each of them:<br>&gt; - on-chain DLCs<br>&gt=
; - coinjoins<br>&gt; - payjoins<br>&gt; - wallets with time-sensitive path=
s<br>&gt; - peerswap and submarine swaps<br>&gt; - batch payouts<br>&gt; - =
transaction &quot;accelerators&quot;<br>&gt; <br>&gt; Inviting their develo=
pers, maintainers and operators to investigate how<br>&gt; replacement cycl=
ing attacks might disrupt their in-mempool chain of<br>&gt; transactions, o=
r fee-bumping flows at the shortest delay.<br><br>Also, this post intends t=
o provide the lineaments of a common template to be useful in case of futur=
e cross-layer security issues arising in the bitcoin ecosystem. Such templa=
te to be leveraged by any skilled folk involved in the resolution of a cros=
s-layer security-issue handling process.<br><br>(To be understood: without =
the necessary tangible involvement of the present author post, there is a s=
ufficient number of other folks in this ecosystem with the skillset and _th=
e guts_ to conduct such =C2=A0process in a reasonable fashion in the future=
).<br><br>## Replacement Cycling Attack (a quick reminder)<br><br>The attac=
ker goal of a replacement cycling attack is to delay the confirmation of a =
HTLC-timeout on an outgoing link of a routing node, sufficiently to enable =
an off-chain double-spend of a HTLC-preimage on an incoming link.<br><br>Th=
e 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 Mall=
et by the intermediary of Alice<br>- This HTLC expires at chain tip + 100 o=
utgoing link, chain tip + 140 incoming link (Alice Pov)<br>- Mallet receive=
s the HTLC on the Alice-Mallet links and does not settle it<br>- At chain t=
ip + 100, Alice broadcasts commitment tx + HTLC-timeout tx<br>- Mallet repl=
aces Alice&#39;s HTLC-timeout tx with a HTLC-preimage tx<br>- Mallet then r=
eplaces HTLC-preimage with a conflicting double-spend<br>- Mallet repeats t=
his trick until chain tip reaches tip + 140<br>- When chain tip + 140, Mall=
ory broadcasts HTLC-timeout to double-spend =C2=A0incoming link<br>- In par=
allel, Mallet broadcasts a HTLC-preimage to double-spend the forwarding lin=
k<br><br>This is a rough summary of one of the simplest scenario, for furth=
er details refers back to the original public disclosure, already cf. above=
.<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 spe=
ndings. 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 output=
s to a common transaction. Each user can commit more than one coin to the c=
ommon transaction.<br><br>c) Pre-signed transactions. The group of users is=
 pre-signing a chain of transactions to execute the protocol steps during a=
n interactive phase. After this phase, any user can broadcast the transacti=
on at any time, without further interactivity.<br><br>d) Absolute / Relativ=
e Timelocks. The set of pre-signed transactiosn might be encumbered by rela=
tive (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 been design=
ated as a multi-party application, the second class of things a contracting=
 protocol (e.g on the effects of mempool policy changes).<br><br>This disti=
nction mostly matters in term of security models. All of them sounds to pre=
sent some vector of transaction or package malleability.<br><br>## Time-val=
ue Denial-of-Service Risks<br><br>Leveraging transaction-relay and mempools=
 mechanism to trigger a time-value denial-of-service in a target applicatio=
n or protocol phase has already been considered many times in the past.<br>=
<br>E.g reaching hypothetical replacement limits to DoS payment channels pa=
rticipants (cf. &quot;Anti DoS for tx replacement&quot; - bitcoin-dev 2013)=
 or DoSing a multi-party transaction by opt-ing out from replacement with a=
 double-spend (cf. &quot;On Mempool Funny Games against Multi-Party Funded =
Transactions&quot; - lightning-dev 2021).<br><br>Under current mempool rule=
s (i.e ones deployed on 99% of network over the last years), a replacement =
cycling opens a new generic way to trigger a denial-of-service in a Bitcoin=
 application or protocol flow to paralyze the execution.<br><br>This denial=
-of-service can constitute a prolonged denial-of-service of the targeted ap=
plication / protocol, or a waste of the on-chain timevalue of the coins con=
sumed by the application / protocol. Here again, risks exposures is functio=
n of the application / protocol concrete combination of characteristics.<br=
><br>Some protocols have lightweight anti-DoS measures to alleviate this ve=
ctor of denial-of-concern. E.g in lightning after 2016 blocks, participants=
 to a payment channel can forget the funding transaction (BOLT2).<br><br>##=
 Time-value Denial-of-Service Risks: The Lightning One-Link Case<br><br>Let=
&#39;s see a concrete example of a time-value DoS triggered by a replacemen=
t cycling.<br><br>The public disclosure of replacement cycling attack has b=
een mostly centered on loss of funds risks affecting HTLC forwarding over L=
ightning routing nodes. Independently, a replacement cycling attack can be =
leveraged to provoke denial-of-service among a Lightning routing node and a=
n end-node on a spoke link.<br><br>The attack works in the following fashio=
n (offered HTLC on outgoing link) as it was not fully fleshed out in the di=
sclosure communications:<br>- Alice and Bob are lightning nodes, they share=
 a funded chan<br>- Alice forwads a HTLC to Bob for further routing to Caro=
ll<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 `c=
ltv_expiry`<br>- Alice broadcast a HTLC-timeout to recover her funds<br>- B=
ob engages in a replacement cycling by repeatedly rebroadcasting the HTLC-p=
reimage and double-spending it<br><br>Alice is stuck with her HTLC funds th=
at cannot be recovered on-chain. While Bob is paying a replacement penalty =
every time it happens, there might be a scaling effect targeting many HTLC-=
timeout with a single HTLC preimage (`option_anchors_zero_fee_htlc_tx`).<br=
><br>It should be noted that in matters of offered HTLC expiration on an ou=
tgoing link, each lightning implementation has its own logic, as this is no=
t something standardized (e.g ldk&#39;s `LATENCY_GRACE_PERIOD_BLOCKS`).<br>=
<br>It is left as an open question how an an attacker can economically bene=
fit 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 a=
ttack, it can be leveraged to steal users funds from lightning payment chan=
nels, as one protocol affected.<br><br>As an extension, it can affect any o=
ther contracting protocol (characterisics a. + c. + d.). On those protocols=
 (e.g lightning or swaps), the protocol semantic is driven by absolute / re=
lative timelocks initialized in a set of pre-signed transactions and finali=
zed by the chain tip height or epoch time.<br><br>The underlying funds secu=
rity is conditional on the time-sensitive broadcast and inclusion of the pr=
e-signed transactions to execute an off-chain state. Failing to fulfill thi=
s time-sensitive requirement can lead to loss of funds.<br><br>Generally, l=
oss of funds risks affecting a multi-party application / contracting protoc=
ols still depends on the usage of &quot;short duration&quot; of relative / =
absolute timelocks.<br><br>## Second-Layers and Use-Cases<br><br>We&#39;re =
further surveying deployed second-layers and use-cases either affected by t=
ime-value DoS or loss of funds risks.<br><br>(Transaction-relay technique l=
ike &quot;transaction accelerators&quot; have been excluded from the list o=
f potentially affected second-layers initially published, actually it&#39;s=
 neither a multi-party application or contracting protocol).<br><br>On-chai=
n DLC (contracting protocol): a funding transaction locks funds in a 2-of-2=
. A subsequent pair of contract execution transaction encodes DLC result fr=
om oracle contribution. There can be a refund transaction under timelocks (=
model: cf. &quot;dlcspecs&quot; - github 2020).<br><br>On-chain DLC risks: =
loss of funds _only if oracle gets wrong_. Time-value DoS risk on the fundi=
ng transaction or with refund if timelock miselection.<br><br>Coinjoin (mul=
ti-party application): a single joint transaction with contributions from N=
 inputs (model: cf. &quot;Coinjoin: Bitcoin privacy for the real world&quot=
; - <a href=3D"http://bitcointalkg.org" rel=3D"nofollow" target=3D"_blank" =
data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttp://b=
itcointalkg.org&amp;source=3Dgmail&amp;ust=3D1716680915199000&amp;usg=3DAOv=
Vaw0F9MaTBNLkfgxxIFiUVskD">bitcointalkg.org</a> 2013)<br><br>Coinjoin risks=
: no loss of funds risks. Time-value DoS risk, if a fee-bumping of the join=
t transaction can be done by any user.<br><br>Payjoin (multi-party applicat=
ion): a single joint transaction with contributions from N inputs owned by =
a single user paying another user (model: cf. &quot;improving privacy using=
 pay-to-endpoint&quot; - blockstream blog 2018).<br><br>Payjoin risks: no l=
oss of funds risks. Time-value DoS risk, if a fee-bumping of the joint tran=
saction can be done by any user.<br><br>Wallet with time-sensitive paths (c=
ontracting protocols): a user locks up funds with a set of pre-signed trans=
actions. Each pre-signed transaction can have unique spending conditions an=
d/or send to another user (model: cf. &quot;bip65 op_checklocktimeverify&qu=
ot;<br>- bips 2014).<br><br>Wallet with time-sensitive paths risks: loss of=
 funds risk _only if spend path to third-party with divergent interest and =
timelock miselection_. Time-value DoS risk _only if spend to third-party wi=
th divergent interest and timelock miselection_.<br><br>Peerswap and submar=
ine swaps (contracting protocol): a funding transaction locks funds in a 2-=
of-2. A swap can be spend by 3 subsequent transactions (invoice, coop, csv)=
 to settle positively or negatively the state of the swap (model: cf. &quot=
;peerswap&quot; - element github 2022).<br><br>Peerswap and submarine swaps=
 risks: loss of funds risk if timelock miselection. Time value DoS risk.<br=
><br>Batch payouts (multi-party application): a single joint transactions w=
ith contributions from N inputs owned by a singler user paying a N number o=
f users (model: cf. &quot;scaling bitcoin using payment batching&quot; - bi=
tcoin optech 2021).<br><br>Batch payouts risks: no loss of funds risks. Tim=
e-value DoS risk, if a fee-bumping of the joint transaction can be done by =
any user.<br><br>For all those second-layers and use-cases risks identifica=
tion, I think a replacement cycling attack is plausible, independently of t=
he level of network mempools congestion.<br><br>On this area, thanks to the=
 insights and observation from folks who have participated in the initial s=
ecurity-handling around February 2023 - All names have already been listed =
in the initial email.<br><br>## Conclusion<br><br>A transaction-relay jammi=
ng can be identified as a protocol counterparty or application participant =
interfering with the relay of transaction. If the transactions are time-sen=
sitive per the protocol semantic, this interference can constitute a loss o=
f funds risk. If the transactions are only collaboratively built, this inte=
rference can constitute a timevalue DoS risk. Replacement cycling attack co=
nstitutes one variant of class of attacks, of which pinning is the other we=
ll-known variant.<br><br>Additionally, in this context of class of attacks =
arising from the interfacing of bitcoin applications and protocols with the=
 base-layer transaction-relay network and its mempools rules, it can be not=
eworthy to under-light some observations concerning<br>security-issue handl=
ing process.<br><br>Firstly, there is not only a difficulty of diagnosticin=
g correctly what specific bitcoin software is potentially affected. Establi=
shing a relevant diagnostic is not only saying what is affected, though als=
o saying the type of risk exposures (e.g plain loss of funds, fee griefing,=
 bandwidth denial-of-service) grieving each specific software.<br><br>Secon=
dly, once the diagnostic is done, there is the curative phase where mitigat=
ion patches are developed and included in the codebase. Each codebase is un=
ique (e.g have its own language) and it can have its own usual release sche=
dule, indicating a the rate at which a mitigation patch can disseminate acr=
oss its crowds of active users.<br><br>Furthermore, in a decentralized ecos=
ystem where each full-node can run its own configuration of mempool policy =
rules on a wide variety of hardware host, not all mitigation strategies are=
 equally viable. Considerations on the same level have already been weighte=
d in the past e.g at the occasion of CVE-2021-31876 (replacement inheritanc=
e defect on bitcoin core).<br><br>Don&#39;t trust, verify. All mistakes and=
 opinions are my own.<br><br>Cheers,<br>Antoine<br></blockquote></div></blo=
ckquote></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/f9ac65db-9756-4c85-b376-6b6a286a2b2cn%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/f9ac65db-9756-4c85-b376-6b6a286a2b2cn%40googlegroups.com</a>.=
<br />

------=_Part_78198_1250213256.1716594862611--

------=_Part_78197_1136865387.1716594862611--