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 1DB501276 for ; Sun, 5 Mar 2017 06:29:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com [209.85.213.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0D765AC for ; Sun, 5 Mar 2017 06:29:17 +0000 (UTC) Received: by mail-vk0-f51.google.com with SMTP id x75so21893739vke.2 for ; Sat, 04 Mar 2017 22:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamin-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=EwQlRpfVkDJRQ/LeHgN3qj2GxslJZLQfXLVibNpO/Wk=; b=FJ38dQiFrbYxmARt0WhG95GgBvsdBMxy4bMykwGHixGyt1UbEZ+FK8t12CjO7HCpoY voDefx2wKbcMvTpULLEEt9o++42AJCRUVVPy0+kXpIF524musN+OtkOu+XL3BqAVR4Li IuBodb9AKBWEv0gbppR5+yOV++r5rZuHKikog3+d37dQxysN6v8nvhXfWG9xEeaj0HxL KfUCrTgZ0Mf5QWdnqSqrI+dyu3d2H/eGMXv/5LEoip1pyENd/feHXlpQRUzfY6brf/yU UXaSUEIKJ1LDpu6vO9I87XnFH4OFou4pPPo2ask9HkgakS9UzINbthYaI7MBQWX4WASP s9ZA== 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=EwQlRpfVkDJRQ/LeHgN3qj2GxslJZLQfXLVibNpO/Wk=; b=jm7zB5DNNt18Q7K6M4YqdOesyj9NVBaDCjcwF8HUyz9J7IuPTblG0/2LVizOBA894N Y4IdmL/FDCn/yFCb81eWQGFlWmsVoTIe+pk+kEMnVWmS2Qb53rLBdS2EJpmx4g7jbJtR B5soDlAiEQPLVWRfC2gbS964BtvxuWB8eFd5rnUt7zCetYLCZjuEKWYSco0XlfWLpHn/ sXvy/gVniC1DQrBWOvYNsXC+Ct+3fgnvLbmG9L+Iq/r51Vwq2VzC/N/OHcAz1hpbI4rN udSeDCKog9HFZgJcPBLedd0xBANrA5KBFeLmHN2yQbgLFcmOQHmx9DcXNZ3OUxfJrGPB UtwA== X-Gm-Message-State: AMke39m919wjoq5aIcVFnMyRw+aTHrJteKPIGAL+g4C3Q7kvzxmZNchAkwtsx6NHOOilYbKb1QAd7g2GfQcWsQ== X-Received: by 10.31.190.142 with SMTP id o136mr4544889vkf.73.1488695356892; Sat, 04 Mar 2017 22:29:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.30.194 with HTTP; Sat, 4 Mar 2017 22:29:16 -0800 (PST) In-Reply-To: References: From: Marcel Jamin Date: Sun, 5 Mar 2017 07:29:16 +0100 Message-ID: To: John Hardy , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a1143a674ed3b800549f5e542 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham 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:12:41 +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 06:29:19 -0000 --001a1143a674ed3b800549f5e542 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > This could even come in the form of a Bitcoin address. Wouldn't this actually *need* to be a bitcoin address that is included in a block to get any real assurances about the age if this node id? Otherwise malicous nodes could lie and claim to have seen a brand new node id years ago already. Even if included in a block, people could sell their aged IDs (if we were to rely on those for anything). Also funding that ID address would might tie your economic activity (or even identity) to a node. On 4 March 2017 at 17:04, 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 > > --001a1143a674ed3b800549f5e542 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0This could even come in the form of a Bitcoin address.

Wouldn't this actually *need* to be a = bitcoin address that is included in a block to get any real assurances abou= t the age if this node id? Otherwise malicous nodes could lie and claim to = have seen a brand new node id years ago already.

Even if included in a block, people could sell th= eir aged IDs (if we were to rely on those for anything).

Also funding that ID address would might = tie your economic activity (or even identity) to a node.
=

On 4 March 2017 a= t 17:04, 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 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


--001a1143a674ed3b800549f5e542--