Delivery-date: Fri, 22 Mar 2024 17:39:34 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::12e as permitted sender) client-ip=2607:f8b0:4864:20::12e;
MIME-Version: 1.0
References: <Zfg/6IZyA/iInyMx@petertodd.org> <CAFC_Vt7BE866DJGQ9EqA+DroEkDH+4U_72-RpCUfyrLHmtnZ1Q@mail.gmail.com>
 <ZfmXNiscjatFOOCX@petertodd.org>
In-Reply-To: <ZfmXNiscjatFOOCX@petertodd.org>
From: Nagaev Boris <bnagaev@gmail.com>
Date: Fri, 22 Mar 2024 21:29:59 -0300
Message-ID: <CAFC_Vt5kHtRj+ypoxGKZUD1-NdSnbC9m=zwWnjVSTcROp7aLow@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

On Tue, Mar 19, 2024 at 10:46=E2=80=AFAM Peter Todd <pete@petertodd.org> wr=
ote:
>
> On Tue, Mar 19, 2024 at 09:37:59AM -0300, Nagaev Boris wrote:
> > Hi Peter,
> >
> > On Mon, Mar 18, 2024 at 10:24=E2=80=AFAM Peter Todd <pete@petertodd.org=
> wrote:
> > > Rule #6 creates a path dependency: the order in which replacement tra=
nsactions
> > > are received determines which transactions are ultimately accepted.
> >
> > I'd like to share my thoughts regarding RBFR rules and propose somethin=
g.
> >
> > 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.
>
> It's not really fair to say that "the proposed RBFR rule is also
> path-dependent". What you're describing is a property of Bitcoin Core's m=
empool
> in general, for all transaction acceptance rules. We've *always* had the
> property that two essentially identical transactions, differing only in a
> trivial way, will be accepted on a first seen basis. Achieving consensus
> requires bandwidth, and since you can generate an essentially infinite nu=
mber
> of almost identical transactions, you'll always be able to find cases wit=
h path
> dependency.
>
> > 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?
>
> I'd suggest that you should argue concretely *why* this is a good propert=
y. The
> RBF Rule #6 issue isn't strong evidence, as it's only related to a specif=
ic
> type of meaningful path dependency, where fees/size differ meaningfully. =
You're
> talking about all forms of path dependency, including trivial differences=
 where
> fees/size are the same and only a txid differs due to a trivial change.

I rethought it and I think I'm wrong. The proposed solution of
delaying and skipping won't fix the replacement attack, because the
preimage could be a skipped transaction, so the attacked node could
miss it.

For my proposal to work it should be changed to guarantee that any
transaction is spread to all the nodes eventually, i.e. no skipping.
This means broadcasting all transactions eventually. But this is
impossible to implement without creating DoS vectors either in
bandwidth or in memory (the later - in case transactions to be
broadcasted are accumulated in a buffer by a node).

--
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_Vt5kHtRj%2BypoxGKZUD1-NdSnbC9m%3DzwWnjVSTcROp7aLow%40mail.g=
mail.com.