Subject: Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6

From: Antoine Riard <[email-masked]>
Date: Fri, 29 Mar 2024 13:48:26 -0700 (PDT)

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 [email-masked].
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/f1868012-8ad2-44ba-b83c-b53d5892b8e6n%40googlegroups.com.