Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 26034E58 for ; Sun, 5 Mar 2017 13:57:12 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from COL004-OMC3S9.hotmail.com (col004-omc3s9.hotmail.com [65.55.34.147]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DECBA127 for ; Sun, 5 Mar 2017 13:57:10 +0000 (UTC) Received: from NAM04-SN1-obe.outbound.protection.outlook.com ([65.55.34.135]) by COL004-OMC3S9.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 5 Mar 2017 05:57:10 -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=WhG0g7+8aCfFglxOUvbPjF8d0c0mbeZ10Zwz0V4uR5I=; b=Hx5+QRkyRhJCn8/9Erg7CVsDzYppNUqyPiwhQZgPum36sN2dLqLaFK0CE7nt5YLkNcXMjBhzRcUS/Oyf86hFgLrsOXYfJDzH3ZW25JuBPhK5ggys64FWKscfdjuQDp7RDNra2pVWlWh7+WB6BeuinJEDbiB+KIKcMVS3cfJcY1kAeh6fw1w33JfCzkw05M1qAuw5a4sqnO4Rda6HxiBNKfvOHp9l2PIiqtQUL77jWzh7TBa4BEHkXAeK7bh+jeHzr00bYYwyhN4BTx0StX+jj9Rg5rNQR6NCf0rjHDkMxDC3Hm/I2Gp1MI16cxsK+vAdFNUEg4yNlFtCgKoV1OYJog== Received: from SN1NAM04FT036.eop-NAM04.prod.protection.outlook.com (10.152.88.57) by SN1NAM04HT171.eop-NAM04.prod.protection.outlook.com (10.152.88.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.11; Sun, 5 Mar 2017 13:57:09 +0000 Received: from BL2PR03MB435.namprd03.prod.outlook.com (10.152.88.60) by SN1NAM04FT036.mail.protection.outlook.com (10.152.89.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.11 via Frontend Transport; Sun, 5 Mar 2017 13:57:09 +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 13:57:09 +0000 From: John Hardy To: Btc Drak , "bitcoin-dev@lists.linuxfoundation.org" Thread-Topic: [bitcoin-dev] Unique node identifiers Thread-Index: AQHSlQC2uBBD8WtSHEG5hC7gQs1fHKGGPl4AgAAHMJQ= Sender: John Hardy Date: Sun, 5 Mar 2017 13:57:08 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; gmail.com; dmarc=none action=none header.from=seebitcoin.com; x-incomingtopheadermarker: OriginalChecksum:6D07575D25BB3BFCDC49B1BDC805A0571232D5B2DF19B1DD6D1EEECCDCDBA23D; UpperCasedChecksum:047048BA838BC3B6E12D7EE4F85AF1ADE3E754EA5EF975F93018FFBE5EDCD1E5; SizeAsReceived:7968; Count:40 x-ms-exchange-messagesentrepresentingtype: 2 x-tmn: [f2hgQcog9Mmxw5aYoQhnOPmmjhG0XmAP] x-incomingheadercount: 40 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; SN1NAM04HT171; 5:8cG5jLY2GLgQiMU+B4C4B8/0K9Z8iSC18sFnFBP9+z021cEtE4sk3zM/ClIGf4gd02QNK4RwMYBW1JGT0cE6e2cpYlLYMC8e9ttLotrH1MgRdup5LiLqCyFuQfNa2AJq079MygwahBOfAz7ZwVY0OA==; 24:7JtIDvrIAkbw3j5k7fTe3j+4He2TCPeWmCWafVdFrYUBzyEJRAAqvJYvEwiGDNcg11hLPz7KNRkNsKK1tC5xN0m+cTRMEZ2N54A/TQXRSp0=; 7:qYkc9iHFyV8v+mYAHejB5uHHYgPEWxXOS89rHs+pGToj5QxQ3z/KzvdxIQj7afTLfVC783++q4j9Utll+6ahMfK6wAORSLe9dOzuIOOMcXGxZpMDa4wE0fC4VSFC7qlFvB83gahLK9zM70p5jp8qEkhdaK6CLjY2LAnfIgfJCnBXh8gM6Yer6V2xjU3oBrgFXkx+G7itF+B3MHXgvJ3+EmICaeLO/st7Ty2Xnkuei5p4AFx444RYicCVVOiwC0+cNkV6ADGsbbwFx17Tm0sUm9LmnjSktWas3cKepsP5/4PNqgepd+ZiLsMAlZdkA6Oa x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900015); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM04HT171; H:BL2PR03MB435.namprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 59454b5e-bad5-42c8-19eb-08d463cf8417 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1603101448)(1601125254)(1701031045); SRVR:SN1NAM04HT171; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015087)(444000031); SRVR:SN1NAM04HT171; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM04HT171; x-forefront-prvs: 02379661A3 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL2PR03MB435029A0856DC7077D4AD68EE2D0BL2PR03MB435namprd_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2017 13:57:08.7975 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT171 X-OriginalArrivalTime: 05 Mar 2017 13:57:10.0383 (UTC) FILETIME=[625B2FF0:01D295B8] 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: Tue, 07 Mar 2017 14:08:07 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 13:57:12 -0000 --_000_BL2PR03MB435029A0856DC7077D4AD68EE2D0BL2PR03MB435namprd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > Nodes are by design not supposed to be identifiable in any way I feel you're conflating social identifiability with technical identifiabil= ity. Sure, a node operator must always be able to remain anonymous, but nod= es themselves require a certain level of identifiability otherwise there wo= uld be no means to communicate between them. I agree that absolute node counts have their limitations, but that doesn't = stop them being used as a measure and even propaganda tool. If something li= ke this is a way to help highlight the latter when it is occurring I think = it has value. I 'm not convinced that node identifiers or identity persiste= nce would have any meaningful impact on privacy, though am open to being co= nvinced otherwise. ________________________________ From: Btc Drak Sent: Sunday, March 5, 2017 1:27 PM To: John Hardy; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Unique node identifiers Nodes are by design not supposed to be identifiable in any way, including p= ersisting identities across IPs changes or when connecting over different n= etworks (e.g. clearnet/tor). Anything that makes Bitcoin less private is a = step backwards. Also absolute node count is pretty meaningless since only f= ully validating nodes that participate in economic activity really matter. As a side note, this should probably have started out as a bitcoin-discuss = post. On Sat, Mar 4, 2017 at 4:04 PM, John Hardy via bitcoin-dev > 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --_000_BL2PR03MB435029A0856DC7077D4AD68EE2D0BL2PR03MB435namprd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

