From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6
Date: Fri, 29 Mar 2024 13:48:26 -0700 (PDT) [thread overview]
Message-ID: <f1868012-8ad2-44ba-b83c-b53d5892b8e6n@googlegroups.com> (raw)
In-Reply-To: <ZgXJOxBsePn9VAKh@petertodd.org>
[-- Attachment #1.1: Type: text/plain, Size: 7637 bytes --]
Hi Peter,
Answering your latest 2 emails.
> I do not consider CVE-2017-12842 to be serious. Indeed, I'm skeptical
that we
> should even fix it with a fork. SPV validation is very sketchy, and the
amount
> of work and money required to trigger CVE-2017-12842 is probably as or
more
> expensive than simply creating fake blocks.
> Sergio's RSK Bridge contract being vulnerable to it just indicates it was
a
> reckless design.
I don't think we shall disregard SPV validation yet in a world where we have
not really solved the scaling of Bitcoin payments for large range of user
segments
running on low-cost android mobile with limited validation ressources. On
the cost
of the attack, yes I think it's probably in the order of creating fake
blocks at current
difficulty adjustment.
On appreciating if a design is reckless or not, it's always good to do it
with a full-
fledged cost-based threat model in a comparative analysis w.r.t other
alternative
design in my experience.
> To be clear, in this particular case I had specific, insider, knowledge
that
> the relevant people had in fact seen my report and had already decided to
> dismiss it. This isn't a typical case where you're emailing some random
company
> and don't have any contacts. I personally knew prior to publication that
the
> relevant people had been given a fair chance to comment, had chosen not
to, and
> I would likely receive no response at all.
Sure thing, it's not a disclosure configuration where the reporter has no
out-of-band
redundant communication channels available with the software group of
maintainers.
I can only suggest that Bitcoin Core's `SECURITY.md` to be modified in the
sense to
give an acknowledgement of reception to finding reports with technical
proofs under
~72 hours. I'll let external observers from the community make their own
appreciation
on what this disclosure episode can say on the state of Bitcoin security
problem handling.
> I'm not going to say anything further on how I knew this, because I'm not
about
> to put up people who have been co-operating with me to the risk of
harassment
> from people like Harding and others; I'm not very popular right now with
many
> of the Bitcoin Core people working on the mempool code.
I think it's up to the maintainers or vendors of any piece of software to
justify why
they're disregarding sound technical reports coming from a security
researcher with
a credible and proven track record, especially when it's apparently for
hidden social
reasons.
There is also the option to disclose under pseudonym which I personally
already done
sometimes in the past. I can understand ones does not wish to do so far for
professional
reputation reasons.
> Anyway, I think the lesson learned here is it's probably not worth
bothering
> with a disclosure process at all for this type of issue. It just created a
> bunch of distracting political drama when simply publishing this exploit
> variation immediately probably would not have.
I've checked my own archive, on the Lightning-side and from my memory,
I can remember two far more serious issues than free-relay attacks which
were
quickly disclosed without a formal process over the past years:
- time-dilation attacks by myself [0]
- RBF-pinning on second-stage HTLC by the TheBlueMatt [1]
Both were conducted on a less than 7-days timeframe between private report
to select developers parties and public full-disclosure. With more
experience on
handling security issues since TDA initial report in 2019, I still think
it's good to
give 2-weeks to any vendors if they wish to engage in a mitigation process
(unless
special or emergency considerations).
In matters of ethical infosec and responsible disclosure, the process and
timeframe
actually followed should matter far more than the "who" of the reporter,
and her / his
"popularity" score on the social graph be completely disregarded - imho.
> 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.
Yes, higher #'s of peers, higher the total maximum extra outgoing bandwidth
used
for broadcasting conflicts increase proportionally. I think you can
dissociate among
transaction-announcement bandwidth (e.g INV(wtxid)) and
transaction-fetching
bandwidth (e.g GETDATA(wtxid)), you can re-fine the adversarial scenario to
have
highest DoS impact for each unique proof-of-UTXO. Like what is
bandwidth-cost
carried on by announcer and bandwidth-cost encumbered by the receiver.
Best,
Antoine
Le jeudi 28 mars 2024 à 20:19:19 UTC, Peter Todd a écrit :
> 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/f1868012-8ad2-44ba-b83c-b53d5892b8e6n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 9548 bytes --]
next prev parent reply other threads:[~2024-03-29 21:14 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
2024-03-29 20:48 ` Antoine Riard [this message]
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=f1868012-8ad2-44ba-b83c-b53d5892b8e6n@googlegroups.com \
--to=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