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.