path: root/ce/4c84ffa5b02ea3b8275bdef2d4cabab77de1ae

Delivery-date: Fri, 02 Aug 2024 15:00:23 -0700
Received: from mail-oo1-f60.google.com ([209.85.161.60])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDV6R2XBYEMBB35NWW2QMGQEIEDMMGA@googlegroups.com>)
	id 1sa0Jz-0007Ij-1P
	for bitcoindev@gnusha.org; Fri, 02 Aug 2024 15:00:23 -0700
Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-5c654141680sf2579511eaf.0
        for <bitcoindev@gnusha.org>; Fri, 02 Aug 2024 15:00:22 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1722636017; cv=pass;
        d=google.com; s=arc-20160816;
        b=OcJ1cg6KEoab9WnVW9BX2xogcoaMhLEpZXM5VIFppRyNe2njdNodmNmT9SERedd0d7
         LuBVOnNX5P5L1eCxnp67SfoDaxZfVoaWoCCdq2no4Qn0Kt3y8x62TmYqsSv9rFfTO+80
         lF30yCPgXJbGz1ocgWXo82/FNlG1Mvpc7Ub+wbXCxfBO7pAL9JUs9AQ5u29BVWGyRyjC
         yAALDVixlCTkSeOwMacw78FATfFnHvIXNyBZ1ixqQzhvR5zJJfxbe+obZZKdIWqDJZly
         E1MBtZsb1mQ7MRH7AtEM3g9KEL9fs094c1NuS+0Sf0aNvuau+lu9hXuNNieV4MzVshKJ
         TJhA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=m+FxbGSlTwPa60QqXt33Zx1UktZmTV/Y9ab/OM83lDA=;
        fh=72dPR5rXcgqj0RB9T2vJ+5WAOX3r0PWf4GN0I95BbT4=;
        b=KYJnhxQm6RrgXDhr3dj2gpStHb71z1YTTyb1i/V8wAI3c97+z2jB5zJZ/F+rmO1Yih
         bz27YXnEX8rVKsB0IP5UBD6+CoY/DZ4Jx9/gIxFyLVE/w6EEKDmZeSrdEG+uk1rDFnm6
         UgZuFresjum9OgkDVh7v5LDwzPiaXATV1aJwGYDeNplAFYV+iPVd64APQllet+UbkcQT
         qII2W+OmSmyhHUzfN3GDgLKMYi2J/RmoiWItpmXLFZP0eDV/ky/pcbPMIWO4EKTVi52G
         gZnskpAVGL3Yi1dl8KjKYvEbeXFvudMcYAK6Aduh5fDqDdY8Zhk5hZ2QV/wBV1d+2b7B
         H0Kw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=nGyYuxEt;
       spf=pass (google.com: domain of keagan.mcclelland@gmail.com designates 2607:f8b0:4864:20::f2e as permitted sender) smtp.mailfrom=keagan.mcclelland@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1722636017; x=1723240817; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=m+FxbGSlTwPa60QqXt33Zx1UktZmTV/Y9ab/OM83lDA=;
        b=w2pxNpMpU/EdaQS2BDWm+tNCQQXGLtwbwdY4D0X4PqMnDCgMT8iYyQd+Z/qDyc6wO/
         AD/X9iCpEf+LR+VxphWymK88ZxElm8CEo+75sVYiRJLJybhfDBxRXffR6cJOey9UaEze
         TFRNYEG3l6RrDGFM8QKK2yQP3qHDpHGXL6HLRt00qzPXzc5jcSrNuX1MK7sP/hRkcTYG
         jWsaEO2XXzPCZNY7+p26fAdlusUR0VAd/CMbvA+MjLz+vCyfvOyg1HSPiGFe4en7AN+P
         B220xFp6BE1m1qFrpwf2h6I+ak9G5rW3cCKB5Y0Lp/05ZXt1q1j6t8RYjrQgnSVGKo49
         46Sw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1722636017; x=1723240817; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=m+FxbGSlTwPa60QqXt33Zx1UktZmTV/Y9ab/OM83lDA=;
        b=LPiZxbczS+UIFodCebpAwpNhs/nhw9IXTP6CRtQBrEv0xBSywMoLnqqFo54f6eKmwN
         W7kAKN3rm6iz/Dd2ne1zKABOOExdBSz7fPVpls4Z0521YzMXYvJj4ngvhrcizrlls5sZ
         d1t6PQI+mPcuH8++M9CxmQKCV//XPuX3CNctF6fcUQ7uO9nj7aXyJ1hUu4TbIvGPLf71
         wFz7z8odMRmpv4d1gLYJrmZN9Vm/5FIU+in+rLLPlrT38JpOgKh9hTyFRjb2iDRzwUlR
         hSZaWbQ+gnkF1vRN0sz2fkel+PR5T4HmOHVcLbj0O7uw9ZqFw5JJb5k1BZWwO5qUzqza
         eU7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1722636017; x=1723240817;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=m+FxbGSlTwPa60QqXt33Zx1UktZmTV/Y9ab/OM83lDA=;
        b=a8qczWUT7DF6RINXtunh+qRZ7WTGJ4vq0wHVxPzuZ9PdC8xf8JOPdNnA50L8GrmAKy
         UNdHd7AY5DTjQa75RPO8K/1IPliMilIfRPWAklWXMBHKiokSr5XTAl7uDP5iVw3gUEG7
         HPQzOrt52OR3W5eBGCdXFG8VlGQYYOwOUfKnNZ2nxrtPRNEHrfqmNwtovO/dtdrewnhV
         ASk+HoYxyMPqXyA6cYbjvD/Hs8YeHGz/0JmDELOiJnqPmiUSCoH52wF4/JgPR+y6QPSp
         RAcEkoLFmUi5BsNHDyqQlbKWlLChO749Xm2WoIFZyAZwhI6vzF7EgIC/qWsUMD5SgGGG
         sqxw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVpXvrSeIQXKyTURdCblHchYLWJORM8X7UI+Fx1UOfp1LJVoV2TSJZaqS79nvWiP/u+ycHNJc671ukT@gnusha.org
