From: Peter Todd <pete@petertodd•org>
To: Antoine Riard <antoine.riard@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6
Date: Thu, 28 Mar 2024 19:47:07 +0000 [thread overview]
Message-ID: <ZgXJOxBsePn9VAKh@petertodd.org> (raw)
In-Reply-To: <CALZpt+H2B1pSbqNa9phxZMxHX+30AiDqX7TgiRjH4rtirLwb9g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]
On Thu, Mar 28, 2024 at 07:13:38PM +0000, Antoine Riard wrote:
> > Modulo economic irrationalities with differently sized txs like the Rule
> #6
> > attack, the proof-of-UTXO is almost economically paid even when mempools
> are
> > partitioned because the bandwidth used by a given form of a transaction is
> > limited to the % of peers that relay it. Eg if I broadcast TxA to 50% of
> nodes,
> > and TxB to the other 50%, both spending the same txout, the total cost/KB
> used
> > in total would exactly the same... except that nodes have more than one
> peer.
> > This acts as an amplification fator to attacks depending on the exact
> topology
> > as bandwidth is wasted in proportion to the # of peers txs need to be
> broadcast
> > too. Basically, a fan-out factor.
>
> > If the # of peers is reduced, the impact of this type of attack is also
> > reduced. Of course, a balance has to be maintained.
>
> Sure, proof-of-UTXO is imperfectly economically charged, however I think
> you can
> re-use the same proof-of-UTXO for each subset of Sybilled transaction-relay
> peers.
Of course you can. That's the whole point of my scenario above: you can re-use
the proof-of-UTXO. But since nodes' mempools enforce anti-doublespending, the
tradeoff is less total nodes seeing each individual conflicting uses.
If, for example, all Bitcoin nodes were somehow peered in a perfect ring, with
each node having exactly two peers, the sum total bandwidth of using 2
conflicting proof-of-UTXOs (aka spending the UTXO), would be almost identical
to the sum total bandwidth of just using 1. The only additional bandwidth would
be the three to four nodes at the "edges" of the ring who saw the two different
conflicting versions.
With higher #'s of peers, the total maximum extra bandwidth used broadcasting
conflicts increases proportionally.
--
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/ZgXJOxBsePn9VAKh%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-03-28 20:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 13:21 [bitcoindev] " Peter Todd
2024-03-19 12:37 ` Nagaev Boris
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 [this message]
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
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=ZgXJOxBsePn9VAKh@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.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