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-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_--