Delivery-date: Fri, 29 Mar 2024 14:14:29 -0700
Sender: bitcoindev@googlegroups.com
Date: Fri, 29 Mar 2024 13:48:26 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <f1868012-8ad2-44ba-b83c-b53d5892b8e6n@googlegroups.com>
In-Reply-To: <ZgXJOxBsePn9VAKh@petertodd.org>
References: <Zfg/6IZyA/iInyMx@petertodd.org>
 <0a377ddb-b001-41ba-9208-27b3fa059bb5n@googlegroups.com>
 <ZgQZUOCc/dSjKMoL@petertodd.org>
 <CALZpt+GOCiwYdK4vfkODrT0Sx6HxCAuvhVqa1c5o3Xjy03OiAQ@mail.gmail.com>
 <ZgV+Rk0m4azlbRZP@petertodd.org>
 <CALZpt+H2B1pSbqNa9phxZMxHX+30AiDqX7TgiRjH4rtirLwb9g@mail.gmail.com>
 <ZgXJOxBsePn9VAKh@petertodd.org>
Subject: Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_185920_1609690552.1711745306409"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_185920_1609690552.1711745306409
Content-Type: multipart/alternative; 
	boundary="----=_Part_185921_1455644758.1711745306409"

------=_Part_185921_1455644758.1711745306409
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,

Answering your latest 2 emails.

> I do not consider CVE-2017-12842 to be serious. Indeed, I'm skeptical=20
that we
> should even fix it with a fork. SPV validation is very sketchy, and the=
=20
amount
> of work and money required to trigger CVE-2017-12842 is probably as or=20
more
> expensive than simply creating fake blocks.

> Sergio's RSK Bridge contract being vulnerable to it just indicates it was=
=20
a
> reckless design.

I don't think we shall disregard SPV validation yet in a world where we hav=
e
not really solved the scaling of Bitcoin payments for large range of user=
=20
segments
running on low-cost android mobile with limited validation ressources. On=
=20
the cost
of the attack, yes I think it's probably in the order of creating fake=20
blocks at current
difficulty adjustment.

On appreciating if a design is reckless or not, it's always good to do it=
=20
with a full-
fledged cost-based threat model in a comparative analysis w.r.t other=20
alternative
design in my experience.

> To be clear, in this particular case I had specific, insider, knowledge=
=20
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=
=20
company
> and don't have any contacts. I personally knew prior to publication that=
=20
the
> relevant people had been given a fair chance to comment, had chosen not=
=20
to, and
> I would likely receive no response at all.

Sure thing, it's not a disclosure configuration where the reporter has no=
=20
out-of-band
redundant communication channels available with the software group of=20
maintainers.
I can only suggest that Bitcoin Core's `SECURITY.md` to be modified in the=
=20
sense to
give an acknowledgement of reception to finding reports with technical=20
proofs under
~72 hours. I'll let external observers from the community make their own=20
appreciation
on what this disclosure episode can say on the state of Bitcoin security=20
problem handling.

> I'm not going to say anything further on how I knew this, because I'm not=
=20
about
> to put up people who have been co-operating with me to the risk of=20
harassment
> from people like Harding and others; I'm not very popular right now with=
=20
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=
=20
justify why
they're disregarding sound technical reports coming from a security=20
researcher with
a credible and proven track record, especially when it's apparently for=20
hidden social
reasons.

There is also the option to disclose under pseudonym which I personally=20
already done
sometimes in the past. I can understand ones does not wish to do so far for=
=20
professional
reputation reasons.

> Anyway, I think the lesson learned here is it's probably not worth=20
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=20
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=20
experience on
handling security issues since TDA initial report in 2019, I still think=20
it's good to
give 2-weeks to any vendors if they wish to engage in a mitigation process=
=20
(unless
special or emergency considerations).

In matters of ethical infosec and responsible disclosure, the process and=
=20
timeframe
actually followed should matter far more than the "who" of the reporter,=20
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,=
=20
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=20
identical
> to the sum total bandwidth of just using 1. The only additional bandwidth=
=20
would
> be the three to four nodes at the "edges" of the ring who saw the two=20
different
> conflicting versions.

