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
Date: Sat, 24 Feb 2024 18:45:41 +0000 [thread overview]
Message-ID: <Zdo5VZIu3gU5wVQM@petertodd.org> (raw)
In-Reply-To: <CAFC_Vt5TSjGVk58o5G8aW4Jt4aJyDQvR9yE4eLvtB1t+m1jrYg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]
On Sat, Feb 24, 2024 at 02:55:26PM -0300, Nagaev Boris wrote:
> > I recently released a [prototype Libre Relay fork](https://github.com/petertodd/bitcoin/tree/libre-relay-v26.0) of Bitcoin Core v26.0, that among
> > other things, implements [Pure Replace-By-Fee-Rate](/2024/one-shot-replace-by-fee-rate#pure-replace-by-fee-rate) (RBFR)
> > with a 2x ratio. This means that transactions will be replaced if the fee-rate
> > of the new transaction is at least 2x higher than the old transaction(s), even
> > if the absolute fee is lower.
>
> I like the idea of pure replacement by fee rate, but I'm not sure
> about the 2x coefficient. I'm afraid it can result in overpaying.
>
> What is the purpose of the 2x coefficient? Is it needed to prevent DoS
> by continuously increasing feerate by a fraction of a percent? Isn't
> 1.1x enough to prevent this DoS vector? A rise from 100 sats/byte to
> 110 sats/byte is easier to bear, then a rise from 100 to 200,
> especially if the next block feerate is 105.
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
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.
Personally, I think 1.25 would be a reasonable ratio. But I wanted to release a
conservative version first to minimize the impact of DoS attacks.
--
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/Zdo5VZIu3gU5wVQM%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-02-24 18:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-24 15:58 Peter Todd
2024-02-24 17:55 ` Nagaev Boris
2024-02-24 18:45 ` Peter Todd [this message]
2024-02-24 20:54 ` Nagaev Boris
2024-02-24 22:25 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zdo5VZIu3gU5wVQM@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoindev@googlegroups.com \
--cc=bnagaev@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox