From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <btcdrak@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7D7271031 for <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; Sun, 5 Mar 2017 13:27:29 +0000 (UTC) Received: by mail-yw0-f170.google.com with SMTP id o4so43371280ywd.3 for <bitcoin-dev@lists.linuxfoundation.org>; 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: <BL2PR03MB435C5077E69D91D0A8092B6EE2A0@BL2PR03MB435.namprd03.prod.outlook.com> References: <BL2PR03MB435C5077E69D91D0A8092B6EE2A0@BL2PR03MB435.namprd03.prod.outlook.com> From: Btc Drak <btcdrak@gmail.com> Date: Sun, 5 Mar 2017 13:27:08 +0000 Message-ID: <CADJgMzvuii8Ww822v3DRa=-Azuqo4va6s32MsNSC-6M9=stm1Q@mail.gmail.com> To: John Hardy <john@seebitcoin.com>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 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 <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 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 <div dir=3D"ltr">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.<div><br></div><div>As a side note, this should probably ha= ve started out as a bitcoin-discuss post.</div></div><div class=3D"gmail_ex= tra"><br><div class=3D"gmail_quote">On Sat, Mar 4, 2017 at 4:04 PM, John Ha= rdy via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lis= ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation= .org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir=3D"ltr"> <div id=3D"m_9138875837303793420divtagdefaultwrapper" style=3D"font-size:12= pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" dir=3D"ltr= "> <p><span id=3D"m_9138875837303793420docs-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:transparen= t;vertical-align:baseline;white-space:pre-wrap">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.</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:transparen= t;vertical-align:baseline;white-space:pre-wrap">I had an idea for an anonym= ous, 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:transparen= t;vertical-align:baseline;white-space:pre-wrap">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.</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:transparen= t;vertical-align:baseline;white-space:pre-wrap">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.</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:transparen= t;vertical-align:baseline;white-space:pre-wrap">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.</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:transparen= t;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:transparen= t;vertical-align:baseline;white-space:pre-wrap">Well, it adds a small but v= ery 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:transparen= t;vertical-align:baseline;white-space:pre-wrap">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.</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:transparen= t;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:transparen= t;vertical-align:baseline;white-space:pre-wrap">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.</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:transparen= t;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:transparen= t;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:transparen= t;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:transparen= t;vertical-align:baseline;white-space:pre-wrap"><a href=3D"mailto:john@seeb= itcoin.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> --94eb2c064ed285bc250549fbbd15--