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
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
|
Return-Path: <aymeric@peersm.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 48432C0012
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 12 Dec 2021 12:07:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 35DE7859B9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 12 Dec 2021 12:07:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.017
X-Spam-Level:
X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.117,
RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id H0ynx_GXWK56
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 12 Dec 2021 12:07:44 +0000 (UTC)
X-Greylist: delayed 00:19:19 by SQLgrey-1.8.0
Received: from smtpout1.mo529.mail-out.ovh.net
(smtpout1.mo529.mail-out.ovh.net [178.32.125.2])
by smtp1.osuosl.org (Postfix) with ESMTPS id D1752859B8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 12 Dec 2021 12:07:43 +0000 (UTC)
Received: from mxplan6.mail.ovh.net (unknown [10.109.146.249])
by mo529.mail-out.ovh.net (Postfix) with ESMTPS id B15E5D167E65;
Sun, 12 Dec 2021 12:48:21 +0100 (CET)
Received: from peersm.com (37.59.142.98) by DAG6EX1.mxp6.local (172.16.2.51)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Sun, 12 Dec
2021 12:48:21 +0100
Authentication-Results: garm.ovh; auth=pass
(GARM-98R00277faca00-cdd3-449d-9d04-7aa3c9dc7306,
0162D8E0E18B0A35B3A43025BCC48F53E5557781) smtp.auth=aymeric@peersm.com
X-OVh-ClientIp: 92.184.100.131
To: Pieter Wuille <bitcoin-dev@wuille.net>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
References: <MqZttWy--3-2@tutanota.de>
<1fbf0ef8b1b42979361b5df0b09c2dcd@willtech.com.au>
<dSBrti8VFr0lMNgTHw8pD-mAPLm0E4auJa234o0FNY67EUuEy1Dfb93INNIzoUb3j2dWSJjZtG7qncci1LhKAHOXzAzbEWOtXjnggr19J6w=@wuille.net>
From: Aymeric Vitte <aymeric@peersm.com>
Message-ID: <86d49c80-2f8f-245c-5fdb-17c6ca6b5f2b@peersm.com>
Date: Sun, 12 Dec 2021 12:48:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <dSBrti8VFr0lMNgTHw8pD-mAPLm0E4auJa234o0FNY67EUuEy1Dfb93INNIzoUb3j2dWSJjZtG7qncci1LhKAHOXzAzbEWOtXjnggr19J6w=@wuille.net>
Content-Type: multipart/alternative;
boundary="------------35852C7439EE128664E0EF4B"
X-Originating-IP: [37.59.142.98]
X-ClientProxiedBy: DAG5EX1.mxp6.local (172.16.2.41) To DAG6EX1.mxp6.local
(172.16.2.51)
X-Ovh-Tracer-GUID: 172242ae-58db-455e-aec2-2b5a3b78739b
X-Ovh-Tracer-Id: 16250394831654839194
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvuddrkeeigdeffecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhepuffvfhfhkffffgggjggtihesrgdtreertdefheenucfhrhhomhepteihmhgvrhhitgcugghithhtvgcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnhepveeutedvgefhhfeftdefffdvtdfgfeeuheehvedvffejkeefueeludejteekvddvnecuffhomhgrihhnpehgihhthhhusgdrtghomhdplhhinhhugihfohhunhgurghtihhonhdrohhrghenucfkpheptddrtddrtddrtddpfeejrdehledrudegvddrleeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpohhuthdphhgvlhhopehmgihplhgrnheirdhmrghilhdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomheprgihmhgvrhhitgesphgvvghrshhmrdgtohhmpdhrtghpthhtohepsghithgtohhinhdquggvvhesfihuihhllhgvrdhnvght
X-Mailman-Approved-At: Sun, 12 Dec 2021 12:41:47 +0000
Subject: Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network
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: Sun, 12 Dec 2021 12:07:45 -0000
--------------35852C7439EE128664E0EF4B
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Indeed, I reiterate that using the Tor network for Bitcoin or whatever
protocol not related to the Tor Browser (ie browsing and HS) does not
make sense, for plenty of reasons
But using the Tor protocol outside of the Tor network (and inside
browsers for wallets for example) does:
https://github.com/Ayms/node-Tor#presentation and
https://github.com/Ayms/node-Tor#phase-4-and-phase-5, anonymizing nodes
can just be already existing bitcoin nodes, example:
https://github.com/bitcoin/bitcoin/pull/18988#issuecomment-646564853
Le 11/12/2021 =E0 17:21, Pieter Wuille via bitcoin-dev a =E9crit :
>> It is that the solution to privacy is to use privacy-enhancing network=
>> communications, such as TOR. I am not against a mechanism to rebroadca=
st
>> transactions more robustly if the mempool of adjoining nodes has
>> forgotten about them, but the truth is, all transactions originate fro=
m
>> some node, and there are methods that allow an individual node to be
>> identified as the likely source of a transaction unless privacy-enable=
d
>> networks are utilised. Having a different method to cause rebroadcast
>> does not obfuscate the origin.
> You're talking about distinct aspects of transaction privacy.
>
> The rebroadcasting approach as it exists on the network, where wallets =
are responsible for their own rebroadcasting, directly reveals to your pe=
ers a relation between nodes and transactions: whenever any node relays t=
he same transaction twice, it almost certainly implies they are the origi=
n.
>
> This is just a node-transaction relation, and not necessarily IP-transa=
ction relation. The latter can indeed be avoided by only connecting over =
Tor, or using other privacy networks, but just hiding the relation with I=
P addresses isn't sufficient (and has its own downsides; e.g. Tor-only co=
nnectivity is far more susceptible to partition/Eclipse/DoS attacks). For=
example seeing the same node (even without knowing its IP) rebroadcast t=
wo transaction lets an observe infer a relation between those transaction=
s, and that too is a privacy leak.
>
> I believe moving to a model where mempools/nodes themselves are respons=
ible for rebroadcasting is a great solution to improving this specific pr=
oblem, simply because if everyone rebroadcasts, the original author doing=
it too does not stand out anymore. It isn't "fixing privacy", it's fixin=
g a specific leak, one of many, but this isn't a black and white property=
=2E
>
> Cheers,
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--------------35852C7439EE128664E0EF4B
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Indeed, I reiterate <span class="VIiyi" jsaction="mouseup:BR6jm"
jsname="jqKxS" lang="en"><span
jsaction="agoMJf:PFBcW;usxOmf:aWLT7;jhKsnd:P7O7bd,F8DmGf;Q4AGo:Gm7gYd,qAKMYb;uFUCPb:pvnm0e,pfE8Hb,PFBcW;f56efd:dJXsye;EnoYf:KNzws,ZJsZZ,JgVSJc;zdMJQc:cCQNKb,ZJsZZ,zchEXc;Ytrrj:JJDvdc;tNR8yc:GeFvjb;oFN6Ye:hij5Wb;bmeZHc:iURhpf;Oxj3Xe:qAKMYb,yaf12d"
jsname="txFAF" class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="fr" data-phrase-index="0"
data-number-of-phrases="1" jscontroller="Zl5N8"
jsdata="uqLsIf;_;$58" jsmodel="SsMkhd"><span
jsaction="click:qtZ4nf,GFf3ac,tMZCfe;
contextmenu:Nqw7Te,QP7LD; mouseout:Nqw7Te;
mouseover:qtZ4nf,c2aHje" jsname="W297wb">that using the Tor
network for Bitcoin or whatever protocol not related to the
Tor Browser (ie browsing and HS) does not make sense, for
plenty of reasons</span></span></span></p>
<p><span class="VIiyi" jsaction="mouseup:BR6jm" jsname="jqKxS"
lang="en"><span
jsaction="agoMJf:PFBcW;usxOmf:aWLT7;jhKsnd:P7O7bd,F8DmGf;Q4AGo:Gm7gYd,qAKMYb;uFUCPb:pvnm0e,pfE8Hb,PFBcW;f56efd:dJXsye;EnoYf:KNzws,ZJsZZ,JgVSJc;zdMJQc:cCQNKb,ZJsZZ,zchEXc;Ytrrj:JJDvdc;tNR8yc:GeFvjb;oFN6Ye:hij5Wb;bmeZHc:iURhpf;Oxj3Xe:qAKMYb,yaf12d"
jsname="txFAF" class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="fr" data-phrase-index="0"
data-number-of-phrases="1" jscontroller="Zl5N8"
jsdata="uqLsIf;_;$58" jsmodel="SsMkhd"><span
jsaction="click:qtZ4nf,GFf3ac,tMZCfe;
contextmenu:Nqw7Te,QP7LD; mouseout:Nqw7Te;
mouseover:qtZ4nf,c2aHje" jsname="W297wb">But using the Tor
protocol outside of the Tor network (and inside browsers for
wallets for example) does:
<a class="moz-txt-link-freetext" href="https://github.com/Ayms/node-Tor#presentation">https://github.com/Ayms/node-Tor#presentation</a> and
<a class="moz-txt-link-freetext" href="https://github.com/Ayms/node-Tor#phase-4-and-phase-5">https://github.com/Ayms/node-Tor#phase-4-and-phase-5</a>,
anonymizing nodes can just be already existing bitcoin
nodes, example:
<a class="moz-txt-link-freetext" href="https://github.com/bitcoin/bitcoin/pull/18988#issuecomment-646564853">https://github.com/bitcoin/bitcoin/pull/18988#issuecomment-646564853</a><br>
</span></span></span></p>
<br>
<div class="moz-cite-prefix">Le 11/12/2021 à 17:21, Pieter Wuille
via bitcoin-dev a écrit :<br>
</div>
<blockquote
cite="mid:dSBrti8VFr0lMNgTHw8pD-mAPLm0E4auJa234o0FNY67EUuEy1Dfb93INNIzoUb3j2dWSJjZtG7qncci1LhKAHOXzAzbEWOtXjnggr19J6w=@wuille.net"
type="cite">
<blockquote type="cite">
<pre wrap="">It is that the solution to privacy is to use privacy-enhancing network
communications, such as TOR. I am not against a mechanism to rebroadcast
transactions more robustly if the mempool of adjoining nodes has
forgotten about them, but the truth is, all transactions originate from
some node, and there are methods that allow an individual node to be
identified as the likely source of a transaction unless privacy-enabled
networks are utilised. Having a different method to cause rebroadcast
does not obfuscate the origin.
</pre>
</blockquote>
<pre wrap="">
You're talking about distinct aspects of transaction privacy.
The rebroadcasting approach as it exists on the network, where wallets are responsible for their own rebroadcasting, directly reveals to your peers a relation between nodes and transactions: whenever any node relays the same transaction twice, it almost certainly implies they are the origin.
This is just a node-transaction relation, and not necessarily IP-transaction relation. The latter can indeed be avoided by only connecting over Tor, or using other privacy networks, but just hiding the relation with IP addresses isn't sufficient (and has its own downsides; e.g. Tor-only connectivity is far more susceptible to partition/Eclipse/DoS attacks). For example seeing the same node (even without knowing its IP) rebroadcast two transaction lets an observe infer a relation between those transactions, and that too is a privacy leak.
I believe moving to a model where mempools/nodes themselves are responsible for rebroadcasting is a great solution to improving this specific problem, simply because if everyone rebroadcasts, the original author doing it too does not stand out anymore. It isn't "fixing privacy", it's fixing a specific leak, one of many, but this isn't a black and white property.
Cheers,
--
Pieter
_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>
--------------35852C7439EE128664E0EF4B--
|
