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 9DC97C06 for ; Tue, 7 Mar 2017 18:44:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f48.google.com (mail-pg0-f48.google.com [74.125.83.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A33BD172 for ; Tue, 7 Mar 2017 18:44:10 +0000 (UTC) Received: by mail-pg0-f48.google.com with SMTP id 77so3481952pgc.1 for ; Tue, 07 Mar 2017 10:44:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H+5E7cGvifF45UNkCF6MGxg0t1UDBpMtW30Sa8j7hPI=; b=Xe8adFEFG/XpOWE8+49Iaozc4e1vViZKXJPsNmrH8iXyh7sXeTX64VxlEPCQCWU9CI 3v6baY/6jwv2j1rarLZg3or+uukv0MUZAHqo7YipBisptIA81elGlTUP8tQLrFbEIXkt asNuJ88TPOGGvwP85F8haEu4IY+SO/+uzTpMNCvNSE9zq2FS5znm5BpXYc+XngSx8zPN +/JiKDWx/FuVr7WiL/2Ve7m4TwmaKC6RDRm8ehTVBlcQYeRn6IUuIsNVWH9Ak5/pWNt1 4Cs+iIgc5bIJXtRryTgz0uhXDbyapDyYZA9fXfp3nIWZa6VmtV8TwK47Givis35KB86L EneA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H+5E7cGvifF45UNkCF6MGxg0t1UDBpMtW30Sa8j7hPI=; b=pNnIDXy9H09vjMYgr1APM5UrXQQigERt2UNUDU2CsV+nMyyKZ/uaR2h3oY8j8pnw8B E7nGilE/OSHju6Xxdb6TmfRl5ohjEPKUbPcXQ+wYf9rBKMiraZDrYcbTSL0nUHPNHJID oFuixrViXXX4DTVPUSKY/GE4D5AFxxV5xPmU+BIj8KZnpdYfUkbmokL5OVZafQgOfoT0 98a4QatrkQU7xenXhfglOUMkW4Q3NV7/bTtmIUnHFLFoinJxAolCzFN+orDkihej4U1q 440qZJdQTIC7A9VUmZizi8qk73FkLZqgkDRARG4AMkOKNo3kw3fBht4HtpeZYiAQRNQs G0Tw== X-Gm-Message-State: AMke39m4DgPdJLFGWdLw7Lr1Gs7HBR8FmnMfqXp78uRhqTrBe04NDT9smzCJP6TI7h7OdA== X-Received: by 10.84.179.99 with SMTP id a90mr2567365plc.26.1488912250265; Tue, 07 Mar 2017 10:44:10 -0800 (PST) Received: from [10.214.35.120] (mobile-166-176-184-131.mycingular.net. [166.176.184.131]) by smtp.gmail.com with ESMTPSA id d68sm1218957pfj.92.2017.03.07.10.44.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 10:44:09 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-D1DCE535-19CB-47A9-8730-83951EBC965B Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Tue, 7 Mar 2017 10:44:07 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: To: John Hardy , Bitcoin Protocol Discussion X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,MIME_QP_LONG_LINE,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: Tue, 07 Mar 2017 18:50:36 +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: Tue, 07 Mar 2017 18:44:11 -0000 --Apple-Mail-D1DCE535-19CB-47A9-8730-83951EBC965B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Mar 5, 2017, at 5:57 AM, John Hardy via bitcoin-dev wrote: >=20 > > Nodes are by design not supposed to be identifiable in any way This is of course my objection to BIP150 ("a way for peers to ... guarantee n= ode ownership"). > I feel you're conflating social identifiability with technical identifiabi= lity. Sure, a node operator must always be able to remain anonymous, but nod= es themselves require a certain level of identifiability otherwise there wou= ld be no means to communicate between them. Anonymous node identity is pointless, and is why I object to BIP151. It prov= ides no actual security/privacy benefit and is a stepping stone to non-anony= mous node identity (e.g. BIP150). > 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 i= t has value. I 'm not convinced that node identifiers or identity persistenc= e would have any meaningful impact on privacy, though am open to being convi= nced otherwise. Bitcoin does not require node counts, and this proposal is redundant with BI= P150. e >=20 > From: Btc Drak > Sent: Sunday, March 5, 2017 1:27 PM > To: John Hardy; Bitcoin Protocol Discussion > Subject: Re: [bitcoin-dev] Unique node identifiers > =20 > Nodes are by design not supposed to be identifiable in any way, including p= ersisting identities across IPs changes or when connecting over different ne= tworks (e.g. clearnet/tor). Anything that makes Bitcoin less private is a st= ep backwards. Also absolute node count is pretty meaningless since only full= y validating nodes that participate in economic activity really matter. >=20 > As a side note, this should probably have started out as a bitcoin-discuss= post. >=20 >> 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 lead to sybil attacks, with new nodes created purely to inf= late the node count for a particular implementation in an attempt at social e= ngineering. >>=20 >> I had an idea for an anonymous, opt-in, unique node identification >> mechanism to help counter this. >>=20 >> 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. >>=20 >> The node on first installation generates and backs up a private >> key. The corresponding public key becomes that node=E2=80=99s unique ide= ntifier. If the node switches to a new software version or a new IP, the ide= ntifier can remain constant if the node operator chooses. >>=20 >> 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 the= n respond with its unique identifier and a signature for the challenge to pr= ove it. The node can also include what software it is running and sign this i= nformation so it can be verified as legitimate >> by third parties. >>=20 >> Why would we do this? >>=20 >> Well, it adds a small but very useful piece of data when compiling >> lists of active nodes. >>=20 >> 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 i= dentifier has broadcast from. Also, crucially, we could see what software th= e node operator has been seen running historically. >>=20 >> This information would make it easy to identify patterns. For >> example if a huge new group of nodes appeared on the network with no his= tory for their identifier they could likely be dismissed as sybil attacks. I= f 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 (= keys could be traded), that the shift was more organic. >>=20 >> 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 ide= ntity, but with the freedom to opt-out at any time. >>=20 >> Keen to hear any thoughts? >>=20 >> Thanks, >>=20 >> John Hardy >> john@seebitcoin.com >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-D1DCE535-19CB-47A9-8730-83951EBC965B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Mar 5, 20= 17, at 5:57 AM, John Hardy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wr= ote:

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

This is o= f course my objection to BIP150 ("a way for peers to ... guarantee node ownership").
I feel you're conflating social identifiability with technical identifi= ability. Sure, a node operator must always be able to remain anonymous, but n= odes themselves require a certain level of identifiability otherwise there w= ould be no means to communicate between them.

Anonymous n= ode identity is pointless, and is why I object to BIP151. It provides no act= ual security/privacy benefit and is a stepping stone to non-anonymous node i= dentity (e.g. BIP150).

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

Bitcoin does not require node counts, and= this proposal is redundant with BIP150.

e
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 w= ay, including persisting identities across IPs changes or when connecting ov= er different networks (e.g. clearnet/tor). Anything that makes Bitcoin less p= rivate 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-disc= uss post.

On Sat, Mar 4, 2017 at 4:04 PM, John Hardy via bi= tcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wr= ote:

The discussion of UASF g= ot me thinking about whether such a method might lead to sybil attacks, with new nodes created purely to inflat= e the node count for a particular implementation in an attempt at social eng= ineering.


I had an idea for an ano= nymous, opt-in, unique node identification mechanism to help counter this.


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


The node on first instal= lation generates and backs up a private key. The corresponding public key becomes that node=E2=80=99s unique identi= fier. If the node switches to a new software version or a new IP, the identi= fier can remain constant if the node operator chooses.


Asking a node for its id= entifier can be done by sending a message the command =E2=80=98identify=E2=80=99 and a challenge. The node can then r= espond 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 inf= ormation so it can be verified as legitimate by third parties.


Why would we do this?


Well, it adds a small bu= t very useful piece of data when compiling lists of active nodes.


Any register of active n= odes can have a record of when a node identifier was =E2=80=9Cfirst seen=E2=80=9D, and how many IPs the same iden= tifier has broadcast from. Also, crucially, we could see what software the n= ode operator has been seen running historically.


This information would m= ake it easy to identify patterns. For example if a huge new group of nodes appeared on the network with no histor= y 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 extende= d period of time started switching to a rival implementation, this would add credibility but not certainty (ke= ys 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 identi= ty, but with the freedom to opt-out at any time.


Keen to hear any thought= s?


Thanks,


John Hardy

john@seebitcoin.com


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.<= wbr>linuxfoundation.org
https://lists.linuxfoundation.org/m= ailman/listinfo/bitcoin-dev


____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-D1DCE535-19CB-47A9-8730-83951EBC965B--