> With higher #'s of peers, the total maximum extra bandwidth used=20
broadcasting
> conflicts increases proportionally.

Yes, higher #'s of peers, higher the total maximum extra outgoing bandwidth=
=20
used
for broadcasting conflicts increase proportionally. I think you can=20
dissociate among
transaction-announcement bandwidth (e.g INV(wtxid)) and=20
transaction-fetching=20
bandwidth (e.g GETDATA(wtxid)), you can re-fine the adversarial scenario to=
=20
have
highest DoS impact for each unique proof-of-UTXO. Like what is=20
bandwidth-cost
carried on by announcer and bandwidth-cost encumbered by the receiver.

Best,
Antoine


Le jeudi 28 mars 2024 =C3=A0 20:19:19 UTC, Peter Todd a =C3=A9crit :

> On Thu, Mar 28, 2024 at 07:13:38PM +0000, Antoine Riard wrote:
> > > Modulo economic irrationalities with differently sized txs like the=
=20
> Rule
> > #6
> > > attack, the proof-of-UTXO is almost economically paid even when=20
> mempools
> > are
> > > partitioned because the bandwidth used by a given form of a=20
> transaction is
> > > limited to the % of peers that relay it. Eg if I broadcast TxA to 50%=
=20
> of
> > nodes,
> > > and TxB to the other 50%, both spending the same txout, the total=20
> cost/KB
> > used
> > > in total would exactly the same... except that nodes have more than o=
ne
> > 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.
> >=20
> > > If the # of peers is reduced, the impact of this type of attack is al=
so
> > > reduced. Of course, a balance has to be maintained.
> >=20
> > Sure, proof-of-UTXO is imperfectly economically charged, however I thin=
k
> > you can
> > re-use the same proof-of-UTXO for each subset of Sybilled=20
> transaction-relay
> > peers.
>
> Of course you can. That's the whole point of my scenario above: you can=
=20
> re-use
> the proof-of-UTXO. But since nodes' mempools enforce anti-doublespending,=
=20
> the
> tradeoff is less total nodes seeing each individual conflicting uses.
>
> If, for example, all Bitcoin nodes were somehow peered in a perfect ring,=
=20
> 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=20
> identical
> to the sum total bandwidth of just using 1. The only additional bandwidth=
=20
> would
> be the three to four nodes at the "edges" of the ring who saw the two=20
> different
> conflicting versions.
>
> With higher #'s of peers, the total maximum extra bandwidth used=20
> broadcasting
> conflicts increases proportionally.
>
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--=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/f1868012-8ad2-44ba-b83c-b53d5892b8e6n%40googlegroups.com.

------=_Part_185921_1455644758.1711745306409
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,<div><br /></div><div>Answering your latest 2 emails.</div><div><b=
r /></div><div>&gt; I do not consider CVE-2017-12842 to be serious. Indeed,=
 I'm skeptical that we<br />&gt; should even fix it with a fork. SPV valida=
tion is very sketchy, and the amount<br />&gt; of work and money required t=
o trigger CVE-2017-12842 is probably as or more<br />&gt; expensive than si=
mply creating fake blocks.<br /><br />&gt; Sergio's RSK Bridge contract bei=
ng vulnerable to it just indicates it was a<br />&gt; reckless design.<br /=
></div><div><br /></div><div>I don't think we shall disregard SPV validatio=
n yet in a world where we have</div><div>not really solved the scaling of B=
itcoin payments for large range of user segments</div><div>running on low-c=
ost android mobile with limited validation ressources. On the cost</div><di=
v>of the attack, yes I think it's probably in the order of creating fake bl=
ocks at current</div><div>difficulty adjustment.</div><div><br /></div><div=
>On appreciating if a design is reckless or not, it's always good to do it =
with a full-</div><div>fledged cost-based threat model in a comparative ana=
lysis w.r.t other alternative</div><div>design in my experience.</div><div>=
<br /></div><div>&gt; To be clear, in this particular case I had specific, =
insider, knowledge that<br />&gt; the relevant people had in fact seen my r=
eport and had already decided to<br />&gt; dismiss it. This isn't a typical=
 case where you're emailing some random company<br />&gt; and don't have an=
