From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D8A90826 for ; 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 ; 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 To: "bitcoin-dev@lists.linuxfoundation.org" Thread-Topic: Unique node identifiers Thread-Index: AQHSlQC2uBBD8WtSHEG5hC7gQs1fHA== Sender: John Hardy Date: Sat, 4 Mar 2017 16:04:50 +0000 Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

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.


I had an idea fo= r an anonymous, opt-in, unique node identification mechanism to help counter this.


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.


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.


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.


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


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.


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.


Keen to hear any= thoughts?


Thanks,

John Hardy

john@seebitcoin.= com

--_000_BL2PR03MB435C5077E69D91D0A8092B6EE2A0BL2PR03MB435namprd_--