X-Gm-Message-State: AOJu0YxyPB4IcHA4eD1nUJ261KQOgm8oAP69B2EcWuBilwkdewqdaZSD
	uWFJX9y9A20XpH4ECcfaerRnloiFybMRQSkewJX7tOy04zXvjBdP
X-Google-Smtp-Source: AGHT+IHuCfVEZG/hg221fSKzGwa0EoMHSVUHl9pDD8boWQw58z12UyTzAh8QlQtNcJIqG/5S0C0H/A==
X-Received: by 2002:a4a:d695:0:b0:5d5:b51d:e61b with SMTP id 006d021491bc7-5d625a247a1mr2906796eaf.0.1722636016661;
        Fri, 02 Aug 2024 15:00:16 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a4a:de87:0:b0:5c4:2c2b:2a0c with SMTP id 006d021491bc7-5d8012d3ae9ls359661eaf.0.-pod-prod-04-us;
 Fri, 02 Aug 2024 15:00:15 -0700 (PDT)
X-Received: by 2002:a05:6808:1993:b0:3db:25f6:a4b6 with SMTP id 5614622812f47-3db5585b50bmr58234b6e.10.1722636015311;
        Fri, 02 Aug 2024 15:00:15 -0700 (PDT)
Received: by 2002:a05:6808:2349:b0:3db:155f:56ed with SMTP id 5614622812f47-3db5623503emsb6e;
        Fri, 2 Aug 2024 14:59:09 -0700 (PDT)