> Nodes are by design not supposed to be identifiable in = any way

I feel you're conflating social identifiability with technical identif= iability. Sure, a node operator must always be able to remain anonymous, bu= t nodes themselves require a certain level of identifiability otherwise the= re would be no means to communicate between them.

I agree that absolute node counts have their limitations, but that doe= sn't stop them being used as a measure and even propaganda tool. If somethi= ng like this is a way to help highlight the latter when it is occurring I t= hink it has value. I 'm not convinced that node identifiers or identity persistence would have any meaningful im= pact on privacy, though am open to being convinced otherwise.



From: Btc Drak <btcdrak@= gmail.com>
Sent: Sunday, March 5, 2017 1:27 PM
To: John Hardy; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Unique node identifiers
 
Nodes are by design not supposed to be identifiable in any= way, including persisting identities across IPs changes or when connecting= over different networks (e.g. clearnet/tor). Anything that makes Bitcoin l= ess private is a step backwards. Also absolute node count is pretty meaningless since only fully validating node= s that participate in economic activity really matter.

As a side note, this should probably have started out as a bitcoin-dis= cuss post.

On Sat, Mar 4, 2017 at 4:04 PM, John Hardy via b= itcoin-dev <bitcoin-dev@lists.linuxfoundation.org> = wrote:

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.


I had an idea for 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 Bit= coin address.


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.


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.


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


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.


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.


Keen to hear any thou= ghts?


Thanks,


John Hardy

john@seebitcoin.com


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--_000_BL2PR03MB435029A0856DC7077D4AD68EE2D0BL2PR03MB435namprd_--