Delivery-date: Sun, 21 Jul 2024 13:48:53 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.150 as permitted sender) client-ip=103.168.172.150;
Feedback-ID: i525146e8:Fastmail
Date: Sun, 21 Jul 2024 20:25:25 +0000
From: Peter Todd <pete@petertodd.org>
To: "David A. Harding" <dave@dtrt.org>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack
 of Full-RBF In Core
Message-ID: <Zp1utYduhnWf4oA4@petertodd.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
 <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
 <ZpvRvRybauFFnhQV@petertodd.org>
 <d57a02a84e756dbda03161c9034b9231@dtrt.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="f6QbCljwwUF5QVIU"
Content-Disposition: inline
In-Reply-To: <d57a02a84e756dbda03161c9034b9231@dtrt.org>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--f6QbCljwwUF5QVIU
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 21, 2024 at 05:35:31AM -1000, David A. Harding wrote:
> On 2024-07-20 05:03, Peter Todd wrote:
> > What other "free" relay attacks can you think of that were fixed?
>=20
> The two you mention were the two I had in mind.

Right. So in the entire history of Core, we have two quite ridiculous free
relay attacks that got fixed, and we *added* a significant free-relay
vulnerability by adding mempool expiration. We also added a free-relay
vulnerability, and a fill-and-dump vulnerability, with the mempool size lim=
it.

That's not evidence that Core actually cares much about "free" relay.

> > Did you actually read my One-Shot RBFR proposal?
>=20
> Yes.  It didn't provide any examples of RBFr free relay and I wanted to
> see whether a basic RBFr free relay attack would use significantly more,
> significantly less, or about the same amount of bandwidth per dollar
> spent as other free relay attacks.  My conclusion is that it's about the
> same.

Good. So you basically agree with me that RBFR does _not_ significantly cha=
nge
the status quo.

I'll respond to the specifics of your RBFR analysis separately; it does *no=
t*
apply to one-shot RBFR.

> > Weak blocks are not a solution to any of the "free" relay attacks I've
> > disclosed and your source does not claim that they are a "free" relay
> > solution.
>=20
> It does not explicitly say that, but it does say: "bonus use-cases:
> =E2=80=9CForcible insertion=E2=80=9D of transactions that are incentive-c=
ompatible but
> violate anti-DoS rules".
>=20
> For example, in some of the scenarios you describe, the attacker sends
> an appealing transaction to miners and then sends less appealing
> versions of that transaction to relay nodes.  If the appealing
> transaction enters the top mempool and gets included in a weak block,
> relay nodes will stop relaying less appealing variations minutes to
> hours before they otherwise would.

Yes, "minutes to hours". Transactions relay on the order of seconds to tens=
 of
seconds. Weak blocks simply aren't relevant.

Also, the attacks I've described are ones that can be pulled off by having =
a
tiny minority of hash power mine a double spend. Weak blocks don't help you
there, as that tiny minority isn't likely to even find a weak block.

> Weak blocks also provide a decentralized DoS-resistant mechanism for
> voluntarily communicating all sorts of information from miners to other
> miners and relay nodes.  That makes them an excellent tool for resolving
> any attack that depends on miners and relay nodes having a divergent set
> of transactions.

For weak blocks to be a solution, you at minimum need to take away the abil=
ity
of miners to choose what transactions they mine. For example, consider the
scenario where you do a "free" relay attack by broadcasting transactions th=
at
OCEAN rejects, and then double-spending them via OCEAN _after_ the transact=
ions
have been broadcast. Equally, you'd need to take away the ability of RBFR
miners to do the revenue maximizing thing: mining RBFR replacements.

I'll also second Antoine Riard's objections to this class of idea in genera=
l:
you're really proposing a secondary pseudo-consensus mechanism to solve the
problems in your first pseud-consensus mechanism.

> > 1) Have you've read my One Shot RBFR proposal? In particular, my
> > analysis of DoS attacks *including* existing DoS attacks like
> > simultaneous broadcast.
> >=20
> > 2) Do you agree or disagree with me that these existing DoS attacks
> > are real?
>=20
> Yes, I've read your proposal, and I agree those attacks are plausible.
> In my mind, the major difference between those free relay attacks
> and RBFR free relay attacks is how solvable they are.
>=20
> I think it's easy to sketch a significant mitigation to all free relay
> attacks (including RBFR):
>=20
> - Reduce the maximum size of both relayable transactions and in-mempool
>   packages, e.g. from 100,000 vbytes to 1,000 vbytes.
>=20
> - Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB.
>=20
> - Increase the default mempool feerate floor, e.g. from e.g. from 1
>   sat/vb to 100 sat/vb.
>=20
> That would break relay of many existing presigned transactions,
> potentially leading to money loss, and would break other existing
> usecases, not to mention introduce other problems.  However, I think
> it's sufficient to prove that a mitigation to free relay is possible
> without rendering the network unusable.

