summaryrefslogtreecommitdiff
path: root/39/7d0bf06881a9c8454f48192f2a834c73a1559d
blob: 21924e7012afa7f003ac2b150a2383a659c6d8fc (plain)
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
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
Return-Path: <outlook_32F81FD1D1BD8CA0@outlook.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E26A11190
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  5 Mar 2017 12:55:40 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from SNT004-OMC2S20.hotmail.com (snt004-omc2s20.hotmail.com
	[65.55.90.95])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 88ADE139
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  5 Mar 2017 12:55:39 +0000 (UTC)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com ([65.55.90.73])
	by SNT004-OMC2S20.hotmail.com over TLS secured channel with
	Microsoft SMTPSVC(7.5.7601.23008); Sun, 5 Mar 2017 04:55:38 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
	s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; 
	bh=TY04TV9VQTFFERJM9Ae902Jactv+tyJbvQR7n1wzfqc=;
	b=E994+9aCbIfBztxRTy1kKl+hiBvxKXOvTEMSOLBTpK9/+gr0uKlHt5QJHGd4eAAc4FFOeP2S1yoEWCJ8cUhPrKTJcwOkH7zyhOn9BZW0SoFNa8SrRCyGUiMwXgDS5f9eL+3Q4C0MBX1mnIGnxPXmuuoRZYjTg+6wIRud2teNOBIGZBbhxE9QHB2D8+8kFgGDKVrp2bw2dSY+51N9clSkJSk7w+d+SnpV7RuGO1kpAuSDwsh0tahhOm166mgsGJ2hzOD9z5oLk7bA7m4vp+f09Ohsz7b4LrTmlwy5GCjcMzp+gP9qV5l+kO/dgDwoqH1zHIOKJQpV8wmoXsnCDgDudQ==
Received: from BL2NAM02FT041.eop-nam02.prod.protection.outlook.com
	(10.152.76.57) by BL2NAM02HT007.eop-nam02.prod.protection.outlook.com
	(10.152.76.253) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.7;
	Sun, 5 Mar 2017 12:55:37 +0000
Received: from BL2PR03MB435.namprd03.prod.outlook.com (10.152.76.58) by
	BL2NAM02FT041.mail.protection.outlook.com (10.152.77.122) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
	15.1.947.7 via Frontend Transport; Sun, 5 Mar 2017 12:55:37 +0000
Received: from BL2PR03MB435.namprd03.prod.outlook.com ([10.141.92.24]) by
	BL2PR03MB435.namprd03.prod.outlook.com ([10.141.92.24]) with mapi id
	15.01.0947.018; Sun, 5 Mar 2017 12:55:33 +0000
From: John Hardy <john@seebitcoin.com>
To: Marcel Jamin <marcel@jamin.net>, "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] Unique node identifiers
Thread-Index: AQHSlQC2uBBD8WtSHEG5hC7gQs1fHKGFyZ4AgABkFUk=
Sender: John Hardy <outlook_32F81FD1D1BD8CA0@outlook.com>
Date: Sun, 5 Mar 2017 12:55:27 +0000
Message-ID: <BL2PR03MB435C86E2A913C0D1BE08A03EE2D0@BL2PR03MB435.namprd03.prod.outlook.com>
References: <BL2PR03MB435C5077E69D91D0A8092B6EE2A0@BL2PR03MB435.namprd03.prod.outlook.com>,
	<CAAUq487S-rvt+fee4961ACyVYaHb=7f2TqppoVO=_WdHfYEExw@mail.gmail.com>
In-Reply-To: <CAAUq487S-rvt+fee4961ACyVYaHb=7f2TqppoVO=_WdHfYEExw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: jamin.net; dkim=none (message not signed)
	header.d=none; jamin.net;
	dmarc=none action=none header.from=seebitcoin.com; 
x-incomingtopheadermarker: OriginalChecksum:11439CC977B24398BB308ED438C705B3E4A2A74F0C9639F8C3B0C75D2009E3BF;
	UpperCasedChecksum:71355AC14AFD395E769A67A850F823ABABED9DFB3B3D05D2371938E6483D8EB1;
	SizeAsReceived:7971; Count:40
x-ms-exchange-messagesentrepresentingtype: 2
x-tmn: [SP6IU7K53sIxYc8/8EYnLAt/LoIc2QZb]
x-incomingheadercount: 40
x-eopattributedmessage: 0
x-microsoft-exchange-diagnostics: 1; BL2NAM02HT007;
	5:jUA758MSqgqT9JN6wepY5CPX5D+YCHgjz0a95iw/eXMIQlJx2DZ3mDf5mPg4RmWG9l2lAYBA1+V6OrcqPTCt37xu0AeBbeV1GMF6cKM4gZkQJ8p3b9CxTikh7q2E+gp2u9F0hfSxy02Nqlq7JK2SAg==;
	24:h+0QR3J2pSH7Dfl8cPzB/cjEso3IjM6rupkF72JHWRQwOeoiTLaNmQclLb8ArhDEecwo/n9ch+W3qsbiXdHDmrIzHQHGuYFleIuCMWwLeAg=;
	7:DxXhKPVeZ2+VMjSIFl0OwIJpphmKOAIptJ2u8w2pdxBemcA1Lr7pmgb4Sx/v8IvdJIGgTwMgpuNT5zkwe8eCZ2WtvLcG/1JJSCpEXmpkYyhVUzLHHad9HoEhqUQhhEkJtNvInV4hI+buhSGmAJrFlF3WWt/T63rTjyfBQOj3jLjSSefpQy/z8AS8twqb1LERFbut7MyyglKCTNPAFMdUSBMcTi0zu6rh5uMOX3ulkPM2Tj/zilrmwXPA7VJAqV7xKVueEj5EgjMPQcL3zNPaFq+xPLaGdDghVR3Xl15vrjrAgGI2xqW75pxRU0sHCSM8
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900015);
	DIR:OUT; SFP:1102; SCL:1; SRVR:BL2NAM02HT007;
	H:BL2PR03MB435.namprd03.prod.outlook.com; FPR:; SPF:None;
	LANG:en; 
x-ms-office365-filtering-correlation-id: 35d084a6-8cff-42af-9dfd-08d463c6e90c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1601125254)(1603101448)(1701031045);
	SRVR:BL2NAM02HT007; 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
	RULEID:(432015087)(444000031); SRVR:BL2NAM02HT007; BCL:0; PCL:0;
	RULEID:; SRVR:BL2NAM02HT007; 
x-forefront-prvs: 02379661A3
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BL2PR03MB435C86E2A913C0D1BE08A03EE2D0BL2PR03MB435namprd_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2017 12:55:27.6142 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT007
X-OriginalArrivalTime: 05 Mar 2017 12:55:38.0898 (UTC)
	FILETIME=[CA0F4720:01D295AF]
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 05 Mar 2017 13:13:18 +0000
Subject: Re: [bitcoin-dev] Unique node identifiers
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 05 Mar 2017 12:55:41 -0000

--_000_BL2PR03MB435C86E2A913C0D1BE08A03EE2D0BL2PR03MB435namprd_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

> Wouldn't this actually *need* to be a bitcoin address that is included in=
 a block

I think it being a bitcoin address probably makes the most sense. The addre=
ss could even be used for donations to incentivise identifier use.

I had not really envisaged this having any blockchain presence though. It w=
as just an easy way to give third party node monitors like coin.dance and b=
itnodes.21.co a few more metrics.

That said, it would allow the creation of a 'nodepool', where each node cou=
ld broadcast its latest status like a transaction, and every node has a reg=
ister of active nodes. Like a mempool, but for nodes.

By leveraging the randomness of node identities, it could be that a determi=
nistic subset of nodes randomly check that a new node status update is legi=
timate by querying the node directly (a small enough subset to not cause a =
DDOS). If a threshhold of those random checking nodes reports that the node=
 either doesn't exist or is responding with conflicting information, this w=
ill become evident to the network and can be flagged.

This should paint a pretty accurate picture of the state of the network, an=
d might also prove useful for developing lightning routing?

________________________________
From: Marcel Jamin <marcel@jamin.net>
Sent: Sunday, March 5, 2017 6:29 AM
To: John Hardy; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Unique node identifiers

> This could even come in the form of a Bitcoin address.

Wouldn't this actually *need* to be a bitcoin address that is included in a=
 block to get any real assurances about the age if this node id? Otherwise =
malicous nodes could lie and claim to have seen a brand new node id years a=
go already.

Even if included in a block, people could sell their aged IDs (if we were t=
o rely on those for anything).

Also funding that ID address would might tie your economic activity (or eve=
n identity) to a node.

On 4 March 2017 at 17:04, John Hardy via bitcoin-dev <bitcoin-dev@lists.lin=
uxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:

The discussion of UASF got me thinking about whether such a method might le=
ad to sybil attacks, with new nodes created purely to inflate the node coun=
t for a particular implementation in an attempt at social engineering.


I had an idea for an anonymous, opt-in, unique node identification mechanis=
m to help counter this.


This would give every node the opportunity to create a node =91address=92/u=
nique identifier. This could even come in the form of a Bitcoin address.


The node on first installation generates and backs up a private key. The co=
rresponding public key becomes that node=92s unique identifier. If the node=
 switches to a new software version or a new IP, the identifier can remain =
constant if the node operator chooses.


Asking a node for its identifier can be done by sending a message the comma=
nd =91identify=92 and a challenge. The node can then respond with its uniqu=
e identifier and a signature for the challenge to prove it. The node can al=
so include what software it is running and sign this information so it can =
be verified as legitimate by third parties.


Why would we do this?


Well, it adds a small but very useful piece of data when compiling lists of=
 active nodes.


Any register of active nodes can have a record of when a node identifier wa=
s =93first seen=94, and how many IPs the same identifier has broadcast from=
. Also, crucially, we could see what software the node operator has been se=
en running historically.


This information would make it easy to identify patterns. For example if a =
huge new group of nodes appeared on the network with no history for their i=
dentifier they could likely be dismissed as sybil attacks. If a huge number=
 of nodes that had been reporting as Bitcoin Core for an extended period of=
 time started switching to a rival implementation, this would add credibili=
ty but not certainty (keys could be traded), that the shift was more organi=
c.


This would be trivial to implement, is (to me?) non-controversial, and woul=
d give a way for a node to link itself to a pseudo-anonymous identity, but =
with the freedom to opt-out at any time.


Keen to hear any thoughts?


Thanks,


John Hardy

john@seebitcoin.com<mailto:john@seebitcoin.com>

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



--_000_BL2PR03MB435C86E2A913C0D1BE08A03EE2D0BL2PR03MB435namprd_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" dir=3D"ltr" style=3D"font-size:12pt; color=
:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
<div id=3D"divtagdefaultwrapper" dir=3D"ltr" style=3D"font-size:12pt; color=
:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>&gt;&nbsp;<span style=3D"font-family:arial; font-size:14.6667px; white-s=
pace:pre-wrap">Wouldn't this actually *need* to be a bitcoin address that i=
s included in a block</span></p>
<br>
I think it being a bitcoin address probably makes the most sense. The addre=
ss could even be used for donations to incentivise identifier use.</div>
<div id=3D"divtagdefaultwrapper" dir=3D"ltr" style=3D"font-size:12pt; color=
:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
<br>
</div>
<div id=3D"divtagdefaultwrapper" dir=3D"ltr" style=3D"font-size:12pt; color=
:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
I had not really envisaged this having any blockchain presence though. It w=
as just an easy way to give third party node monitors like coin.dance and b=
itnodes.21.co a few more metrics.</div>
<div id=3D"divtagdefaultwrapper" dir=3D"ltr" style=3D"font-size:12pt; color=
:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
<br>
</div>
<div id=3D"divtagdefaultwrapper" dir=3D"ltr" style=3D"font-size:12pt; color=
:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
That said, it would allow the creation of a 'nodepool', where each node cou=
ld broadcast its latest status like a transaction, and every node has a reg=
ister of active nodes. Like a mempool, but for nodes.</div>
<div id=3D"divtagdefaultwrapper" dir=3D"ltr" style=3D"font-size:12pt; color=
:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
<br>
</div>
<div id=3D"divtagdefaultwrapper" dir=3D"ltr" style=3D"font-size:12pt; color=
:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
<div>By leveraging the randomness of node identities, it could be that a de=
terministic subset of nodes randomly check that a new node status update is=
 legitimate by querying the node directly (a small enough subset to not cau=
se a DDOS). If a threshhold of those
 random checking nodes reports that the node either doesn't exist or is res=
ponding with conflicting information, this will become evident to the netwo=
rk and can be flagged.</div>
<div><br>
</div>
<div>This should paint a pretty accurate picture of the state of the networ=
k, and might also prove useful for developing lightning routing?</div>
<br>
<div style=3D"color:rgb(0,0,0)">
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co=
lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Marcel Jamin &lt;marc=
el@jamin.net&gt;<br>
<b>Sent:</b> Sunday, March 5, 2017 6:29 AM<br>
<b>To:</b> John Hardy; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] Unique node identifiers</font>
<div>&nbsp;</div>
</div>
<div>
<div dir=3D"ltr">
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace; font=
-size:small; color:rgb(12,52,61)">
&gt;&nbsp;<span style=3D"color:rgb(0,0,0); font-family:arial; font-size:14.=
6667px; white-space:pre-wrap">This could even come in the form of a Bitcoin=
 address.</span></div>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace; font=
