Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7D7271031 for ; Sun, 5 Mar 2017 13:27:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f170.google.com (mail-yw0-f170.google.com [209.85.161.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AAECD140 for ; Sun, 5 Mar 2017 13:27:29 +0000 (UTC) Received: by mail-yw0-f170.google.com with SMTP id o4so43371280ywd.3 for ; Sun, 05 Mar 2017 05:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=gl6Pwzi623yFvIRO2v0ErH9gc9sKxiu34O1tIrXRHNk=; b=EysVZtx9xQ45Zt97zqeTNFj4rSd3sMgnqDZN37fx1C7iIpAPbij7ww2JNAI0Yp8gmX 0EnjclJQiDdXG/XeHyornA0A0PpM1+SbH3fn/4qenDWEk2A8n6i3Dg35cTk+1d0tLYTS ZFhVbc1E3TIjiYItj4xRpUOSVS+N0Vj32trZwvB84wrAS+1AS7WZ37gT1WnC57lY8afb cEb4r4EWkHKNzOaLxrlsInGx3cVh6MNmAr6qJ7cW2j+HMbOIcIHehyrr79q4BdDviRbs 64fvuWpNdw/d/gtIl+ggGUvqlBXDMnF0S2sezDOOk/iLZ9N5uD7XlkTgivUbjrOpT+Cz Casw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=gl6Pwzi623yFvIRO2v0ErH9gc9sKxiu34O1tIrXRHNk=; b=Boh3OMfbugCNfWKbI3dqPjhFDoTWnAQKCQiI5qG1nW9CAK6MD/N+S15R+KAK97yerA FZjxMkZvrIh7fYVXEka/D7qzRVS0y0kTrZDs/eY2wqFjSoZQoGeRy2ZJfgNSoJKDgQHv V34QBgYGKX5dQS7gHcyapqThyw+DuSiO0GcmWyUClqRQJS14nIIAuEiROV5Yd/qYxXEH LpAIaG0kjCibN22l/2MBl+20wpAGzEGM+EU4zVSm1/m2aFQS7Nm6NjiRIMBs6dGrgF60 QOTL+8rUK00kstTGVbIFdenxZz2GdyFogEELpTqqm01xpQBmBjZyaUy0+/XEgPAkeFE+ mSnw== X-Gm-Message-State: AMke39mYiG3e2GD1AkGmK9szhQQVGJx5y6lXcIS6zYVx1xJqsXacAmULN8LIeXmnZHsrK8sCKzQwHnReQ/eeXg== X-Received: by 10.13.221.19 with SMTP id g19mr7706830ywe.21.1488720448817; Sun, 05 Mar 2017 05:27:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.134.131 with HTTP; Sun, 5 Mar 2017 05:27:08 -0800 (PST) In-Reply-To: References: From: Btc Drak Date: Sun, 5 Mar 2017 13:27:08 +0000 Message-ID: To: John Hardy , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c064ed285bc250549fbbd15 X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM 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:34:23 +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:27:30 -0000 --94eb2c064ed285bc250549fbbd15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 less private is a step backwards. Also absolute node count is pretty meaningless since only fully 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 < bitcoin-dev@lists.linuxfoundation.org> wrote: > The discussion of UASF got me thinking about whether such a method might > lead to sybil attacks, with new nodes created purely to inflate the node > count for a particular implementation in an attempt at social engineering= . > > 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 > =E2=80=98address=E2=80=99/unique 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 > corresponding public key becomes that node=E2=80=99s unique identifier. I= f 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 =E2=80=98identify=E2=80=99 and a challenge. The node can then res= pond 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 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 > was =E2=80=9Cfirst seen=E2=80=9D, and how many IPs the same identifier ha= s 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 > 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 ad= d > credibility but not certainty (keys 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 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 > > --94eb2c064ed285bc250549fbbd15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 meaning= less since only fully validating nodes that participate in economic activit= y really matter.

As a side note, this should probably ha= ve started out as a bitcoin-discuss post.

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

= The discussion of 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 for an anonym= ous, opt-in, unique node identification mechanism to help counter this.


= This would give every node = the opportunity to create a node =E2=80=98address=E2=80=99/unique identifier. This could even come in = the form of a Bitcoin address.


= The node on first installat= ion generates and backs up a private key. The corresponding public key becomes that node=E2=80=99s un= ique 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 ident= ifier can be done by sending a message the command =E2=80=98identify=E2=80=99 and a challenge. The node= can then respond with its unique identifier and a signature for the challe= nge to prove it. The node 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 v= ery useful piece of data when compiling lists of active nodes.


= Any register of active node= s can have a record of when a node identifier was =E2=80=9Cfirst seen=E2=80=9D, and how many IPs the s= ame identifier has broadcast from. Also, crucially, we could see what softw= are 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 trivial to im= plement, 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?<= /span>


= Thanks,


= John Hardy

= john@seebitcoin.com


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


--94eb2c064ed285bc250549fbbd15--