path: root/16/ad74f55ae7be50b7cb0680a10f3e4f775aecdd

Delivery-date: Tue, 27 Aug 2024 12:41:53 -0700
Received: from mail-yb1-f187.google.com ([209.85.219.187])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRB56XXC3AMGQETOIEIZY@googlegroups.com>)
	id 1sj24e-0004on-5P
	for bitcoindev@gnusha.org; Tue, 27 Aug 2024 12:41:53 -0700
Received: by mail-yb1-f187.google.com with SMTP id 3f1490d57ef6-e11368fa2e3sf11638809276.3
        for <bitcoindev@gnusha.org>; Tue, 27 Aug 2024 12:41:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1724787706; x=1725392506; 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=M4gLza5p1o2XzOPPi4bZNQvB+D2qSHeMcz+WTqw+PHo=;
        b=kyJ1P9FWoR23RUsNsxO3hFg84KpV+zdEwCFqjKllHH3XD4Zm5VoOlxcyQL0qiKTCVU
         6fUv1F41UA46BYbebbi5u9TgCzcYHXfOkx3Vy5VL5puIIbbCkUVKnTOgRT2hRAyZRrOn
         1VKhiVAhM4+Nv+b8IgVLHJABqJKS95qu2yQVIZ9Zo65RU7+ptNNFP3NVtvbxUuZLoWe0
         t8aWh/RQtwUUe3CLPtU5H/W5VRXUfk4NsEORF+MKWdNtH3IykeyDFvgIg6SOS7A6CFYF
         MehdtvShDb/WPhYBSHc62XIf2VBc4p0Hv6c6ECH7I4NzifPnnJ3x1igHFaCVHvvlbWBI
         fLjg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1724787706; x=1725392506; 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=M4gLza5p1o2XzOPPi4bZNQvB+D2qSHeMcz+WTqw+PHo=;
        b=GiwAamdJ4QuwJQmY/cT2G8Z64ihiBbBtR3e/uBM4pNBmmKK7bKRJwaSS6kBlXpnuoQ
         Qt5GAtYn9Gr6Xu1FKJSaKAAHzLQOqg0xI5w3vtzsRIij1pZRVr6y3AAOJETuPB/JP9g5
         An02MDsrquV6RW9EU+bJ3oaP2iPKbBnKFPMoz4uio/E0HW+wMNPCQvELVVIfBLM2j512
         cfkBoOtF/7OPSJ53WJx3GKJ6I9GUey5+axnvE0Cd8S7J4QQm8Yv8abAGiVY/5aB/u2aE
         Dh6lpy9nrUSicsiYlGfXHdknCwJNv1EBTOuXazx+nSMtJTUWUKvyAuDQZMd91CosgG0m
         d/KA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1724787706; x=1725392506;
        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=M4gLza5p1o2XzOPPi4bZNQvB+D2qSHeMcz+WTqw+PHo=;
        b=Rv14gd0v5m1oVM0f1e7M7p44w5DRY7wFpPdzJBXKdvVH3INuWBg9oGYodUv4FJwKKs
         O7zwXt9b1NTAfdXlnvf1mC0SnsW0OW44pr3wjLXPm/b9xfpKd00WZyL1S7NL0nM9DaTW
         FWFPiIjuXQvW3tMJrwciBx6HTfHAkOzMC/oZr5049fZoojYJj/CqJMw1GktP+lNvdkEK
         UyqqWB95YrXx6EADA/kb2TS68uLMR+a2w0TeZGX5A32Inql9K4q8gWTItNdTVKGyfOdl
         wl5wJTsYyO41LO3ToeyigpeJtp/s+1TEvQ3Vd1lGAMKH1rZN4Ih2gA6fOZ6SAvjvbK6p
         iODg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUo9ibRvQF//cztawjlAHEUAQ0Rnai2fwwm8Ll+JU4Ms0jZsRtGTiuymLlRM+iM/bnIOd5afY9CVdm5@gnusha.org
X-Gm-Message-State: AOJu0Yxh8JFY/U86HsIrF/tiLJqxNdb5vNnnsPmPSVHiI1n/1HC+R8VG
	qyTM1qQBDVuHq0hKWoVqBo7si8+j6kxFtn9wnXURzkwVJWJ8P9gz
