Delivery-date: Tue, 19 Mar 2024 05:57:27 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::130 as permitted sender) client-ip=2607:f8b0:4864:20::130;
MIME-Version: 1.0
References: <Zfg/6IZyA/iInyMx@petertodd.org>
In-Reply-To: <Zfg/6IZyA/iInyMx@petertodd.org>
From: Nagaev Boris <bnagaev@gmail.com>
Date: Tue, 19 Mar 2024 09:37:59 -0300
Message-ID: <CAFC_Vt7BE866DJGQ9EqA+DroEkDH+4U_72-RpCUfyrLHmtnZ1Q@mail.gmail.com>
Subject: Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
To: Peter Todd <pete@petertodd.org>
Cc: bitcoindev@googlegroups.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

Hi Peter,

On Mon, Mar 18, 2024 at 10:24=E2=80=AFAM Peter Todd <pete@petertodd.org> wr=
ote:
> Rule #6 creates a path dependency: the order in which replacement transac=
tions
> 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

--=20
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 e=
mail 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.g=
mail.com.