path: root/9d/68b6816303cb3ac48da549fbc7044d8fae5f51

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">&lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt;</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--