X-Google-Smtp-Source: AGHT+IHgBroi92lC7J1gVIpelxMz6DJz989SmZQ9VUuBtKsK+AnXfOkIxR3sSqJmBMrVAxpOPeCSEA==
X-Received: by 2002:a05:6902:2207:b0:e16:506a:3431 with SMTP id 3f1490d57ef6-e17a8c45d0emr17017306276.51.1724787705347;
        Tue, 27 Aug 2024 12:41:45 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:70b:b0:e13:d4bd:79fd with SMTP id
 3f1490d57ef6-e178bd21d2als4481177276.1.-pod-prod-05-us; Tue, 27 Aug 2024
 12:41:43 -0700 (PDT)
X-Received: by 2002:a05:690c:f0b:b0:6ad:75f6:678d with SMTP id 00721157ae682-6c624fb6b47mr164303287b3.4.1724787703269;
        Tue, 27 Aug 2024 12:41:43 -0700 (PDT)
Received: by 2002:a81:e50a:0:b0:699:2980:4ef6 with SMTP id 00721157ae682-6d00679fd28ms7b3;
        Tue, 27 Aug 2024 12:39:38 -0700 (PDT)
X-Received: by 2002:a05:690c:6104:b0:6b1:18bd:a79d with SMTP id 00721157ae682-6cfbbbd4c82mr45314167b3.40.1724787577398;
        Tue, 27 Aug 2024 12:39:37 -0700 (PDT)
Date: Tue, 27 Aug 2024 12:39:37 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <57c52a0c-c390-4b7b-8247-8612a489cb98n@googlegroups.com>
In-Reply-To: <CALeFGL1dLhdvdePzt5xdZxskcU6WJDJL_PSmO2u2Z1nKZCKMag@mail.gmail.com>
References: <ZqyQtNEOZVgTRw2N@petertodd.org>
 <CALeFGL1dLhdvdePzt5xdZxskcU6WJDJL_PSmO2u2Z1nKZCKMag@mail.gmail.com>
Subject: Re: [bitcoindev] Keyless Anchors Are Vulnerable To Replacement
 Cycling Attacks
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_61658_1794754944.1724787577217"
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_61658_1794754944.1724787577217
Content-Type: multipart/alternative; 
	boundary="----=_Part_61659_181252100.1724787577217"

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

Hello,

> This feels like someone should have published it before. But I can't find=
=20
an
> obvious citation (eg in any of the documentation around keyless ephemeral
> anchors), so I'll publish one here. Maybe I'm the first to point this out
> explicitly? Probably not; I'd appreciate an earlier citation if one=20
exists.

Same, I cannot remember about an earlier citation in doucmentation around=
=20
keyless
ephemeral anchors, and while this is a concern I was aware of I was=20
expecting
that some reviewer of ephemeral anchors would figure it out earlier (or at=
=20
least=20
praying for that...). =20

> tl;dr: _Anyone_ can do a replacement cycling attack on transactions where=
=20
fees
> are paid via CPFP via keyless anchors and similar outputs that a=20
third-party
> can double-spend. Secondly, for attackers who were already planning on=20
making a
> transaction with a higher total fee and total fee-rate than the target,=
=20
this
> attack is almost free.

Yes, about the second observation, see the section 5.2 about high-fee=20
collaboration
transactions advantage in the write-up which was initially released at the
disclosure of replacement cycling attacks [0].

[0]=20
https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/r=
eplacement-cycling.pdf

In my belief, the simple fact that any bitcoin economical actor originating
transaction traffic at regular interval (e.g LSP or exchange batching) can
leverage that position to engage in replacement cycling attacks is a real=
=20
worry.

> # The Attack
>=20
> Suppose that Alice has created a 2 transaction package consisting of=20
low-fee or
> zero-fee transaction A, whose fees are CPFP paid via a keyless ephemeral=
=20
anchor
> spent by transaction B. For B to pay fees, obviously it must spend a=20
second
> transaction output.
>=20
> Mallory can cycle A and B out of mempools by broadcasting transaction B2,
> spending his own output and the keyless ephemeral anchor of A, at a highe=
r
> fee/fee-rate than B. Next, Mallory broadcasts B3, double-spending B2 by
> spending Mallory's input but not the ephemeral anchor of A. Assuming=20
Mallory
> needed to mine B3 anyway, the only cost to this attack is the small=20
chance that
> B2 will in fact be mined between the time that B2 is replaced by B3.
>=20
> At this point A is no longer economical to mine as B has been cycled out,=
=20
and A
> may be dropped from mempools depending on the circumstances.

