Feedback-ID: i525146e8:Fastmail
Date: Wed, 2 Nov 2022 10:33:51 -0400
From: Peter Todd <pete@petertodd.org>
To: Greg Sanders <gsanders87@gmail.com>
Message-ID: <Y2J/zyeTh/rwekqe@petertodd.org>
References: <CALZpt+GZAd-vYMzUMicg0c9OyyWExtT5EH61Hms6NNOM19ddZA@mail.gmail.com>
 <Y2J40/Cd40fUlFjj@petertodd.org>
 <CAB3F3DsA3kNutwXGwamyyEgJN65rJt-0ks-ytuXP7jwjsjr8ug@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="zyKkyq1H45Ubztc9"
Content-Disposition: inline
In-Reply-To: <CAB3F3DsA3kNutwXGwamyyEgJN65rJt-0ks-ytuXP7jwjsjr8ug@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Solving Multi-Party Flows Pinning with Opt-in
 Full-RBF Spent-nVersion Signaling
Precedence: list


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

On Wed, Nov 02, 2022 at 10:19:00AM -0400, Greg Sanders wrote:
> Sorry, I forgot one point which is pertinent to this conversation.
>=20
> *Even with* fullrbf-everywhere and V3, pinning via rule#3 and rule#5 are
> still an issue in coinjoin scenarios.
>=20
> Each coinjoin adversary can double-spend their coin to either full package
> weight(101kvb),
> or give 24 descendants, which means you quickly pay out the nose in rule#3

=2E..and the attacker also pays out the nose if they're exploiting rule #3.

> or are excluded
> from RBFing it if you have 4+ greifers in your coinjoin violating rule#5.
>=20
> If we instead narrowed this policy to marking a transaction output as
> opt-in to V3, it gets a bit more interesting. *Unfortunately,
> double-spending counterparties can still cause rule#3 pain, one 100kvb
> package of junk per peer,* but rule#5 violations is at least contained to
> coinjoins with ~50 peers(assuming two transactions booted per input
> double-spent, which would be the V3 max bumped per input).

There's no hard technical reason for rule #5 to even exist. It's simply a
conservative DoS limit to avoid having to do "too much" computation when
processing a replacement in some replacement implementations. We shouldn't
assume it will always exist. And like rule #3 pinning, exploiting it costs
money.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmNif80ACgkQLly11TVR
LzdNhw//bgG4Z+4AAzMd/baM9GdCGB3gjlGGwMCYIS11oWdCpnus9+ldUI75fJPg
VRdtFvJQMkGAvKRjz9m3r1TnJ5eyZzCcGUKcbXrptqUYGOGGVpJrtrBREfu+zgAx
MfmTgIoIU2wHaiMscRJ1mlnfP0aqxR+ZkOopM4ew61KE16KpTv1lFv7aVyRAUdrn
b/8pB9fBfyn0E8bWznXZynhx78qOPWEvhxIrlZj91aDvrvNrhmYyb6AnTKQTZQrD
tByRDgUqPrBU5+Z0KZrohYTYFKgwigo8rtVp4mUiKl/YER1zDp2pQBLDYt4IQYQI
g7AD4txH2lF0rqKhAGtoG2McJiA0HzwQ0JZZu46bZcYVljO5tDfQjxtmAk8m7CCj
8SYgUbqGdjU9KGZFzuhZckXpmYbjGJaXDe8x/RdSimMoKYhybbrW8FVnZEHILiCv
0E6PZEa+G1rPYQpUpiz/DZne0O0P90o4af65DgYP8mXES72Hn1pGHJZdPUsJyfp2
p6rWRbGMOo+v4Pqy6TiPBatrsoOZKux7NEc9K5Tex4+tqoadaJN5mTzSE1Sj/7eE
ZEo5iXMRfZDTF8lWVX1YjD7Ku9IbtUJCMqucD2RXybK2z8wazHbDP0sEDv6/2hjt
a7KETeomonJEfC5ZrNZiEvxJrEtQOSL7cfsm+f9JZXXA18aKj4Q=
=H8p2
-----END PGP SIGNATURE-----

--zyKkyq1H45Ubztc9--