summaryrefslogtreecommitdiff
path: root/39
diff options
context:
space:
mode:
authorJohn Hardy <john@seebitcoin.com>2017-03-05 12:55:27 +0000
committerbitcoindev <bitcoindev@gnusha.org>2017-03-05 12:55:40 +0000
commitb76cc62ba529f2178df8ee8233dee1111f5c203f (patch)
tree1ecc6165f224674a82d68f8703e9e1d40c80b652 /39
parentaed01a0d0a1f287b3ba24b0bec5114c4b47205ad (diff)
downloadpi-bitcoindev-b76cc62ba529f2178df8ee8233dee1111f5c203f.tar.gz
pi-bitcoindev-b76cc62ba529f2178df8ee8233dee1111f5c203f.zip
Re: [bitcoin-dev] Unique node identifiers
Diffstat (limited to '39')
-rw-r--r--39/7d0bf06881a9c8454f48192f2a834c73a1559d465
1 files changed, 465 insertions, 0 deletions
diff --git a/39/7d0bf06881a9c8454f48192f2a834c73a1559d b/39/7d0bf06881a9c8454f48192f2a834c73a1559d
new file mode 100644
index 000000000..21924e701
--- /dev/null
+++ b/39/7d0bf06881a9c8454f48192f2a834c73a1559d
@@ -0,0 +1,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_--
+