Yes, in my understanding this scenario works. I think can even maliciously=
=20
batch
B3 to replace a N number of keyless spending B2 transactions at the same=20
time.

> ## SIGHASH_ANYONECANPAY
>=20
> Obviously, a similar attack is possible against SIGHASH_ANYONECANPAY-usin=
g
> transactions, provided that _all_ signatures sign with=20
SIGHASH_ANYONECANPAY.

Yes, a single SIGHASH_ALL locks-in the spent input, and as such avoid a=20
third-party
to adds a higher-fee / feerate input, then to be ulteriorly conflited with.=
=20
There
might be some data carriage style transactions using this pattern...

> # Countermeasures
>=20
> As with other replacement cycling attacks, rebroadcasting A and B fixes=
=20
the
> issue. I think the existence of this additional type of replacement=20
cycling
> attack suggests that adding an optional rebroadcasting module to Bitcoin=
=20
Core
> that would keep track of dropped transactions and re-add them to mempools=
=20
when
> they are again valid would make sense. This fixes all replacement cycling
> attacks and there's probably lots of nodes who have the memory and/or dis=
k
> space to keep track of dropped transactions like this.
>=20
> Preventing the replacement of B2 with B3 is _not_ a viable=20
countermeasure: if
> that replacement was prohibited, attackers could in turn exploit that=20
rule as a
> new form of transaction pinning!

I still think altruistic rebroadcasting is a very limited mitigation as=20
even beefy
nodes have computationally-limited memory and/or disk spaces. They would=20
need to have
some ordering of the dropped transactions e.g caches by tiers of feerate=20
group and
a replacement cycling attacker would just have to spam the top cache.

I believe it was already discussed there and in the previous email (I might=
=20
be
missing something ?) [1].

[1] https://groups.google.com/g/bitcoindev/c/qEx4K8lGnLk/m/AMPqDi6MBwAJ

> # Privacy
>=20
> The fact that rebroadcasting is a countermeasure is a privacy concern.=20
Each
> time a transaction is rebroadcast by the sender is a potential=20
opportunity to
> track the origin of a transaction. Again, having third parties=20
rebroadcasting
> transactions altruistically would mitigate this privacy concern.

Yes...On the other hand third parties rebroadcasting transactions are now
exposing themselves to be injected DoS traffic. Having full-nodes offering =
a
threshold of their memory / CPU cyles to process anonymizing traffic is=20
great,
especially for the marginal lighnting user. When it's a lightning hub with
a lot of channel funds, I believe it's naive to expect those additional=20
memory /=20
CPU cyles cannot be spammed for exploitation purposes.

> It kinda seems like this might introduce a DOS vector to the nodes=20
running this
> module since you can keep cycling B3, B4 etc. and force the mempool to=20
house
> all of these until one of them gets mined. Further, it would cause the=20
mempool
> to have to decide which of these dead transactions gets priority upon the=
=20
eviction
> of the conflicting one. Is this something you've given thought to?=20
Admittedly I
> haven't dived deep into it.

I did, and effectively you're running into hierarchy of caches management=
=20
styles of issues [2]

[2] https://github.com/bitcoin/bitcoin/issues/28699

Best,
Antoine
ots hash: eba1b16753146707a07dcd1aee1ca066fcb323e18222be7282088c49d9f44266
Le vendredi 2 ao=C3=BBt 2024 =C3=A0 23:00:16 UTC+1, Keagan McClelland a =C3=
=A9crit :