X-Received: by 2002:a17:902:f650:b0:1fb:d07c:64cd with SMTP id d9443c01a7336-1ff52492003mr95702215ad.21.1722635948034;
        Fri, 02 Aug 2024 14:59:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1722635948; cv=none;
        d=google.com; s=arc-20160816;
        b=pUaYXI53aybMrwblEP8ikT/jf14znYFqICTK48kOIhAok1HP9N72lTe0SIju458Ffz
         Hw2nUbzEea85osDH5+tPI2RwH1l9eImCAXUPx8YdLMUSOUvlRCUy3gdwnhFZ2COp+EGi
         dVX62HyZF5Dw5W0/i1vdte0LpF8dXylxzZzIlVYRvuJfqZtlHm4tr2t2N41jAnzZHgBD
         RpcUUOz1lP4qoNWe843xz3AJ4XZvVSO7hBjZw++Zj+gqZt6ye8qphmmKg2hrYk6vTq0l
         d5RxWpzuQQvuurVg5K+k8/tr+uTnnxwkpGvmv36JJG0pMUXvT3DQ7txRSVe0kjDXfPM/
         yhEg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=F3F51moxGR/n8wRb57wqlai7X5/vu/jw9vN6G6Ie4bE=;
        fh=psWP3UCtCzzPEOUoUzVM9ZZK8adYsTeWDAKCd6L5Zok=;
        b=SieFRPmlgr8q0jaD3ZLCvEaadlh1GVxAHNxblAIgcMzw4k7Cr7fYjyyon05mNuyg+0
         tAYvBLrq2GMhpFUakRsfMFdR3+LBBEV6D1CNDgKHtczQ0FgI18GjPwoBRFFCwQeA/I4I
         QBfrx8Eb5HQJgr1kdnfSWDwk4uanLEvOeRfpmfwFutI73v87tOrhDX7KMECX9CFqX0bV
         3V+wWxsQwYSCxqbQushueIu0sYVQOIWcqClK523ZG1YX2V3gJOCyNYQMIsm+p33tz2wQ
         IYdVTpJxp/xkFWEnbTutePuT/kITK5s9RMDFEhGPJ9LNsT0brEdbCAudedwaf/5XzI9r
         KzDg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=nGyYuxEt;
       spf=pass (google.com: domain of keagan.mcclelland@gmail.com designates 2607:f8b0:4864:20::f2e as permitted sender) smtp.mailfrom=keagan.mcclelland@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com. [2607:f8b0:4864:20::f2e])
        by gmr-mx.google.com with ESMTPS id d9443c01a7336-1ff5904319dsi1323735ad.10.2024.08.02.14.59.08
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 02 Aug 2024 14:59:08 -0700 (PDT)
Received-SPF: pass (google.com: domain of keagan.mcclelland@gmail.com designates 2607:f8b0:4864:20::f2e as permitted sender) client-ip=2607:f8b0:4864:20::f2e;
Received: by mail-qv1-xf2e.google.com with SMTP id 6a1803df08f44-6b7a36f26f3so31994226d6.1
        for <bitcoindev@googlegroups.com>; Fri, 02 Aug 2024 14:59:07 -0700 (PDT)
X-Received: by 2002:a0c:e643:0:b0:6bb:8b7b:c2df with SMTP id
 6a1803df08f44-6bb91ea8140mr104771586d6.25.1722635947001; Fri, 02 Aug 2024
 14:59:07 -0700 (PDT)
MIME-Version: 1.0
References: <ZqyQtNEOZVgTRw2N@petertodd.org>
In-Reply-To: <ZqyQtNEOZVgTRw2N@petertodd.org>
From: Keagan McClelland <keagan.mcclelland@gmail.com>
Date: Fri, 2 Aug 2024 14:58:56 -0700
Message-ID: <CALeFGL1dLhdvdePzt5xdZxskcU6WJDJL_PSmO2u2Z1nKZCKMag@mail.gmail.com>
Subject: Re: [bitcoindev] Keyless Anchors Are Vulnerable To Replacement
 Cycling Attacks
To: Peter Todd <pete@petertodd.org>
Cc: bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="000000000000b2cf5e061eba6fb2"
X-Original-Sender: keagan.mcclelland@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=nGyYuxEt;       spf=pass
 (google.com: domain of keagan.mcclelland@gmail.com designates
 2607:f8b0:4864:20::f2e as permitted sender) smtp.mailfrom=keagan.mcclelland@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.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 (/)

