1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
Return-Path: <antoine.riard@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 54CBFC013A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Feb 2021 11:49:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 4327D87428
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Feb 2021 11:49:57 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 3J7WVkb1L3fY
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Feb 2021 11:49:56 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com
[209.85.221.43])
by hemlock.osuosl.org (Postfix) with ESMTPS id 515A687418
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Feb 2021 11:49:56 +0000 (UTC)
Received: by mail-wr1-f43.google.com with SMTP id v7so2389344wrr.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 Feb 2021 03:49:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=KRy3hYnE0PVi9XB8oXxSH6qFT2+j3lLvisMhYqnZses=;
b=rDxL5Lc5uD3gr0COtlLN5SsX+S5AhC0IUlrJ5LLe5eA6Am330tSz8qIedZa++8SEj6
3hCVu5HRPrKBWoR7DVn2QzrHLgcX9Hu0ICfyQfyIG6P/FeR91ZTy5aNFPO1GIbRFDC6V
1llF61GWdWPnjp3c5H2ZIGDZLNYWCnV2g62Fu6zX3XiX/0E3nLNDnGQsLiC3nUUquI3p
68gusz7m6sqGhTAH4SnQxKy9uTweD5XqYBfInSNaHGFsNUn/WHu/oUaBVizjqjpJrzcT
50/OchaNl2z2dDwKhdiGxnBL1237jgRV3YTesFsWRtyvdZDV4dA33lsZX8d5tAJm8Ztf
pK1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=KRy3hYnE0PVi9XB8oXxSH6qFT2+j3lLvisMhYqnZses=;
b=BvDGCfS7bmgqn9Lje/o+wngcFkv6K9jTRSDQ9Fma6cEaDAD8N+SWroftIFBxSPjoWg
zOjVY2L+vVuYjosJqB9K3og0YRbkPGB3Zodm479Ah90NM/cHUtva8O8G5RA21b/SqBXA
xrXvcfPTNlraGo1gOCz/hGE/qZf2BGKALFAFQf69b7BHQ3m9uYiW6Q2ZqLI+uyBzmFh6
CQuddiKE3/kZdQ6ClOF3t3Y9YZZG+fC3PH2yukz2/J+UfvzzDH3frP543Lhi6Wtlm4mH
DmvBLlxOAp57WGtgABSUHIZguLGrfcsM5WHOfOw28oCpk9GXwy40mGwvOjLBvMkAcHeX
hOMQ==
X-Gm-Message-State: AOAM530/t0Oy2/Pb48VOrnkBEdDGcFe+7fW++GJAzKfD6N0ncFC9D5I2
YrfCicKCD3vSIvtF95XHiWAdWoZUyGlN8P+iaBc=
X-Google-Smtp-Source: ABdhPJwG8IykI5K9HM9qt1Zp8+MN99ocvSRf1blHQigAwXzcFYnQdozppvl34MQeWpUVgQroMQktg30llAl6xsGdk4k=
X-Received: by 2002:a05:6000:104:: with SMTP id
o4mr2952511wrx.419.1613130594663;
Fri, 12 Feb 2021 03:49:54 -0800 (PST)
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"
X-Mailman-Approved-At: Fri, 12 Feb 2021 12:20:23 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal to stop processing of unrequested
transactions in Bitcoin Core
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Feb 2021 11:49:57 -0000
--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're worried that change would ease discovery of the=
node's tx-relay topology ? I don'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'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 "is-unrequ=
ested" 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't see how this change is easing attackers'=
work. That said, I don'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 <<a h=
ref=3D"mailto:bitcoin-dev@wuille.net">bitcoin-dev@wuille.net</a>> 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'=
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'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--
|
