Delivery-date: Thu, 28 Mar 2024 13:19:25 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 64.147.123.147 as permitted sender) client-ip=64.147.123.147;
Feedback-ID: i525146e8:Fastmail
Date: Thu, 28 Mar 2024 19:47:07 +0000
From: Peter Todd <pete@petertodd.org>
To: Antoine Riard <antoine.riard@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6
Message-ID: <ZgXJOxBsePn9VAKh@petertodd.org>
References: <Zfg/6IZyA/iInyMx@petertodd.org>
 <0a377ddb-b001-41ba-9208-27b3fa059bb5n@googlegroups.com>
 <ZgQZUOCc/dSjKMoL@petertodd.org>
 <CALZpt+GOCiwYdK4vfkODrT0Sx6HxCAuvhVqa1c5o3Xjy03OiAQ@mail.gmail.com>
 <ZgV+Rk0m4azlbRZP@petertodd.org>
 <CALZpt+H2B1pSbqNa9phxZMxHX+30AiDqX7TgiRjH4rtirLwb9g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="T7mF4jH14HklA4Ju"
Content-Disposition: inline
In-Reply-To: <CALZpt+H2B1pSbqNa9phxZMxHX+30AiDqX7TgiRjH4rtirLwb9g@mail.gmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--T7mF4jH14HklA4Ju
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

On Thu, Mar 28, 2024 at 07:13:38PM +0000, Antoine Riard wrote:
> > Modulo economic irrationalities with differently sized txs like the Rule
> #6
> > attack, the proof-of-UTXO is almost economically paid even when mempools
> are
> > partitioned because the bandwidth used by a given form of a transaction is
> > limited to the % of peers that relay it. Eg if I broadcast TxA to 50% of
> nodes,
> > and TxB to the other 50%, both spending the same txout, the total cost/KB
> used
> > in total would exactly the same... except that nodes have more than one
> peer.
> > This acts as an amplification fator to attacks depending on the exact
> topology
> > as bandwidth is wasted in proportion to the # of peers txs need to be
> broadcast
> > too. Basically, a fan-out factor.
> 
> > If the # of peers is reduced, the impact of this type of attack is also
> > reduced. Of course, a balance has to be maintained.
> 
> Sure, proof-of-UTXO is imperfectly economically charged, however I think
> you can
> re-use the same proof-of-UTXO for each subset of Sybilled transaction-relay
> peers.

Of course you can. That's the whole point of my scenario above: you can re-use
the proof-of-UTXO. But since nodes' mempools enforce anti-doublespending, the
tradeoff is less total nodes seeing each individual conflicting uses.

If, for example, all Bitcoin nodes were somehow peered in a perfect ring, with
each node having exactly two peers, the sum total bandwidth of using 2
conflicting proof-of-UTXOs (aka spending the UTXO), would be almost identical
to the sum total bandwidth of just using 1. The only additional bandwidth would
be the three to four nodes at the "edges" of the ring who saw the two different
conflicting versions.

With higher #'s of peers, the total maximum extra bandwidth used broadcasting
conflicts increases proportionally.

-- 
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/ZgXJOxBsePn9VAKh%40petertodd.org.

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmYFyTkACgkQLly11TVR
LzfDmQ//RryTFGHsDXK5eD1B8P5ppu7meD7rR2HpeKF+WNxVgv3xWZnsiAFrZCbX
5VStkRgmsGBmHcxZnDwWrEx+IxQMA6kZQvBajo3dyBU2jzxxsSXqfnLb/Ir+ASJV
GlXMLYF8pMvNW1QndLKSLYaLYqZyRszer0qVFlxmt4brH156mJO1CxDxMM/HvcC/
cfjE5FNCVjmRliUhjtkMY8jUzltW6naFPHnEB6yFAO4s8O6LFir1BlBNwBCYVzEa
ppv7cXSbaXa+97pdOj5JGg+Sz3A8d2srIxkVdLgOmd+55vwwiDSCFMzTLDGCdtXV
cU+ULYv5dwZpMMyF84sMfsR/gBrCWDbYfxkqCCZBOj2WgDyr5ejySi0SKXgyRXj/
Kvl75i8tdn0K6FzEhi0FRt3O+7AQSUkWma//iOQWxUU+1Tp+UbrP8AMY2zjJqrnA
sfZfYTZrvdgu8hfSU2mVeMubAdNtMax5J474nThxez7hQQiWcAw3d1rO+PlmzIve
ovc4l293YinrFblcuz1Vc8c8DJgtRXVrUoGnOzwabDQDLboMDjHRyluxIEAYoAVY
lKmbtbf6KQIemPVm+VrLKZKJYKJgB/iLe4sf9wRB/vZ0v1hNH6jTT+NyXkzsZCed
QJWokM/Fe9Zb3K2CgTZtXn5aMel6tUQbkjTOR6FH2KXOOLUmGZM=
=MFjf
-----END PGP SIGNATURE-----

--T7mF4jH14HklA4Ju--