summaryrefslogtreecommitdiff
path: root/ad/d7576c6145ec05aa8acc804bc3a3c18bed6904
blob: fb43e70219587b0eb5dba436b90fa32bc342888b (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
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 D8A90826
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  4 Mar 2017 16:04:53 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from SNT004-OMC1S32.hotmail.com (snt004-omc1s32.hotmail.com
	[65.55.90.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED409177
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  4 Mar 2017 16:04:52 +0000 (UTC)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com ([65.55.90.9]) by
	SNT004-OMC1S32.hotmail.com over TLS secured channel with
	Microsoft SMTPSVC(7.5.7601.23008); Sat, 4 Mar 2017 08:04:52 -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=K00WFpl4oa36EYKgurl9FAg1FmdmRRXLDCY96EEqEUA=;
	b=nLLDuAhGCMo0ox+zsFNXguydL1dXUz4GZTZlbnQiuABThRVbjVfkSZ2LPbXTyQvwI9KvCqhXTF9lZ8vDqEFQR06vMwtJAD/EFvOIIti6ikzjFThriblHksvosrOK4ym/+HjNbXbqG4VG2HaZi8t1DALnvEhj8HJMsQ96hEIER4y4VLT4gt2k82v1SnXy2ayizgPUSL5Viqj0HClP76gIGuGcdLUlKiwKlE++5uNmxx3ATdYgLw0K78nHelNzvuSK/P08jcv/noue8uHv4qaq5DGSyLwcmIGpXzvZYHWIaUk8HuhHec8bFY1a2vcPuLnuIX+Scw9DNe7MXvSzg1Uwvg==
Received: from BY2NAM01FT003.eop-nam01.prod.protection.outlook.com
	(10.152.68.54) by BY2NAM01HT093.eop-nam01.prod.protection.outlook.com
	(10.152.68.221) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.11;
	Sat, 4 Mar 2017 16:04:51 +0000
Received: from BL2PR03MB435.namprd03.prod.outlook.com (10.152.68.55) by
	BY2NAM01FT003.mail.protection.outlook.com (10.152.68.125) 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; Sat, 4 Mar 2017 16:04:50 +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.015; Sat, 4 Mar 2017 16:04:50 +0000
From: John Hardy <john@seebitcoin.com>
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: Unique node identifiers
Thread-Index: AQHSlQC2uBBD8WtSHEG5hC7gQs1fHA==
Sender: John Hardy <outlook_32F81FD1D1BD8CA0@outlook.com>
Date: Sat, 4 Mar 2017 16:04:50 +0000
Message-ID: <BL2PR03MB435C5077E69D91D0A8092B6EE2A0@BL2PR03MB435.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: lists.linuxfoundation.org; dkim=none (message not
	signed) header.d=none; lists.linuxfoundation.org; dmarc=none action=none
	header.from=seebitcoin.com;
x-incomingtopheadermarker: OriginalChecksum:FFE913B06B043A685505A300F0402D3A95CA74C2880751E77FC0827A43686F59;
	UpperCasedChecksum:5EEE6DF20C8FE8ABB75AC089B92132FAB76E233A19F2C3A6C09CD638A2D6CCA9;
	SizeAsReceived:7651; Count:38
x-ms-exchange-messagesentrepresentingtype: 2
x-tmn: [WGLhbnWecDt7X2y8UIif0/0qDwDoJDYs]
x-incomingheadercount: 38
x-eopattributedmessage: 0
x-microsoft-exchange-diagnostics: 1; BY2NAM01HT093;
	5:lxlRxF3tJ6CZ0KbqBmv8dkEdt63rQ4/957tNTDue+THNiHbaYV5E3dydOIi4D8QPRtyHssS/WpAYP0Hh/S5FzK/n4dGf2DpeLWm9we/FrbtDW3TQkVNZYzpMgXm1ndZGsOVFJNTy0Gvs3tf7Px+oig==;
	24:nvBk3prUVj5E6NfTlHqeaEjjQVPCXX1BM9jjQSHSWcpEU1ETJ2FYCX5oZ9YfSouUvV9qm8wsJOw5CIsTP2uMQuRPgT0ltYPa1dXdS99LZuE=;
	7:MKe1+bvqKSjQiS+l+PkOzXZsARHz7CL75UtYATOojoY8kuBbtY/ili3bdStZ2vKjwPk8jDuAkHx0DXxlgF6TKbReCDKn9CGGkbncYAhH8Xl87gWFW8S0QIuIqFFs9rvmfJXoi8gXcldXpH/m7i6lkMI7rV6wTfKyREiyZ52ZGkoBHBTjEZaXe23A655tOD0697t6beOuFHFzcgBgz92qS7SF9uLliz3LqnY6eRrgpGm4sqcDpWFE8UstL/14U2Ics7QUe0g5eiDSsfR/OOSqOeeHzjh44tvP9dRgQBKloKhTKY6X0eiQqS++g2XAmwux
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900015);
	DIR:OUT; SFP:1102; SCL:1; SRVR:BY2NAM01HT093;
	H:BL2PR03MB435.namprd03.prod.outlook.com; FPR:; SPF:None;
	LANG:en; 
x-ms-office365-filtering-correlation-id: 0f3f015a-6d97-4842-9792-08d46318307b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1603101448)(1601125254)(1701031045);
	SRVR:BY2NAM01HT093; 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
	RULEID:(432015087)(444000031); SRVR:BY2NAM01HT093; BCL:0; PCL:0;
	RULEID:; SRVR:BY2NAM01HT093; 
x-forefront-prvs: 0236114672
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BL2PR03MB435C5077E69D91D0A8092B6EE2A0BL2PR03MB435namprd_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2017 16:04:50.5790 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM01HT093
X-OriginalArrivalTime: 04 Mar 2017 16:04:52.0360 (UTC)
	FILETIME=[0ED65880:01D29501]
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
Subject: [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: Sat, 04 Mar 2017 16:04:53 -0000

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

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

--_000_BL2PR03MB435C5077E69D91D0A8092B6EE2A0BL2PR03MB435namprd_
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" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Arial,Helvetica,sans-serif;" dir=3D"ltr">
<p><span id=3D"docs-internal-guid-1be5245f-9a0e-19aa-bd44-cdeb0d05121c"></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: tran=
sparent; vertical-align: baseline; white-space: pre-wrap;">The discussion o=
f UASF got me thinking about whether such
 a method might lead to sybil attacks, with new nodes created purely to inf=
late the node count for a particular implementation in an attempt at social=
 engineering.</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: tran=
sparent; vertical-align: baseline; white-space: pre-wrap;">I had an idea fo=
r 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: tran=
sparent; 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 Bitcoin 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: tran=
sparent; vertical-align: baseline; white-space: pre-wrap;">The node on firs=
t installation generates and backs up
 a private key. The corresponding public key becomes that node=92s unique i=
dentifier. 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: tran=
sparent; vertical-align: baseline; white-space: pre-wrap;">Asking a node fo=
r its identifier can be done by sending
 a message the command =91identify=92 and a challenge. The node can then re=
spond with its unique identifier and a signature for the challenge to prove=
 it. The node can also include what software it is running and sign this in=
formation 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: tran=
sparent; 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: tran=
sparent; 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: tran=
sparent; vertical-align: baseline; white-space: pre-wrap;">Any register of =
active nodes can have a record of when
 a node identifier was =93first seen=94, and how many IPs the same identifi=
er has broadcast from. Also, crucially, we could see what software the node=
 operator 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: tran=
sparent; vertical-align: baseline; white-space: pre-wrap;">This information=
 would make it easy to identify patterns.
 For example if a huge new group of nodes appeared on the network with no h=
istory 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 =
extended period of time started
 switching to a rival implementation, this would add credibility but not ce=
rtainty (keys 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: tran=
sparent; vertical-align: baseline; white-space: pre-wrap;">This would be tr=
ivial 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: tran=
sparent; vertical-align: baseline; white-space: pre-wrap;">Keen to hear any=
 thoughts?</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: tran=
sparent; 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: tran=
sparent; 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: tran=
sparent; vertical-align: baseline; white-space: pre-wrap;">john@seebitcoin.=
com</span></p>
</span>
<p></p>
</div>
</body>
</html>

--_000_BL2PR03MB435C5077E69D91D0A8092B6EE2A0BL2PR03MB435namprd_--