MIME-Version: 1.0
References: <CALZpt+E6UqB5cew145PO2qiEMsELJ-TuGyE5PBL04T1tESiOiQ@mail.gmail.com>
 <CAD5xwhjGsB38otK5+H30XcnFnUdP+D29_k5=p2ZBgXzvdRRggw@mail.gmail.com>
 <ii__M4064KswBFoSG8QQus9QE36Iv0wSBIEcRm-jWPZhZhT5d3aBFrjiO27whqJ5iZ6MeNuz8KMSSFec7bMAh3DddZvFRtgbngO3edsX6Cw=@wuille.net>
In-Reply-To: <ii__M4064KswBFoSG8QQus9QE36Iv0wSBIEcRm-jWPZhZhT5d3aBFrjiO27whqJ5iZ6MeNuz8KMSSFec7bMAh3DddZvFRtgbngO3edsX6Cw=@wuille.net>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 12 Feb 2021 06:49:42 -0500
Message-ID: <CALZpt+HnAbD+EGKE_=fCS8YPJ77XEqT6xvUq8YO3ErSQ+=FaxQ@mail.gmail.com>
To: Pieter Wuille <bitcoin-dev@wuille.net>
Content-Type: multipart/alternative; boundary="000000000000123fc805bb223ca3"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal to stop processing of unrequested
 transactions in Bitcoin Core
Precedence: list

--000000000000123fc805bb223ca3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jeremy,

If I understand correctly your concern, you're worried that change would
ease discovery of the node's tx-relay topology ? I don't scope transaction
origin inference, if you suppose the
unrequested-tx peer sending is the attacker it must have learnt the
transaction from somewhere else which is more likely to be the tx owner
rather than the probed node.

As far I can think of this change, a peer might send an unrequested
transaction to this node and observe that it's either a) processed, the
node has learnt about the txid from another peer or b) rejected, the node
has never learnt about the txid. The outcome can be queried by sending a
GETDATA for the "is-unrequested" txid.

I think the same result can already be achieved by sending an INV and
observing if a GETDATA is replied back to guess the presence of another
peer with already the knowledge of the txid. Or alternatively, just connect
to this other peer and wait for an announcement.

What else can we think of ?

From my side, compared to the already-existing heuristics, I don't see how
this change is easing attackers' work. That said, I don't deny our
transaction announcements/requests logic is worthy of more study about its
privacy properties, especially when you acknowledge the recent overhaul of
the transaction request and the upcoming Erlay changes.

Cheers,
Antoine

Le jeu. 11 f=C3=A9vr. 2021 =C3=A0 16:15, Pieter Wuille <bitcoin-dev@wuille.=
net> a
=C3=A9crit :

>
> I'm not sure of the existing behavior is of when we issue a getdata
> request, but noting that there could be a privacy implication of this sor=
t
> of change. Could you (or someone else) expand on why this is not a concer=
n
> here?
>
>
> What kind of privacy concern are you talking about? I'm not sure I see ho=
w
> this could matter.
>
> Cheers,
>
> --
> Pieter
>
>

--000000000000123fc805bb223ca3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Jeremy,<br><br>If I understand correct=
ly your concern, you&#39;re worried that change would ease discovery of the=
 node&#39;s tx-relay topology ? I don&#39;t scope transaction origin infere=
nce, if you suppose the<br>unrequested-tx peer sending is the attacker it m=
ust have learnt the transaction from somewhere else which is more likely to=
 be the tx owner rather than the probed node.<br><br>As far I can think of =
this change, a peer might send an unrequested transaction to this node and =
observe that it&#39;s either a) processed, the node has learnt about the tx=
id from another peer or b) rejected, the node has never learnt about the tx=
id. The outcome can be queried by sending a GETDATA for the &quot;is-unrequ=
ested&quot; txid.<br><br>I think the same result can already be achieved by=
 sending an INV and observing if a GETDATA is replied back to guess the pre=
sence of another peer with already the knowledge of the txid. Or alternativ=
ely, just connect to this other peer and wait for an announcement.<br><br>W=
hat else can we think of ? <br><br>From my side, compared to the already-ex=
isting heuristics, I don&#39;t see how this change is easing attackers&#39;=
 work. That said, I don&#39;t deny our transaction announcements/requests l=
ogic is worthy of more study about its privacy properties, especially when =
you acknowledge the recent overhaul of the transaction request and the upco=
ming Erlay changes.<br><br></div><div>Cheers,<br></div><div>Antoine<br></di=
v></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">Le=C2=A0jeu. 11 f=C3=A9vr. 2021 =C3=A0=C2=A016:15, Pieter Wuille &lt;<a h=
ref=3D"mailto:bitcoin-dev@wuille.net">bitcoin-dev@wuille.net</a>&gt; a =C3=
=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I&#39;=
m not sure of the existing behavior is of when we issue a getdata request, =
but noting that there could be a privacy implication of this sort of change=
. Could you (or someone else) expand on why this is not a concern here?<br>=
</div></div></blockquote><div><br></div><div>What kind of privacy concern a=
re you talking about? I&#39;m not sure I see how this could matter.<br></di=
v><div><br></div><div>Cheers,<br></div><div><br></div><div>-- <br></div><di=
v>Pieter<br></div><div><br></div></blockquote></div>

--000000000000123fc805bb223ca3--