--000000000000b2cf5e061eba6fb2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>  I think the existence of this additional type of replacement cycling
attack suggests that adding an optional rebroadcasting module to Bitcoin
Core
that would keep track of dropped transactions and re-add them to mempools
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 disk
space to keep track of dropped transactions like this.

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

Keags

On Fri, Aug 2, 2024 at 5:30=E2=80=AFAM Peter Todd <pete@petertodd.org> wrot=
e:

> This feels like someone should have published it before. But I can't find
> 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 exist=
s.
>
>
> tl;dr: _Anyone_ can do a replacement cycling attack on transactions where
> fees
> are paid via CPFP via keyless anchors and similar outputs that a
> third-party
> can double-spend. Secondly, for attackers who were already planning on
> making a
> transaction with a higher total fee and total fee-rate than the target,
> this
> attack is almost free.
>
>
> # The Attack
>
> Suppose that Alice has created a 2 transaction package consisting of
> low-fee or
> zero-fee transaction A, whose fees are CPFP paid via a keyless ephemeral
> anchor
> spent by transaction B. For B to pay fees, obviously it must spend a seco=
nd
> 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 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
> Mallory
> needed to mine B3 anyway, the only cost to this attack is the small chanc=
e
> 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,
> and A
> may be dropped from mempools depending on the circumstances.
>
>
> ## SIGHASH_ANYONECANPAY
>
> Obviously, a similar attack is possible against SIGHASH_ANYONECANPAY-usin=
g
> transactions, provided that _all_ signatures sign with
> SIGHASH_ANYONECANPAY.
>
>
> # Countermeasures
>
> As with other replacement cycling attacks, rebroadcasting A and B fixes t=
he
> issue. I think the existence of this additional type of replacement cycli=
ng
> attack suggests that adding an optional rebroadcasting module to Bitcoin
> Core
> that would keep track of dropped transactions and re-add them to mempools
> 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.
>
> Preventing the replacement of B2 with B3 is _not_ a viable countermeasure=
:
> if
> that replacement was prohibited, attackers could in turn exploit that rul=
e
> as a
> new form of transaction pinning!
>
>
> # Privacy
>
> The fact that rebroadcasting is a countermeasure is a privacy concern. Ea=
ch
> time a transaction is rebroadcast by the sender is a potential opportunit=
y
> to
> track the origin of a transaction. Again, having third parties
> rebroadcasting
> transactions altruistically would mitigate this privacy concern.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> --
> 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/ZqyQtNEOZVgTRw2N%40petertodd=
.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/CALeFGL1dLhdvdePzt5xdZxskcU6WJDJL_PSmO2u2Z1nKZCKMag%40mail.gmail=
.com.

--000000000000b2cf5e061eba6fb2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0=C2=A0I think the existence of this additional t=
ype of replacement cycling<br>attack suggests that adding an optional rebro=
adcasting module to Bitcoin Core<br>that would keep track of dropped transa=
ctions and re-add them to mempools when<br>they are again valid would make =
sense. This fixes all replacement cycling<br>attacks and there&#39;s probab=
ly lots of nodes who have the memory and/or disk<br>space to keep track of =
dropped transactions like this.<div><br></div><div>It kinda seems like this=
 might introduce a DOS vector to the nodes running this</div><div>module si=
nce you can keep cycling B3, B4 etc. and force the mempool to house</div><d=
iv>all of these until one of them gets mined. Further, it would cause the m=
empool<br></div><div>to have to decide which of these dead transactions get=
s priority upon the eviction</div><div>of the conflicting one. Is this some=
thing you&#39;ve given thought to? Admittedly I</div><div>haven&#39;t dived=
 deep into it.</div><div><br></div><div>Keags</div></div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Aug 2, 2024 at 5=
:30=E2=80=AFAM Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org">pete@pe=
tertodd.org</a>&gt; wrote:<br></div><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 before. But I c=
an&#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" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
<br>
-- <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%2Bunsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.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" =
target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/ZqyQtNEOZVgT=
Rw2N%40petertodd.org</a>.<br>
</blockquote></div>

<p></p>

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

--000000000000b2cf5e061eba6fb2--