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: Fri, 22 Mar 2024 21:29:59 -0300 [thread overview]
Message-ID: <CAFC_Vt5kHtRj+ypoxGKZUD1-NdSnbC9m=zwWnjVSTcROp7aLow@mail.gmail.com> (raw)
In-Reply-To: <ZfmXNiscjatFOOCX@petertodd.org>
On Tue, Mar 19, 2024 at 10:46 AM Peter Todd <pete@petertodd•org> wrote:
>
> On Tue, Mar 19, 2024 at 09:37:59AM -0300, Nagaev Boris wrote:
> > 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.
>
> 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 mempool
> 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 number
> of almost identical transactions, you'll always be able to find cases with 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 property. The
> RBF Rule #6 issue isn't strong evidence, as it's only related to a specific
> 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
--
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_Vt5kHtRj%2BypoxGKZUD1-NdSnbC9m%3DzwWnjVSTcROp7aLow%40mail.gmail.com.
next prev parent reply other threads:[~2024-03-23 0:39 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
2024-03-19 13:46 ` Peter Todd
2024-03-23 0:29 ` Nagaev Boris [this message]
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_Vt5kHtRj+ypoxGKZUD1-NdSnbC9m=zwWnjVSTcROp7aLow@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