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
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
|
Return-Path: <willtech@live.com.au>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 405E9C07AC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Nov 2019 20:37:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 291D2849FA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Nov 2019 20:37:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ACty54cZj4gu
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Nov 2019 20:37:49 +0000 (UTC)
X-Greylist: delayed 00:18:04 by SQLgrey-1.7.6
Received: from APC01-PU1-obe.outbound.protection.outlook.com
(mail-oln040092254089.outbound.protection.outlook.com [40.92.254.89])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 92E6B84974
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 17 Nov 2019 20:37:48 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=AbALlYrWkAlDnmkOZnyAOfpWCofXp5hSPNrdUdq9NnZIky1oyU52fLWSEVMXjGKQf3SJMupWB6kgXkKPo6daS04YSw7MnTFotuVwP8n0N4RHmhFiLuBEmLT51p8ElO0nxTr8XoayxZC7vqpjBTLK5QYQXWFtMAS3pb/GAjbm+HvyEqy3ihfLxMKdXtT1IcDTEoxKAcICz/+LhvPmaApdazQXzXr9Lwkf72B3Niy1zisk3DSMtQyrkOFr6OnUybHS289W6bOE2ocCDVP7SGa7p+jhFxcsx5x7Jn0KYIPV0qRjtcQM9/tDbYALC26IueCmd1OvVZEgtyOW+V7E5DR40g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=XJQLPNXNG4hcHgwae3ki5I0NuxG1yJh7UjWE52grizc=;
b=UpqD/h4Vq1n1NMoHQm0ubJXqniuqC9HTGZa7XreFI8F0A7OiGdk0lxUfQiGkislVNYAmIBUYaUEpmZ52X4LpLAerKQ2YYiE7Amb7oON71LjDpIKxa2ldiXTcsmp3IWY+Op94BvUur/cFNbFVMblxa9tXU0mM7Q7SYrMGl4BhBlK3goLuQzZz+ZceqmhdJ+/RIYHgfQ7ak016t8q7vCkB1sU1bnOCD72B4RvbIcf6P8DeXKOAhsUNpUMx/ei7Xja70dNp8jTAUYAOLGQjh45bqqgfaXc+aRLiizHton3Uq4EOKHjxoQg5A/R7Kh/QDOZE5/tQF4rXlADRIP/W2jcJsQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
dkim=none; arc=none
Received: from SG2APC01FT049.eop-APC01.prod.protection.outlook.com
(10.152.250.58) by SG2APC01HT123.eop-APC01.prod.protection.outlook.com
(10.152.251.163) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Sun, 17 Nov
2019 20:04:04 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.250.58) by
SG2APC01FT049.mail.protection.outlook.com (10.152.251.207) with Microsoft
SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.2451.23 via Frontend Transport; Sun, 17 Nov 2019 20:04:04 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM
([fe80::8894:14d9:68de:ed5d]) by PS2P216MB0179.KORP216.PROD.OUTLOOK.COM
([fe80::8894:14d9:68de:ed5d%9]) with mapi id 15.20.2451.029; Sun, 17 Nov 2019
20:04:04 +0000
From: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>
To: "Mr. Lee Chiffre" <lee.chiffre@secmail.pro>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>, s7r <s7r@sky-ip.org>
Thread-Topic: [bitcoin-dev] v3 onion services
Thread-Index: AQHVnQShIfQtUSgPdEiVtoo6UmAXYaePfy8AgABGz9A=
Date: Sun, 17 Nov 2019 20:04:04 +0000
Message-ID: <PS2P216MB01798627A61D2214FB3ED0D79D720@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
References: <8fd4e30c4c1c24442686dd51727e75cc.squirrel@giyzk7o6dcunb2ry.onion>,
<c1371845-ef3e-c73b-f358-a0470bb48d07@sky-ip.org>
In-Reply-To: <c1371845-ef3e-c73b-f358-a0470bb48d07@sky-ip.org>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:6813E1BBFB3B89D197C60CAFA3362A4030A1EB0F98FBDC28F49FF7989556D49A;
UpperCasedChecksum:FCDCDEA7FDB9A16C4547974E74DEE902675BEC425320E2612198C77C027A73FD;
SizeAsReceived:7041; Count:45
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [UQUt25b8zdPzIrLIMDR/XJ44WAc62kr5]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 2fae3383-b2a0-4a85-42f3-08d76b994bf6
x-ms-traffictypediagnostic: SG2APC01HT123:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 460KWJJOYLK3Jmf8hdwr/RFdWS1/QS1eLLs0ptuJp5XP5Br5eDb3/18UQO8CycwC2QNS0CtpWZpAQk/x+kH2M1AMzeXR3fFxYhKKiY7G6p0545EXR/dAwROGMWosYRB4NqaERtipjXYKafgoWzGjqcObvodACH8G/li0sN0EfVmOXf0E7arYD9Z6J7g/99eF
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative;
boundary="_000_PS2P216MB01798627A61D2214FB3ED0D79D720PS2P216MB0179KORP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 2fae3383-b2a0-4a85-42f3-08d76b994bf6
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2019 20:04:04.3873 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT123
X-Mailman-Approved-At: Sun, 17 Nov 2019 20:41:22 +0000
Subject: Re: [bitcoin-dev] v3 onion services
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, 17 Nov 2019 20:37:51 -0000
--_000_PS2P216MB01798627A61D2214FB3ED0D79D720PS2P216MB0179KORP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
For those perhaps not so well versed in the operation of Bitcoin (and Bitco=
in Core) with Tor, connectivity through the outgoing connection to other no=
des is all accomplished via the socks5 proxy which enables all current goss=
ip and the distribution of the nodes own transactions to other nodes. This =
is a full connectivity feature.
For listening, Bitcoin Core instructs Tor to create an ephemeral hidden ser=
vice which, depending on the various factors, may be currently v2 only or v=
3 (future implementation). This is not necessary for the functionality of n=
ode connectivity in any way and is only used to allow for hidden listening =
so that other nodes connecting out on the onion can connect privately witho=
ut hopping on the public internet at all and without exposing the nodes pub=
lic IP or ports as listening (no port forwarding required and no listing on=
nodes list with public IP). It is currently possible for many nodes to exi=
st as onion only nodes.
For the time being, although I did wonder myself, the use of v3 ephemeral s=
ervice is not a requirement of operation on Bitcoin and hardly adds anythin=
g to security especially if we enable transient onion listening (a feature =
proposal is currently waiting for consideration/approval on bitcoin-core-de=
v and GitHub), however, eventually it will be essential to make use of the =
v3 ephemeral service as the v2 service support will, as I understand, event=
ually be dropped from the Tor network. I do not know if there are any curre=
nt distinct plans.
My opinion is, v3 support is a nice idea but hardly urgent yet. Good luck i=
f it ends up with an ack as I suspect some of the changes required will be =
complex and this may be perhaps the best reason to begin on it while there =
is interest.
Regards,
LORD HIS EXCELLENCY JAMES HRMH
________________________________
From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf=
of s7r via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Monday, 18 November 2019 2:35 AM
To: Mr. Lee Chiffre <lee.chiffre@secmail.pro>; Bitcoin Protocol Discussion =
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] v3 onion services
Mr. Lee Chiffre via bitcoin-dev wrote:
> Right now bitcoin client core supports use of tor hidden service. It
> supports v2 hidden service. I am in progress of creating a new bitcoin
> node which will use v3 hidden service instead of v2. I am looking at
> bitcoin core and btcd to use. Do any of these or current node software
> support the v3 onion addresses for the node address? What about I2P
> addresses? If not what will it take to get it to support the longer
> addresses that is used by i2p and tor v3?
>
>
Hello,
Yes, that is correct. Currently at present moment only v2 onion services
are supported. Bitcoin Core is limited at 128 bit 'addresses' in the p2p
protocol, so it requires a rework of the p2p protocol. v3 onion services
are whole ed25519 public keys, base32 encoded with .onion at the end.
Same reason applies to I2P 'address types' as well. However, I am not an
expert in I2P and don't actually know how many bitcoin full nodes might
exist in I2P.
See:
https://github.com/bitcoin/bitcoin/issues/9214
https://github.com/bitcoin/bitcoin/issues/2091
For the default `ADD_ONION` feature, the onion service key was
downgraded to explicitly RSA1024 (legacy, v2 onion services) to ensure
the feature still works out of the box:
https://github.com/bitcoin/bitcoin/pull/9234
If you want a Tor only full node, you are best to use v2 onion services
for now. Why do you need the bitcoin node to explicitly have a v3 onion
address? You can have a service that is accessible to the general public
as a v3 onion service, and in the back uses a bitcoin full node that
uses v2 onion service to talk to other nodes. The v2 onion service
bitcoin network is extended fairly.
You can use in the same torrc (Tor configuration file), implicitly same
Tor process/daemon simultaneously v2 and v3 onion services by setting
HiddenServiceVersion parameter after every HiddenServiceDir parameter.
--_000_PS2P216MB01798627A61D2214FB3ED0D79D720PS2P216MB0179KORP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"color: rgb(0, 0, 0); font-family: Calibri,Helvetica,sans-seri=
f; font-size: 12pt;">
For those perhaps not so well versed in the operation of Bitcoin (and Bitco=
in Core) with Tor, connectivity through the outgoing connection to other no=
des is all accomplished via the socks5 proxy which enables all current goss=
ip and the distribution of the nodes
own transactions to other nodes. This is a full connectivity feature.</div=
>
<div style=3D"color: rgb(0, 0, 0); font-family: Calibri,Helvetica,sans-seri=
f; font-size: 12pt;">
<br>
</div>
<div style=3D"color: rgb(0, 0, 0); font-family: Calibri,Helvetica,sans-seri=
f; font-size: 12pt;">
For listening, Bitcoin Core instructs Tor to create an ephemeral hidden ser=
vice which, depending on the various factors, may be currently v2 only or v=
3 (future implementation). This is not necessary for the functionality of n=
ode connectivity in any way and
is only used to allow for hidden listening so that other nodes connecting =
out on the onion can connect privately without hopping on the public intern=
et at all and without exposing the nodes public IP or ports as listening (n=
o port forwarding required and no
listing on nodes list with public IP). It is currently possible for many n=
odes to exist as onion only nodes.</div>
<div style=3D"color: rgb(0, 0, 0); font-family: Calibri,Helvetica,sans-seri=
f; font-size: 12pt;">
<br>
</div>
<div style=3D"color: rgb(0, 0, 0); font-family: Calibri,Helvetica,sans-seri=
f; font-size: 12pt;">
For the time being, although I did wonder myself, the use of v3 ephemeral s=
ervice is not a requirement of operation on Bitcoin and hardly adds anythin=
g to security especially if we enable transient onion listening (a feature =
proposal is currently waiting for
consideration/approval on bitcoin-core-dev and GitHub), however, eventuall=
y it will be essential to make use of the v3 ephemeral service as the v2 se=
rvice support will, as I understand, eventually be dropped from the Tor net=
work. I do not know if there are
any current distinct plans.</div>
<div style=3D"color: rgb(0, 0, 0); font-family: Calibri,Helvetica,sans-seri=
f; font-size: 12pt;">
<br>
</div>
<div style=3D"color: rgb(0, 0, 0); font-family: Calibri,Helvetica,sans-seri=
f; font-size: 12pt;">
My opinion is, v3 support is a nice idea but hardly urgent yet. Good luck i=
f it ends up with an ack as I suspect some of the changes required will be =
complex and this may be perhaps the best reason to begin on it while there =
is interest.</div>
<div style=3D"color: rgb(0, 0, 0); font-family: Calibri,Helvetica,sans-seri=
f; font-size: 12pt;">
<br>
</div>
<div id=3D"Signature">
<div></div>
<div></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
Regards,</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
LORD HIS EXCELLENCY JAMES HRMH</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<div></div>
</div>
<div>
<div id=3D"appendonsend"></div>
<div style=3D"color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif; f=
ont-size:12pt">
<br>
</div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font color=3D"#000000" face=3D"Calib=
ri, sans-serif" style=3D"font-size:11pt"><b>From:</b> bitcoin-dev <bitco=
in-dev-bounces@lists.linuxfoundation.org> on behalf of s7r via bitcoin-d=
ev <bitcoin-dev@lists.linuxfoundation.org><br>
<b>Sent:</b> Monday, 18 November 2019 2:35 AM<br>
<b>To:</b> Mr. Lee Chiffre <lee.chiffre@secmail.pro>; Bitcoin Protoco=
l Discussion <bitcoin-dev@lists.linuxfoundation.org><br>
<b>Subject:</b> Re: [bitcoin-dev] v3 onion services</font>
<div> </div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt"=
>
<div class=3D"PlainText">Mr. Lee Chiffre via bitcoin-dev wrote:<br>
> Right now bitcoin client core supports use of tor hidden service. It<b=
r>
> supports v2 hidden service. I am in progress of creating a new bitcoin=
<br>
> node which will use v3 hidden service instead of v2. I am looking at<b=
r>
> bitcoin core and btcd to use. Do any of these or current node software=
<br>
> support the v3 onion addresses for the node address? What about I2P<br=
>
> addresses? If not what will it take to get it to support the longer<br=
>
> addresses that is used by i2p and tor v3?<br>
> <br>
> <br>
<br>
Hello,<br>
<br>
Yes, that is correct. Currently at present moment only v2 onion services<br=
>
are supported. Bitcoin Core is limited at 128 bit 'addresses' in the p2p<br=
>
protocol, so it requires a rework of the p2p protocol. v3 onion services<br=
>
are whole ed25519 public keys, base32 encoded with .onion at the end.<br>
<br>
Same reason applies to I2P 'address types' as well. However, I am not an<br=
>
expert in I2P and don't actually know how many bitcoin full nodes might<br>
exist in I2P.<br>
<br>
See:<br>
<a href=3D"https://github.com/bitcoin/bitcoin/issues/9214">https://github.c=
om/bitcoin/bitcoin/issues/9214</a><br>
<br>
<a href=3D"https://github.com/bitcoin/bitcoin/issues/2091">https://github.c=
om/bitcoin/bitcoin/issues/2091</a><br>
<br>
<br>
For the default `ADD_ONION` feature, the onion service key was<br>
downgraded to explicitly RSA1024 (legacy, v2 onion services) to ensure<br>
the feature still works out of the box:<br>
<br>
<a href=3D"https://github.com/bitcoin/bitcoin/pull/9234">https://github.com=
/bitcoin/bitcoin/pull/9234</a><br>
<br>
If you want a Tor only full node, you are best to use v2 onion services<br>
for now. Why do you need the bitcoin node to explicitly have a v3 onion<br>
address? You can have a service that is accessible to the general public<br=
>
as a v3 onion service, and in the back uses a bitcoin full node that<br>
uses v2 onion service to talk to other nodes. The v2 onion service<br>
bitcoin network is extended fairly.<br>
<br>
You can use in the same torrc (Tor configuration file), implicitly same<br>
Tor process/daemon simultaneously v2 and v3 onion services by setting<br>
HiddenServiceVersion parameter after every HiddenServiceDir parameter.<br>
<br>
</div>
</span></font></div>
</div>
</div>
</body>
</html>
--_000_PS2P216MB01798627A61D2214FB3ED0D79D720PS2P216MB0179KORP_--
|