> >  I think the existence of this additional type of replacement cycling
> attack suggests that adding an optional rebroadcasting module to Bitcoin=
=20
> Core
> that would keep track of dropped transactions and re-add them to mempools=
=20
> when
> they are again valid would make sense. This fixes all replacement cycling
> attacks and there's probably lots of nodes who have the memory and/or dis=
k
> space to keep track of dropped transactions like this.
>
> It kinda seems like this might introduce a DOS vector to the nodes runnin=
g=20
> this
> module since you can keep cycling B3, B4 etc. and force the mempool to=20
> house
> all of these until one of them gets mined. Further, it would cause the=20
> mempool
> to have to decide which of these dead transactions gets priority upon the=
=20
> eviction
> of the conflicting one. Is this something you've given thought to?=20
> Admittedly I
> haven't dived deep into it.
>
> Keags
>
> On Fri, Aug 2, 2024 at 5:30=E2=80=AFAM Peter Todd <pe...@petertodd.org> w=
rote:
>
>> This feels like someone should have published it before. But I can't fin=
d=20
>> an
>> obvious citation (eg in any of the documentation around keyless ephemera=
l
>> anchors), so I'll publish one here. Maybe I'm the first to point this ou=
t
>> explicitly? Probably not; I'd appreciate an earlier citation if one=20
>> exists.
>>
>>
>> tl;dr: _Anyone_ can do a replacement cycling attack on transactions wher=
e=20
>> fees
>> are paid via CPFP via keyless anchors and similar outputs that a=20
>> third-party
>> can double-spend. Secondly, for attackers who were already planning on=
=20
>> making a
>> transaction with a higher total fee and total fee-rate than the target,=
=20
>> this
>> attack is almost free.
>>
>>
>> # The Attack
>>
>> Suppose that Alice has created a 2 transaction package consisting of=20
>> low-fee or
>> zero-fee transaction A, whose fees are CPFP paid via a keyless ephemeral=
=20
>> anchor
>> spent by transaction B. For B to pay fees, obviously it must spend a=20
>> second
>> transaction output.
>>
>> Mallory can cycle A and B out of mempools by broadcasting transaction B2=
,
>> spending his own output and the keyless ephemeral anchor of A, at a high=
er
>> fee/fee-rate than B. Next, Mallory broadcasts B3, double-spending B2 by
>> spending Mallory's input but not the ephemeral anchor of A. Assuming=20
>> Mallory
>> needed to mine B3 anyway, the only cost to this attack is the small=20
>> chance that
>> B2 will in fact be mined between the time that B2 is replaced by B3.
>>
>> At this point A is no longer economical to mine as B has been cycled out=
,=20
>> and A
>> may be dropped from mempools depending on the circumstances.
>>
>>
>> ## SIGHASH_ANYONECANPAY
>>
>> Obviously, a similar attack is possible against SIGHASH_ANYONECANPAY-usi=
ng
>> transactions, provided that _all_ signatures sign with=20
>> SIGHASH_ANYONECANPAY.
>>
>>
>> # Countermeasures
>>
>> As with other replacement cycling attacks, rebroadcasting A and B fixes=
=20
>> the
>> issue. I think the existence of this additional type of replacement=20
>> cycling
>> attack suggests that adding an optional rebroadcasting module to Bitcoin=
=20
>> Core
>> that would keep track of dropped transactions and re-add them to mempool=
s=20
>> when
>> they are again valid would make sense. This fixes all replacement cyclin=
g
>> attacks and there's probably lots of nodes who have the memory and/or di=
sk
>> space to keep track of dropped transactions like this.
>>
>> Preventing the replacement of B2 with B3 is _not_ a viable=20
>> countermeasure: if
>> that replacement was prohibited, attackers could in turn exploit that=20
>> rule as a
>> new form of transaction pinning!
>>
>>
>> # Privacy
>>
>> The fact that rebroadcasting is a countermeasure is a privacy concern.=
=20
>> Each
>> time a transaction is rebroadcast by the sender is a potential=20
>> opportunity to
>> track the origin of a transaction. Again, having third parties=20
>> rebroadcasting
>> transactions altruistically would mitigate this privacy concern.
>>
>> --=20
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to bitcoindev+...@googlegroups.com.
>> To view this discussion on the web visit=20
>> https://groups.google.com/d/msgid/bitcoindev/ZqyQtNEOZVgTRw2N%40petertod=
d.org
>> .
>>
>

--=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/57c52a0c-c390-4b7b-8247-8612a489cb98n%40googlegroups.com.

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

