From: Nagaev Boris <bnagaev@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
Date: Tue, 19 Mar 2024 09:37:59 -0300 [thread overview]
Message-ID: <CAFC_Vt7BE866DJGQ9EqA+DroEkDH+4U_72-RpCUfyrLHmtnZ1Q@mail.gmail.com> (raw)
In-Reply-To: <Zfg/6IZyA/iInyMx@petertodd.org>
Hi Peter,
On Mon, Mar 18, 2024 at 10:24 AM Peter Todd <pete@petertodd•org> wrote:
> Rule #6 creates a path dependency: the order in which replacement transactions
> are received determines which transactions are ultimately accepted.
I'd like to share my thoughts regarding RBFR rules and propose something.
The proposed RBFR rule is also path-dependent. Two transactions can
conflict with each other, but their fee rates can be too close for one
of them to eliminate the other from nodes' mempools. The first
transaction a node sees is kept in its mempool.
Is it possible to have a rule that is completely path-independent? The
eviction rules are path-independent iff, for each pair of conflicting
transactions A and B, it is always known which of them should be
preferred over the other, and this relation is transitive. Having such
a property would be very beneficial in preventing any attacks on the
mempool. This property of the mempool can also be seen as the eventual
consistency of all the mempools of the nodes. A good property, isn't
it?
How can we design such a rule system?
1. It must align with miners' incentives; otherwise, it simply won't work.
2. And it must not open the door for DoS attacks on the mempool.
The naive approach satisfying the first requirement is a simple rule
saying "the higher the fee rate, the more preferential is the
transaction." However it does not specify what to do with two
transactions of the same fee rate and also doesn't prevent DoS
attacks. The former is easy to fix, e.g. preferring the transaction
with lower txid. (Must be formally proven though.) Let's discuss the
latter, which is a stumbling stone here.
Traditionally, the way of preventing DoS was to reject some
transactions and to stop their broadcasting at this node. What about
deprioritizing them instead? Make two priority queues of transactions
in the node: (1) to process incoming transactions and (2) to
broadcast. When a transaction is double-spent, it is deprioritized in
both queues. If an attacker sends many double-spending transactions to
DoS the mempool, not all of them are broadcast further because by the
time a transaction is ready to be broadcast, its newer version has
already evicted it; the first one is not yet broadcasted. So a node
broadcasts fewer transactions than it receives, which reduces the DoS
effect. And still, the whole system is eventually consistent; just
spammers get their transactions spread slower.
What are your thoughts on this scheme?
--
Best regards,
Boris Nagaev
--
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/CAFC_Vt7BE866DJGQ9EqA%2BDroEkDH%2B4U_72-RpCUfyrLHmtnZ1Q%40mail.gmail.com.
next prev parent reply other threads:[~2024-03-19 12:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 13:21 Peter Todd
2024-03-19 12:37 ` Nagaev Boris [this message]
2024-03-19 13:46 ` Peter Todd
2024-03-23 0:29 ` Nagaev Boris
2024-03-22 23:18 ` [bitcoindev] " Antoine Riard
2024-03-27 13:04 ` Peter Todd
2024-03-27 19:17 ` Antoine Riard
2024-03-28 14:27 ` Peter Todd
2024-03-28 15:20 ` Peter Todd
2024-03-28 19:13 ` Antoine Riard
2024-03-28 19:47 ` Peter Todd
2024-03-29 20:48 ` Antoine Riard
2024-03-26 18:36 ` [bitcoindev] " David A. Harding
2024-03-27 6:27 ` Antoine Riard
2024-03-27 12:54 ` Peter Todd
2024-03-27 17:18 David A. Harding
2024-03-27 18:04 ` Peter Todd
2024-03-27 19:50 ` David A. Harding
2024-03-27 20:30 ` Peter Todd
2024-03-27 22:05 ` Steve Lee
2024-03-28 18:34 ` Antoine Riard
2024-03-28 19:16 ` 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=CAFC_Vt7BE866DJGQ9EqA+DroEkDH+4U_72-RpCUfyrLHmtnZ1Q@mail.gmail.com \
--to=bnagaev@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=pete@petertodd$(echo .)org \
/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