The irony here is you've almost described a _good_ mitigation to "free" rel=
ay
attacks: just reduce the size of the default mempool. A big reason why we h=
ave
"free" relay attacks right now is because we allow transactions to be broad=
cast
that are uneconomical to mine; if you limit transaction broadcast to
transactions that are economical to mine in the near future, relay is more
expensive.

For miners, you can make a decent argument that they want to have on-hand a=
 big
backlog of transactions in case mempools empty out; in my conversations wit=
h
miners almost all of them claim they run with much larger than default memp=
ools
(eg >1GB). I've even discussed mempool emptying attacks and RBFR in this
context with miners: they didn't think they were an issue as replacing thei=
r
mempools was absurdly expensive.

Fee estimation of course can make use of knowing what backlog of transactio=
ns
exist. But I'm sure only a small minority of nodes do fee estimation.

A variant of this solution would be to just pick the minimum relay fee to b=
e
some number N blocks worth of transactions "back" from the highest fee-rate=
 tip
of the mempool. Obviously, this will be easier to implement with a cluster
mempool, and requires package relay for the CPFP case.

> Of course, an ideal solution wouldn't require placing any additional
> constraints on mempool policy.  For the case of free relay due to
> divergent mempool policies, maybe it's something that could be done with
> transaction set reconciliation (~erlay), functions for allowing

Erlay (and transaction set reconciliation in general) does not help you
reconcile conflicting transactions. It simply lets you efficiently learn ab=
out
the total set of known transactions. Notice how the Erlay is based on WTXID=
s,
and the BIP doesn't even talk about dealing with conflicts.

> independent nodes to come to consistent conclusions about the best
> revenue set of transactions (~cluster mempool),

That's quite irrelevant as RBFR _is_ the highest revenue policy in lots of
situations. That's one reason why in my discussions with miners/pools, they=
're
interested in implementing it (mining pools have very low profit margins, s=
o
every cent counts, and RBFR replacements are reasonably common already). Mi=
ning
pools implemented full-RBF against the wishes of Core for the same reason:
full-RBF earns you more revenue, and I made it easy to implement.

Implementing one-shot RBFR is probably going to be quite a bit cleaner with
cluster mempools, as it'll provide a nice way to rapidly determine what the
minimum economic fee-rate is to get into the next (N) blocks. (though you c=
an
do this in a less clean way by just periodically assembling a trial block a=
nd
recording the value, or using the fee estimation code)

Finally, why are clusters even relevant to "free" relay? Most "free" relay
attacks don't even need transaction packages. The really boring and unsolva=
ble
"free" relay attack of simply broadcasting large transactions that conflict
with small ones is done with single transaction packages.

> P2P relay of non-obvious
> cluster linearizations[1], and miners voluntarily committing to their
> mempool contents in candidate blocks and P2P relaying those commitments
> in weak blocks.

As I explained above, weak blocks is not a "free" relay solution.

> Innovations like that don't work for RBFR.  If mempool policy is kept
> the same, free relay attacks with RBFR remain equally effective no
> matter what mechanisms we implement to improve preconsensus consistency.

I could also argue that magic ponies will solve "free" relay. We have to we=
ight
that hope with the likelyhood it will happen; none of the technical
advancements you have mentioned even come close.


Anyway, I'll reply to the rest of your other email separately.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.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/Zp1utYduhnWf4oA4%40petertodd.org.

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmadbqwACgkQLly11TVR
LzfEuA//Vua35mgw1JMzh3drOYzEdP/59EpLDMGmcAsfNBoYfM+oEKsCpgtbv71K
u1XF1C83DonGutMHnPVzRbQiQ7fx6MBI8gaY+5hU4XY9hyBBsWhSnXW3c+UVvEj6
pvhsvU+ceB5DCsNnGVNHssxKw8XIGMI3+RZIqC+l9NsjXn6xe7296DUgE1p0tcR/
SS0krPd+hoFVFBiEjQMopDEjHhmFOznIJlkNmYnfMT8nhVCgGmZBsVEi5+c1b0LL
WbZpaoWqXdKbr0mZ3Wsr0nGnkXhvQme5bBe1nOBhSMexcpIEC1686Y0MIcXMWzsJ
S2U3KuUHn9i56RFGJ79OIxn5vrbXOBmxFcB3gDxgn7hnnGX3j+es2ZKoHinwTl97
yLanngdwQc8P+uU70K9ZgAoDh9Iu3BNbvAD0Rs3qFaHG+kAOZQBfnHRUXizfwGCn
EvasTpTPNQvtz5jnKe1dI9Z8fyxN5YKUjC7fagyzXrXtfOfLQOb6lCiVTTdyn1h8
5S/eN6v5X3TZ7aTdflOYcMIy8p2vlLjb6urW/afsX6e2Sv65AoRX81EdXTj6AHXf
wbfOZikjgshWediIHVNufZdlW438RAhnJIgpzg5XCqzWZmQgRIlWpreinNHyobDr
oQ/UrXSJNbFOKgoCwKmYfPFb9TUGz6sOvCosBrjXzBN7xUcXwm0=
=V5E8
-----END PGP SIGNATURE-----

--f6QbCljwwUF5QVIU--