Hello,<br /><br />&gt; This feels like someone should have published it bef=
ore. But I can't find an<br />&gt; obvious citation (eg in any of the docum=
entation around keyless ephemeral<br />&gt; anchors), so I'll publish one h=
ere. Maybe I'm the first to point this out<br />&gt; explicitly? Probably n=
ot; I'd appreciate an earlier citation if one exists.<br /><br />Same, I ca=
nnot remember about an earlier citation in doucmentation around keyless<br =
/>ephemeral anchors, and while this is a concern I was aware of I was expec=
ting<br />that some reviewer of ephemeral anchors would figure it out earli=
er (or at least <br />praying for that...). =C2=A0<br /><br />&gt; tl;dr: _=
Anyone_ can do a replacement cycling attack on transactions where fees<br /=
>&gt; are paid via CPFP via keyless anchors and similar outputs that a thir=
d-party<br />&gt; can double-spend. Secondly, for attackers who were alread=
y planning on making a<br />&gt; transaction with a higher total fee and to=
tal fee-rate than the target, this<br />&gt; attack is almost free.<br /><b=
r />Yes, about the second observation, see the section 5.2 about high-fee c=
ollaboration<br />transactions advantage in the write-up which was initiall=
y released at the<br />disclosure of replacement cycling attacks [0].<br />=
<br />[0] https://github.com/ariard/mempool-research/blob/2023-10-replaceme=
nt-paper/replacement-cycling.pdf<br /><br />In my belief, the simple fact t=
hat any bitcoin economical actor originating<br />transaction traffic at re=
gular interval (e.g LSP or exchange batching) can<br />leverage that positi=
on to engage in replacement cycling attacks is a real worry.<br /><br />&gt=
; # The Attack<br />&gt; <br />&gt; Suppose that Alice has created a 2 tran=
saction package consisting of low-fee or<br />&gt; zero-fee transaction A, =
whose fees are CPFP paid via a keyless ephemeral anchor<br />&gt; spent by =
transaction B. For B to pay fees, obviously it must spend a second<br />&gt=
; transaction output.<br />&gt; <br />&gt; Mallory can cycle A and B out of=
 mempools by broadcasting transaction B2,<br />&gt; spending his own output=
 and the keyless ephemeral anchor of A, at a higher<br />&gt; fee/fee-rate =
than B. Next, Mallory broadcasts B3, double-spending B2 by<br />&gt; spendi=
ng Mallory's input but not the ephemeral anchor of A. Assuming Mallory<br /=
>&gt; needed to mine B3 anyway, the only cost to this attack is the small c=
hance that<br />&gt; B2 will in fact be mined between the time that B2 is r=
eplaced by B3.<br />&gt; <br />&gt; At this point A is no longer economical=
 to mine as B has been cycled out, and A<br />&gt; may be dropped from memp=
ools depending on the circumstances.<br /><br />Yes, in my understanding th=
is scenario works. I think can even maliciously batch<br />B3 to replace a =
N number of keyless spending B2 transactions at the same time.<div><br /></=
div><div>&gt; ## SIGHASH_ANYONECANPAY<br />&gt; <br />&gt; Obviously, a sim=
ilar attack is possible against SIGHASH_ANYONECANPAY-using<br />&gt; transa=
ctions, provided that _all_ signatures sign with SIGHASH_ANYONECANPAY.<br /=
><br />Yes, a single SIGHASH_ALL locks-in the spent input, and as such avoi=
d a third-party<br />to adds a higher-fee / feerate input, then to be ulter=
iorly conflited with. There<br />might be some data carriage style transact=
ions using this pattern...<br /><br />&gt; # Countermeasures<br />&gt; <br =
/>&gt; As with other replacement cycling attacks, rebroadcasting A and B fi=
xes the<br />&gt; issue. I think the existence of this additional type of r=
eplacement cycling<br />&gt; attack suggests that adding an optional rebroa=
dcasting module to Bitcoin Core<br />&gt; that would keep track of dropped =
transactions and re-add them to mempools when<br />&gt; they are again vali=
d would make sense. This fixes all replacement cycling<br />&gt; attacks an=
d there's probably lots of nodes who have the memory and/or disk<br />&gt; =
space to keep track of dropped transactions like this.<br />&gt; <br />&gt;=
 Preventing the replacement of B2 with B3 is _not_ a viable countermeasure:=
 if<br />&gt; that replacement was prohibited, attackers could in turn expl=