-size:small; color:rgb(12,52,61)">
<span style=3D"color:rgb(0,0,0); font-family:arial; font-size:14.6667px; wh=
ite-space:pre-wrap"><br>
</span></div>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace; font=
-size:small; color:rgb(12,52,61)">
<span style=3D"color:rgb(0,0,0); font-family:arial; font-size:14.6667px; wh=
ite-space:pre-wrap">Wouldn't this actually *need* to be a bitcoin address t=
hat is included in a block to get any real assurances about the age if this=
 node id? Otherwise malicous nodes
 could lie and claim to have seen a brand new node id years ago already.</s=
pan></div>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace; font=
-size:small; color:rgb(12,52,61)">
<span style=3D"color:rgb(0,0,0); font-family:arial; font-size:14.6667px; wh=
ite-space:pre-wrap"><br>
</span></div>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace; font=
-size:small; color:rgb(12,52,61)">
<span style=3D"color:rgb(0,0,0); font-family:arial; font-size:14.6667px; wh=
ite-space:pre-wrap">Even if included in a block, people could sell their ag=
ed IDs (if we were to rely on those for anything).</span></div>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace; font=
-size:small; color:rgb(12,52,61)">
<span style=3D"color:rgb(0,0,0); font-family:arial; font-size:14.6667px; wh=
ite-space:pre-wrap"><br>
</span></div>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace; font=
-size:small; color:rgb(12,52,61)">
<span style=3D"color:rgb(0,0,0); font-family:arial; font-size:14.6667px; wh=
ite-space:pre-wrap">Also funding that ID address would might tie your econo=
mic activity (or even identity) to a node.</span></div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On 4 March 2017 at 17:04, John Hardy via bitcoin=
-dev <span dir=3D"ltr">
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex; border-left:1=
px #ccc solid; padding-left:1ex">
<div dir=3D"ltr">
<div id=3D"m_4495502098626100444divtagdefaultwrapper" dir=3D"ltr" style=3D"=
font-size:12pt; color:#000000; font-family:Calibri,Arial,Helvetica,sans-ser=
if">
<p><span id=3D"m_4495502098626100444docs-internal-guid-1be5245f-9a0e-19aa-b=
d44-cdeb0d05121c"></span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">The discussion of UAS=
F got me thinking about whether such a
 method might lead to sybil attacks, with new nodes created purely to infla=
te the node count for a particular implementation in an attempt at social e=
ngineering.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">I had an idea for an =
anonymous, opt-in, unique node identification
 mechanism to help counter this.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">This would give every=
 node the opportunity to create a node
 =91address=92/unique identifier. This could even come in the form of a Bit=
coin address.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">The node on first ins=
tallation generates and backs up a private
 key. The corresponding public key becomes that node=92s unique identifier.=
 If the node switches to a new software version or a new IP, the identifier=
 can remain constant if the node operator chooses.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">Asking a node for its=
 identifier can be done by sending a message
 the command =91identify=92 and a challenge. The node can then respond with=
 its unique identifier and a signature for the challenge to prove it. The n=
ode can also include what software it is running and sign this information =
so it can be verified as legitimate
 by third parties.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">Why would we do this?=
</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">Well, it adds a small=
 but very useful piece of data when compiling
 lists of active nodes.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">Any register of activ=
e nodes can have a record of when a node
 identifier was =93first seen=94, and how many IPs the same identifier has =
broadcast from. Also, crucially, we could see what software the node operat=
or has been seen running historically.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">This information woul=
d make it easy to identify patterns. For
 example if a huge new group of nodes appeared on the network with no histo=
ry for their identifier they could likely be dismissed as sybil attacks. If=
 a huge number of nodes that had been reporting as Bitcoin Core for an exte=
nded period of time started switching
 to a rival implementation, this would add credibility but not certainty (k=
eys could be traded), that the shift was more organic.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">This would be trivial=
 to implement, is (to me?) non-controversial,
 and would give a way for a node to link itself to a pseudo-anonymous ident=
ity, but with the freedom to opt-out at any time.</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">Keen to hear any thou=
ghts?</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">Thanks,</span></p>
<br>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap">John Hardy</span></p>
<p dir=3D"ltr" style=3D"line-height:1.38; margin-top:0pt; margin-bottom:0pt=
"><span style=3D"font-size:11pt; font-family:Arial; background-color:transp=
arent; vertical-align:baseline; white-space:pre-wrap"><a href=3D"mailto:joh=
n@seebitcoin.com" target=3D"_blank">john@seebitcoin.com</a></span></p>
<p></p>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_BL2PR03MB435C86E2A913C0D1BE08A03EE2D0BL2PR03MB435namprd_--