path: root/ad/727c8d337f3879c153a72796cca7cd1452a28f

Return-Path: <pete@petertodd.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 93317C0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 17 Dec 2023 10:57:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 441B64011B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 17 Dec 2023 10:57:42 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 441B64011B
Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=messagingengine.com header.i=@messagingengine.com
 header.a=rsa-sha256 header.s=fm2 header.b=cUkWBR8K
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id h7eAuaSnHbrA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 17 Dec 2023 10:57:39 +0000 (UTC)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com
 [66.111.4.27])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 9744E400A6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 17 Dec 2023 10:57:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9744E400A6
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
 by mailout.nyi.internal (Postfix) with ESMTP id B8FAC5C00C7;
 Sun, 17 Dec 2023 05:57:36 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute4.internal (MEProxy); Sun, 17 Dec 2023 05:57:36 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-type:content-type:date:date
 :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
 :message-id:mime-version:references:reply-to:subject:subject:to
 :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
 fm2; t=1702810656; x=1702897056; bh=Md6CG+coHwkze7chXAaET9pBUueF
 DJBAvY/LfamD+cY=; b=cUkWBR8K9gNt5CjFgIx45hxGbpwZrLo73tWdwbocl7za
 D23kZ9wlllkRsezpyhFBtFhK3QOo9IXYvBj5jHa1mMtgw7I6zh3DdR5BxX7yXC1c
 RA2i2uTs0ny39gVWaLjy9WlGSHyROATIqMpUJ0joBYIhltl1rsnvF90q3GVCleIl
 YKNBij0uRJlrt9H3aXAGb7fZMvjbq/EqhTX7tcmnoOBO4F4Awhq11SoqnASkulW+
 JCxZ5iYqx86yucNs/EzyPI0CN2ayGmEj7ND1+rzSLxrvh6LqAwQ2ljNNkde/TbZI
 Od/5/aLsaRY+fC+KdRwgpQE2+8cFsF/alXNB2LuFZA==
X-ME-Sender: <xms:INR-ZS15WB2IBbWOa3rX1i_T-fhbt-Tm1fwAIi0b8TfT1wpke2r76g>
 <xme:INR-ZVEi_P5GyYoW3d0v8Jkk0R6f8owh2LSqyyciNtHK_h6IIgklcG__0jSwSkVSZ
 03Azq01oRKQ7OQOJaY>
X-ME-Received: <xmr:INR-Za66O_B8gAIjvAdYh-LrnP2v75t4J4YTcEzGQJyrGGRPlf_xZA0bL8JtbMAVlBtF4RHZboc38gwIbrTPJPqLBOrfjN3O>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvddtiedgvddtucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgv
 rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth
 gvrhhnpedttdegtdffteeukeffhfffkeekiefhteduvdetjeeujeffgeevgefhudetjefh
 veenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhpvghtvghrthhouggurdhorhhgne
 cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgv
 sehpvghtvghrthhouggurdhorhhg
X-ME-Proxy: <xmx:INR-ZT08cjTiQduHS710hLpCTNthnc6Ab5q6Mk_SYwleRJ-_HTo03A>
 <xmx:INR-ZVE4QqF7mgtQm5y6WBCqljsV4G7EAcyWYCOr4fZ4NFTZ2x1WTQ>
 <xmx:INR-Zc9cXdGLpFjhsNDH6DH1j5A06CEEhpSnyrhbZBuEYcyvKEEtqQ>
 <xmx:INR-ZVDtQNqhXnnoqfgn3AFcG0FG_ebk1h8rJuJmchcCX-QFxtXlNw>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 17 Dec 2023 05:57:35 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
 id 4D7725F81D; Sun, 17 Dec 2023 10:57:32 +0000 (UTC)
Date: Sun, 17 Dec 2023 10:57:32 +0000
From: Peter Todd <pete@petertodd.org>
To: Antoine Riard <antoine.riard@gmail.com>
Message-ID: <ZX7UHOaUKk/+jbS1@petertodd.org>
References: <ZXQ8uFLoNlSksalX@petertodd.org>
 <CALZpt+HLoomKZn=QsBZ-4M-WSDzjEA_p1nzk9N=+R4MveeAOFQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="75lbTpNkkMvh6s4X"
Content-Disposition: inline
In-Reply-To: <CALZpt+HLoomKZn=QsBZ-4M-WSDzjEA_p1nzk9N=+R4MveeAOFQ@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement
 Cycling Mitigation
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Dec 2023 10:57:42 -0000


--75lbTpNkkMvh6s4X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 15, 2023 at 10:29:22PM +0000, Antoine Riard wrote:
> Hi Peter,
>=20
> > Altruistic third parties can partially mitigate replacement cycling(1)
> attacks
> > by simply rebroadcasting the replaced transactions once the replacement
> cycle
> > completes. Since the replaced transaction is in fact fully valid, and t=
he
> > "cost" of broadcasting it has been paid by the replacement transactions,
> it can
> > be rebroadcast by anyone at all, and will propagate in a similar way to
> when it
> > was initially propagated. Actually implementing this simply requires co=
de
> to be
> > written to keep track of all replaced transactions, and detect
> opportunities to
> > rebroadcast transactions that have since become valid again. Since any
> > interested third party can do this, the memory/disk space requirements =
of
> > keeping track of these replacements aren't important; normal nodes can
> continue
> > to operate exactly as they have before.
>=20
> I think there is an alternative to altruistic and periodic rebroadcasting
> still solving replacement cycling at the transaction-relay level, namely
> introducing a local replacement cache.
>=20
> https://github.com/bitcoin/bitcoin/issues/28699
>=20
> One would keep in bounded memory a list of all seen transactions, which
> have entered our mempool at least once at current mempool min fee.