oit that rule as a<br />&gt; new form of transaction pinning!<br /><br />I =
still think altruistic rebroadcasting is a very limited mitigation as even =
beefy<br />nodes have computationally-limited memory and/or disk spaces. Th=
ey would need to have<br />some ordering of the dropped transactions e.g ca=
ches by tiers of feerate group and<br />a replacement cycling attacker woul=
d just have to spam the top cache.<br /><br />I believe it was already disc=
ussed there and in the previous email (I might be<br />missing something ?)=
 [1].<br /><br />[1] https://groups.google.com/g/bitcoindev/c/qEx4K8lGnLk/m=
/AMPqDi6MBwAJ<br /><br />&gt; # Privacy<br />&gt; <br />&gt; The fact that =
rebroadcasting is a countermeasure is a privacy concern. Each<br />&gt; tim=
e a transaction is rebroadcast by the sender is a potential opportunity to<=
br />&gt; track the origin of a transaction. Again, having third parties re=
broadcasting<br />&gt; transactions altruistically would mitigate this priv=
acy concern.<br /><br />Yes...On the other hand third parties rebroadcastin=
g transactions are now<br />exposing themselves to be injected DoS traffic.=
 Having full-nodes offering a<br />threshold of their memory / CPU cyles to=
 process anonymizing traffic is great,<br />especially for the marginal lig=
hnting user. When it's a lightning hub with<br />a lot of channel funds, I =
believe it's naive to expect those additional memory / <br />CPU cyles cann=
ot be spammed for exploitation purposes.<br /><br />&gt; It kinda seems lik=
e this might introduce a DOS vector to the nodes running this<br />&gt; mod=
ule since you can keep cycling B3, B4 etc. and force the mempool to house<b=
r />&gt; all of these until one of them gets mined. Further, it would cause=
 the mempool<br />&gt; to have to decide which of these dead transactions g=
ets priority upon the eviction<br />&gt; of the conflicting one. Is this so=
mething you've given thought to? Admittedly I<br />&gt; haven't dived deep =
into it.<br /><br />I did, and effectively you're running into hierarchy of=
 caches management styles of issues [2]<br /><br />[2] https://github.com/b=