y contacts. I personally knew prior to publication that the<br />&gt; relev=
ant people had been given a fair chance to comment, had chosen not to, and<=
br />&gt; I would likely receive no response at all.<br /></div><div><br />=
</div><div>Sure thing, it's not a disclosure configuration where the report=
er has no out-of-band</div><div>redundant communication channels available =
with the software group of maintainers.</div><div>I can only suggest that B=
itcoin Core's `SECURITY.md` to be modified in the sense to</div><div>give a=
n acknowledgement of reception to finding reports with technical proofs und=
er</div><div>~72 hours. I'll let external observers from the community make=
 their own appreciation</div><div>on what this disclosure episode can say o=
n the state of Bitcoin security problem handling.</div><div><br /></div><di=
v>&gt; I'm not going to say anything further on how I knew this, because I'=
m not about<br />&gt; to put up people who have been co-operating with me t=
o the risk of harassment<br />&gt; from people like Harding and others; I'm=
 not very popular right now with many<br />&gt; of the Bitcoin Core people =
working on the mempool code.<br /></div><div><br /></div><div>I think it's =
up to the maintainers or vendors of any piece of software to justify why</d=
iv><div>they're disregarding sound technical reports coming from a security=
 researcher with</div><div>a credible and proven track record, especially w=
hen it's apparently for hidden social</div><div>reasons.</div><div><br /></=
div><div>There is also the option to disclose under pseudonym which I perso=
nally already done</div><div>sometimes in the past. I can understand ones d=
oes not wish to do so far for professional</div><div>reputation reasons.</d=
iv><div><br /></div><div>&gt; Anyway, I think the lesson learned here is it=
's probably not worth bothering<br />&gt; with a disclosure process at all =
for this type of issue. It just created a<br />&gt; bunch of distracting po=
litical drama when simply publishing this exploit<br />&gt; variation immed=
iately probably would not have.<br /></div><div><br /></div><div>I've check=
ed my own archive, on the Lightning-side and from my memory,</div><div>I ca=
n remember two far more serious issues than free-relay attacks which were</=
div><div>quickly disclosed without a formal process over the past years:</d=
iv><div>- time-dilation attacks by myself [0]</div><div>- RBF-pinning on se=
cond-stage HTLC by the TheBlueMatt [1]</div><div><br /></div><div>Both were=
 conducted on a less than 7-days timeframe between private report</div><div=
>to select developers parties and public full-disclosure. With more experie=
nce on</div><div>handling security issues since TDA initial report in 2019,=
 I still think it's good to</div><div>give 2-weeks to any vendors if they w=
ish to engage in a mitigation process (unless</div><div>special or emergenc=
y considerations).</div><div><br /></div><div>In matters of ethical infosec=
 and responsible disclosure, the process and timeframe</div><div>actually f=
ollowed should matter far more than the "who" of the reporter, and her / hi=
s</div><div>"popularity" score on the social graph be completely disregarde=
d - imho.</div><div><br /></div><div>&gt; If, for example, all Bitcoin node=
s were somehow peered in a perfect ring, with<br />&gt; each node having ex=
actly two peers, the sum total bandwidth of using 2<br />&gt; conflicting p=
roof-of-UTXOs (aka spending the UTXO), would be almost identical<br />&gt; =
to the sum total bandwidth of just using 1. The only additional bandwidth w=
ould<br />&gt; be the three to four nodes at the "edges" of the ring who sa=
w the two different<br />&gt; conflicting versions.<br /><br />&gt; With hi=
gher #'s of peers, the total maximum extra bandwidth used broadcasting<br /=
>&gt; conflicts increases proportionally.<br /></div><div><br /></div><div>=
Yes, higher #'s of peers, higher the total maximum extra outgoing bandwidth=
 used</div><div>for broadcasting conflicts increase proportionally. I think=
 you can dissociate among</div><div>transaction-announcement bandwidth (e.g=
 INV(wtxid)) and transaction-fetching=C2=A0</div><div>bandwidth (e.g GETDAT=
A(wtxid)), you can re-fine the adversarial scenario to have</div><div>highe=
st DoS impact for each unique proof-of-UTXO. Like what is bandwidth-cost</d=
iv><div>carried on by announcer and bandwidth-cost encumbered by the receiv=
er.</div><div><br /></div><div>Best,</div><div>Antoine</div><div><br /><br =
/></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">L=
e jeudi 28 mars 2024 =C3=A0 20:19:19 UTC, Peter Todd a =C3=A9crit=C2=A0:<br=
/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; bor=
der-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">On Thu, Mar 28,=
 2024 at 07:13:38PM +0000, Antoine Riard wrote:
<br>&gt; &gt; Modulo economic irrationalities with differently sized txs li=
ke the Rule
<br>&gt; #6
<br>&gt; &gt; attack, the proof-of-UTXO is almost economically paid even wh=
en mempools
<br>&gt; are
<br>&gt; &gt; partitioned because the bandwidth used by a given form of a t=
ransaction is
<br>&gt; &gt; limited to the % of peers that relay it. Eg if I broadcast Tx=
A to 50% of
<br>&gt; nodes,
<br>&gt; &gt; and TxB to the other 50%, both spending the same txout, the t=
otal cost/KB
<br>&gt; used
<br>&gt; &gt; in total would exactly the same... except that nodes have mor=
e than one
<br>&gt; peer.
<br>&gt; &gt; This acts as an amplification fator to attacks depending on t=
he exact
<br>&gt; topology
<br>&gt; &gt; as bandwidth is wasted in proportion to the # of peers txs ne=
ed to be
<br>&gt; broadcast
<br>&gt; &gt; too. Basically, a fan-out factor.
<br>&gt;=20
<br>&gt; &gt; If the # of peers is reduced, the impact of this type of atta=
ck is also
<br>&gt; &gt; reduced. Of course, a balance has to be maintained.
<br>&gt;=20
<br>&gt; Sure, proof-of-UTXO is imperfectly economically charged, however I=
 think
<br>&gt; you can
<br>&gt; re-use the same proof-of-UTXO for each subset of Sybilled transact=
ion-relay
<br>&gt; peers.
<br>
<br>Of course you can. That&#39;s the whole point of my scenario above: you=
 can re-use
<br>the proof-of-UTXO. But since nodes&#39; mempools enforce anti-doublespe=
nding, the
<br>tradeoff is less total nodes seeing each individual conflicting uses.
<br>
<br>If, for example, all Bitcoin nodes were somehow peered in a perfect rin=
g, with
<br>each node having exactly two peers, the sum total bandwidth of using 2
<br>conflicting proof-of-UTXOs (aka spending the UTXO), would be almost ide=
ntical
<br>to the sum total bandwidth of just using 1. The only additional bandwid=
th would
<br>be the three to four nodes at the &quot;edges&quot; of the ring who saw=
 the two different
<br>conflicting versions.
<br>
<br>With higher #&#39;s of peers, the total maximum extra bandwidth used br=
oadcasting
<br>conflicts increases proportionally.
<br>
<br>--=20
<br><a href=3D"https://petertodd.org" target=3D"_blank" rel=3D"nofollow" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://pe=
tertodd.org&amp;source=3Dgmail&amp;ust=3D1711830543925000&amp;usg=3DAOvVaw2=
t6YOtPhZYJ42gICoxho60">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a hr=
ef=3D"http://petertodd.org" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttp://petertodd.org=
&amp;source=3Dgmail&amp;ust=3D1711830543925000&amp;usg=3DAOvVaw0KdSQs5-jwYo=
8i5YvmgZ9b">petertodd.org</a>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/f1868012-8ad2-44ba-b83c-b53d5892b8e6n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/f1868012-8ad2-44ba-b83c-b53d5892b8e6n%40googlegroups.com</a>.=
<br />

------=_Part_185921_1455644758.1711745306409--

------=_Part_185920_1609690552.1711745306409--