Obviously a local replacement cache is a possibility. The whole point of my
email is to show that a local replacement cache isn't necessarily needed, as
any alturistic party can implement that cache for all nodes.

> For the full-nodes which cannot afford extensive storage in face of
> medium-liquidity capable attackers, could imagine replacement cache nodes
> entering into periodic altruistic rebroadcast. This would introduce a
> tiered hierarchy of full-nodes participating in transaction-relay. I think
> such topology would be more frail in face of any sybil attack or scarce
> inbound slots connections malicious squatting.
>=20
> The altruistic rebroadcasting default rate could be also a source of
> amplification attacks, where there is a discrepancy between the feerate of
> the rebroadcast traffic and the current dynamic mempool min fee of the
> majority of network mempools. As such wasting bandwidth for everyone.

1) That is trivially avoided by only broadcasting txs that meet the local
mempool min fee, plus some buffer. There's no point to broadcasting txs that
aren't going to get mined any time soon.

2) BIP-133 feefilter avoids this as well, as Bitcoin Core uses the feefilter
P2P message to tell peers not to send transactions below a threshold fee ra=
te.

https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki

> Assuming some medium-liquidity or high-liquidity attackers might reveal a=
ny
> mitigation as insufficient, as an unbounded number of replacement
> transactions might be issued from a very limited number of UTXOs, all
> concurrent spends. In the context of multi-party time-sensitive protocol,
> the highest feerate spend of an "honest" counterparty might fall under the
> lowest concurrent replacement spend of a malicious counterparty, occupying
> all the additional replacement cache storage.

Did you actually read my email? I worked out the budget required in a
reasonable worst case scenario:

> > Suppose the DoS attacker has a budget equal to 50% of the total block
> > reward.
> > That means they can spend 3.125 BTC / 10 minutes, or 520,833sats/s.
> >
> >     520,833 sats/s
> >     -------------- =3D 2,083,332 bytes / s
> >     0.25 sats/byte
> >
> > Even in this absurd case, storing a one day worth of replacements would
> > require
> > just 172GB of storage. 256GB of RAM costs well under $1000 these days,
> > making
> > altruistic rebroadcasting a service that could be provided to the netwo=
rk
> > for
> > just a few thousand dollars worth of hardware even in this absurd case.

Here, we're talking about an attacker that has financial resources high eno=
ugh
to possibly do 51% attacks. And even in that scenario, storing the entire
replacement database in RAM costs under $1000

The reality is such an attack would probably be limited by P2P bandwidth, n=
ot
financial resources, as 2MB/s of tx traffic would likely leave mempools in =
an
somewhat inconsistent state across the network due to bandwidth limitations.
And that is *regardless* of whether or not anyone implements alturistic tx
broadcasting.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--75lbTpNkkMvh6s4X
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmV+1BEACgkQLly11TVR
LzcV5A/+MXwsMrh0rrDGZ/RSxkARZhO9IqD4EF6j2ayuC0zLI0OToiu99jWrKps+
kp1pplmn2e3z+LTxbLzwOqWRvo+RhQyCQMqT8lJ5/Lq3IdQOdTnkpZlJ7OtEJLur
z55XI9iy6fkd0qlPg+pR4gs6hAaYMItn/zcz1ujm4GgFBZ1kjEZZsOg52x7l+mMZ
vjjrWhvp1QdnLNI3I3pFWP7JjBdIRTQydpnAbRJUd3laVN+zXEAHG0nklGLSWdN3
iKDk2Mlw7mM2j9ihOGG289pPUK/Q7dvhUXub1dP7G5v67PgEfF1nFHszJNJdH3dd
q/7x8zqFqyf0eucC6vh9ncGH2RiaKiy4hHKxLBAcQQ1QI5Sj1E/gt91y7mQwk+96
Z93LGHtE3VK9kXrPI0sdU4uLBe9cb21B82BqS7UQPV2Jf/MTK7QJEgAVpBbWLX1E
VugKifzpmevydyzaCh76w/kQkZEdRkcIoPCTopO/2FzopDtfUQscLKiTvHvYOxnv
ZDIuLvBrYV/uREKAOqS0lK3gsGlxAhNUob59vpnrXueDDRvHKhAVoBpRui4Tq3WF
yKosJOPesj6lwJBQcrQdRRv6mUHbaPjyDqs/WY/oY2AtblDsuNbtY7SIq7lTL5yt
aKPGxPHe2PcZjvKCq/K4+T0odCPK6mZlpbrZhpS/UAoilmkzADE=
=cNoa
-----END PGP SIGNATURE-----

--75lbTpNkkMvh6s4X--