Delivery-date: Sat, 24 Feb 2024 14:54:08 -0800
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.158 as permitted sender) client-ip=103.168.172.158;
Feedback-ID: i525146e8:Fastmail
Date: Sat, 24 Feb 2024 22:25:56 +0000
From: Peter Todd <pete@petertodd.org>
To: Nagaev Boris <bnagaev@gmail.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Over Half of Replace-by-Fee-Rate Replacements Are Mined
Message-ID: <Zdps9GJ+59hsek3B@petertodd.org>
References: <ZdoSP+Z/f17TYOD+@petertodd.org>
 <CAFC_Vt5TSjGVk58o5G8aW4Jt4aJyDQvR9yE4eLvtB1t+m1jrYg@mail.gmail.com>
 <Zdo5VZIu3gU5wVQM@petertodd.org>
 <CAFC_Vt4icK4RMm2UgqsgoV2Qude7e8ThL+3Hm+9DXfB0BgC6ZQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="JwyJ8CUR0pks+dDp"
Content-Disposition: inline
In-Reply-To: <CAFC_Vt4icK4RMm2UgqsgoV2Qude7e8ThL+3Hm+9DXfB0BgC6ZQ@mail.gmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--JwyJ8CUR0pks+dDp
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

On Sat, Feb 24, 2024 at 05:54:52PM -0300, Nagaev Boris wrote:
> > The coefficient is a trade-off between overpaying and DoS attack cost. The
> > smaller the coefficient, the more replacements that can be done:
> >
> > 2^10    = 1024
> > 1.5^10  = 58
> > 1.25^10 = 9.3
> > 1.1^10  = 2.6
> 
> Very interesting!
> 
> To assess the number of DoS replacements, given RBFR is implemented
> with coefficient K, we need to know the following two numbers,
> available on mempool.space front page:
> 
>  - Purging feerate (P)
>  - Next block feerate (N)
> 
> For an attacker, to cause the most number of replacements, it is
> rational to first introduce a tx with fee rate just above purging
> feerate and then increase its feerate by K times until it reaches next
> block feerate (N).

Note that next block feerate isn't actually the limit in the Libre Relay
implementation. It's memoryless, and does not depend on overall mempool
conditions, so you can continue to RBFR replace even beyond the next block
feerate.

Of course, if you do that you're spending a heck of a lot of money that could
be used on a cheaper attack.

> Another piece of data which would be very valuable are N and R for
> historical RBF events. If K is set to median N / R, then RBFR would
> cost nothing to the average legitimate user and cost something to an
> attacker, which is a good thing.

Absolute maximum next block fee rate historically has been <1000sat/vB;
absolute minimum has been 1sat/vB. Just using those numbers for sake of
conservativism is probably fine:

1.25^32 ~= 1010
1.15^50 ~= 1084

After all, you're putting up a *lot* of money for the privilege of using
relatively little bandwidth at anything but relatively small fee-rates. As per
my prior analysis of this topic, it's probably cheaper to just DoS attack
public nodes directly, with similarish effectiveness:

https://petertodd.org/2024/one-shot-replace-by-fee-rate#denial-of-service-attacks

> > I picked 2x for the prototype because it's:
> >
> > 1) A safe default that makes DoS attacks _very_ expensive.
> > 2) Low enough that the primary purpose of preventing pinning attacks still
> >    works.
> > 3) High enough to be clearly incentive compatible for miners.
> > 4) A ratio that's easy to implement with addition.
> >
> > The last reason is kinda funny... CFeeRate in Bitcoin Core v26.0 doesn't
> > support multiplication or division operations. So I implemented the 2x ratio by
> > just adding a fee-rate to itself.
> 
> Yeah, it is funny :-)
> 
> By the way, K=1.25 is also easy to implement using just additions:
> 
> bool enough_increase(CFeeRate oldrate, newrate) {
>   auto oldx2 = oldrate + oldrate;
>   auto oldx5 = oldx2 + oldx2 + oldrate;
>   auto newx2 = newrate + newrate;
>   auto newx4 = newx2 + newx2;
>   return newx4 >= oldx5;
> }

lololol

> Also CFeeRate supports integer multiplication, so it can be simplified as:
> 
> bool enough_increase(CFeeRate oldrate, newrate) {
>   return (4 * newrate) >= (5 * oldrate);
> }

Check git blame: that's actually new! The v26.0 code base doesn't have that
patch. Not sure if v26.1 will have it either. Of course, easy to just
cherry-pick it at this point.

-- 
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/Zdps9GJ%2B59hsek3B%40petertodd.org.

--JwyJ8CUR0pks+dDp
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmXabPIACgkQLly11TVR
LzeX8g/+KfPabWL6gCGZwDeNApSwTwWHt0IrjdPL6CE2PVRF6oNzwRO0wCQ37RJW
9MKuUu2IQFER+Go5XAfZKKoPZ5yYZEqTiUkQGFmRiZi7butHancuxBeiHYIzRpzW
zJ+AYvzRehrSP6XBjTGC4zIUClUcmgRtbQGOHMvPLoj1RQvcBvM8RTOp3JL8e7x9
If07/FcEFZwFFSqoyGvF/9cRkLpjAOv9La++iiFwgrcry0V1mNc0GI906yNiAFP3
kvcLN70JZnGxbf020tnZ+nu4gqJpCQ5rvtcg/ATAvB6ewR6p+pDJc2LbBPmgsMRM
Pixr9KEIDLRMleCCjjhJj+sua7XmZ7X9mwtrRF3lVqf+B6O9iDk8E6XnxEbbFfZQ
g4asZLDkRVaQYSl/TL6qhvDpKIc2KPWF4Vj2Pw8OEsGfBGoUufIS8sNC9lkrwW3E
uG3giJz+J8OYe+qidkTYBhnfN7L2FACvCfaKzs+ratEg2q7mftLbC2Uz3TLLA8gZ
BABVm7QYpsXye5QNhgRKzylwCq35+yuCwbuR0MzFaHjrrJFuDnlRWI+/9zDkRtVB
fKUxiHhV1d3u9XI81S8OMoCB1f+siUSK1bS3Vo1Z4K85/yL6ozM1qTDxUUQ5d5nj
bAK2d29cg29FsHQhvGL5bPOToyEVUVvgJpbpOR/DC8FUjLs3WfM=
=Bmgz
-----END PGP SIGNATURE-----

--JwyJ8CUR0pks+dDp--