itcoin/bitcoin/issues/28699<br /><br />Best,<br />Antoine<br />ots hash: eb=
a1b16753146707a07dcd1aee1ca066fcb323e18222be7282088c49d9f44266<br /></div><=
div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le vendred=
i 2 ao=C3=BBt 2024 =C3=A0 23:00:16 UTC+1, Keagan McClelland a =C3=A9crit=C2=
=A0:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8=
ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir=
=3D"ltr">&gt;=C2=A0=C2=A0I think the existence of this additional type of r=
eplacement cycling<br>attack suggests that adding an optional rebroadcastin=
g module to Bitcoin Core<br>that would keep track of dropped transactions a=
nd re-add them to mempools when<br>they are again valid would make sense. T=
his fixes all replacement cycling<br>attacks and there&#39;s probably lots =
of nodes who have the memory and/or disk<br>space to keep track of dropped =
transactions like this.<div><br></div></div><div dir=3D"ltr"><div>It kinda =
seems like this might introduce a DOS vector to the nodes running this</div=
><div>module since you can keep cycling B3, B4 etc. and force the mempool t=
o house</div><div>all of these until one of them gets mined. Further, it wo=
uld cause the mempool<br></div><div>to have to decide which of these dead t=
ransactions gets priority upon the eviction</div><div>of the conflicting on=
e. Is this something you&#39;ve given thought to? Admittedly I</div><div>ha=
ven&#39;t dived deep into it.</div><div><br></div><div>Keags</div></div><br=
><div class=3D"gmail_quote"></div><div class=3D"gmail_quote"><div dir=3D"lt=
r" class=3D"gmail_attr">On Fri, Aug 2, 2024 at 5:30=E2=80=AFAM Peter Todd &=
lt;<a href data-email-masked rel=3D"nofollow">pe...@petertodd.org</a>&gt; w=
rote:<br></div></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">This feels like someone should have published it bef=
ore. But I can&#39;t find an<br>
obvious citation (eg in any of the documentation around keyless ephemeral<b=
r>
anchors), so I&#39;ll publish one here. Maybe I&#39;m the first to point th=
is out<br>
explicitly? Probably not; I&#39;d appreciate an earlier citation if one exi=
sts.<br>
<br>
<br>
tl;dr: _Anyone_ can do a replacement cycling attack on transactions where f=
ees<br>
are paid via CPFP via keyless anchors and similar outputs that a third-part=
y<br>
can double-spend. Secondly, for attackers who were already planning on maki=
ng a<br>
transaction with a higher total fee and total fee-rate than the target, thi=
s<br>
attack is almost free.<br>
<br>
<br>
# The Attack<br>
<br>
Suppose that Alice has created a 2 transaction package consisting of low-fe=
e or<br>
zero-fee transaction A, whose fees are CPFP paid via a keyless ephemeral an=
chor<br>
spent by transaction B. For B to pay fees, obviously it must spend a second=
<br>
transaction output.<br>
<br>
Mallory can cycle A and B out of mempools by broadcasting transaction B2,<b=
r>
spending his own output and the keyless ephemeral anchor of A, at a higher<=
br>
fee/fee-rate than B. Next, Mallory broadcasts B3, double-spending B2 by<br>
spending Mallory&#39;s input but not the ephemeral anchor of A. Assuming Ma=
llory<br>
needed to mine B3 anyway, the only cost to this attack is the small chance =
that<br>
B2 will in fact be mined between the time that B2 is replaced by B3.<br>
<br>
At this point A is no longer economical to mine as B has been cycled out, a=
nd A<br>
may be dropped from mempools depending on the circumstances.<br>
<br>
<br>
## SIGHASH_ANYONECANPAY<br>
<br>
Obviously, a similar attack is possible against SIGHASH_ANYONECANPAY-using<=
br>
transactions, provided that _all_ signatures sign with SIGHASH_ANYONECANPAY=
.<br>
<br>
<br>
# Countermeasures<br>
<br>
As with other replacement cycling attacks, rebroadcasting A and B fixes the=
<br>
issue. I think the existence of this additional type of replacement cycling=
<br>
attack suggests that adding an optional rebroadcasting module to Bitcoin Co=
re<br>
that would keep track of dropped transactions and re-add them to mempools w=
hen<br>
they are again valid would make sense. This fixes all replacement cycling<b=
r>
attacks and there&#39;s probably lots of nodes who have the memory and/or d=
isk<br>
space to keep track of dropped transactions like this.<br>
<br>
Preventing the replacement of B2 with B3 is _not_ a viable countermeasure: =
if<br>
that replacement was prohibited, attackers could in turn exploit that rule =
as a<br>
new form of transaction pinning!<br>
<br>
<br>
# Privacy<br>
<br>
The fact that rebroadcasting is a countermeasure is a privacy concern. Each=
<br>
time a transaction is rebroadcast by the sender is a potential opportunity =
to<br>
track the origin of a transaction. Again, having third parties rebroadcasti=
ng<br>
transactions altruistically would mitigate this privacy concern.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer nofollow" target=3D"_bl=
ank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhtt=
ps://petertodd.org&amp;source=3Dgmail&amp;ust=3D1724873817496000&amp;usg=3D=
AOvVaw2h78ORKVv3ov7rkoL62L6T">https://petertodd.org</a> &#39;peter&#39;[:-1=
]@<a href=3D"http://petertodd.org" rel=3D"noreferrer nofollow" target=3D"_b=
lank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dht=
tp://petertodd.org&amp;source=3Dgmail&amp;ust=3D1724873817496000&amp;usg=3D=
AOvVaw142v0GWjDn0fO07vPZ0EYl">petertodd.org</a><br>
<br></blockquote></div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">
-- <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 data-email-masked rel=3D"nofollow">bitcoindev+...@googlegro=
ups.com</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/ZqyQtNEOZVgTRw2N%40petertodd.org" rel=3D"noreferrer n=
ofollow" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/u=
rl?hl=3Dfr&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/ZqyQtNEOZVg=
TRw2N%2540petertodd.org&amp;source=3Dgmail&amp;ust=3D1724873817496000&amp;u=
sg=3DAOvVaw1HfVegBs8XJgsMrdeYK9Gy">https://groups.google.com/d/msgid/bitcoi=
ndev/ZqyQtNEOZVgTRw2N%40petertodd.org</a>.<br>
</blockquote></div>
</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/57c52a0c-c390-4b7b-8247-8612a489cb98n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/57c52a0c-c390-4b7b-8247-8612a489cb98n%40googlegroups.com</a>.=
<br />

------=_Part_61659_181252100.1724787577217--

------=_Part_61658_1794754944.1724787577217--