path: root/ef/92e0b9232071d6397d769d8e422bd0da298112

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9DC97C06
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  7 Mar 2017 18:44:10 +0000 (UTC)
Received: by mail-pg0-f48.google.com with SMTP id 77so3481952pgc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <eric@voskuil.org>
X-Mailer: iPhone Mail (14D27)
In-Reply-To: <BL2PR03MB435029A0856DC7077D4AD68EE2D0@BL2PR03MB435.namprd03.prod.outlook.com>
Date: Tue, 7 Mar 2017 10:44:07 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <D4B674DB-8F2E-4AA1-B271-FEE02A62A274@voskuil.org>
References: <BL2PR03MB435C5077E69D91D0A8092B6EE2A0@BL2PR03MB435.namprd03.prod.outlook.com>
	<CADJgMzvuii8Ww822v3DRa=-Azuqo4va6s32MsNSC-6M9=stm1Q@mail.gmail.com>
	<BL2PR03MB435029A0856DC7077D4AD68EE2D0@BL2PR03MB435.namprd03.prod.outlook.com>
To: John Hardy <john@seebitcoin.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <bitcoin-dev@lists.=
linuxfoundation.org> 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 <btcdrak@gmail.com>
> 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 <bitcoin-dev@l=
ists.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 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

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div></div><div><br></div><div>On Mar 5, 20=
17, at 5:57 AM, John Hardy via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wr=
ote:<br><br></div><blockquote type=3D"cite"><div>

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-12=
52">



<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font-=
family:Calibri,Arial,Helvetica,sans-serif;" dir=3D"ltr">
<p></p>
<div><span style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font=
-size: 16px;">&gt; Nodes are by design not supposed to be identifiable in an=
y way</span><br></div></div></div></blockquote><div><br></div><div>This is o=
f course my objection to BIP150 ("<span style=3D"background-color: rgba(255,=
 255, 255, 0);">a way for peers to ... guarantee node ownership").</span></d=
iv><br><blockquote type=3D"cite"><div><div id=3D"divtagdefaultwrapper" style=
=3D"font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-se=
rif;" dir=3D"ltr"><div>
</div>

<div>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.</div></div></div></blockquote><div><br></div><div>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).</div><br><blockquote type=3D"cite"><div><div id=3D"di=
vtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font-family:Calibr=
i,Arial,Helvetica,sans-serif;" dir=3D"ltr">
<div>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.</div></div></di=
v></blockquote><div><br></div><div>Bitcoin does not require node counts, and=
 this proposal is redundant with BIP150.</div><div><br></div><div>e</div><br=
><blockquote type=3D"cite"><div><div id=3D"divtagdefaultwrapper" style=3D"fo=
nt-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;" d=
ir=3D"ltr">
<div style=3D"color: rgb(0, 0, 0);">
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" col=
or=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Btc Drak &lt;<a href=3D=
"mailto:btcdrak@gmail.com">btcdrak@gmail.com</a>&gt;<br>
<b>Sent:</b> Sunday, March 5, 2017 1:27 PM<br>
<b>To:</b> John Hardy; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] Unique node identifiers</font>
<div>&nbsp;</div>
</div>
<div>
<div dir=3D"ltr">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.
<div><br>
</div>
<div>As a side note, this should probably have started out as a bitcoin-disc=
uss post.</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Sat, Mar 4, 2017 at 4:04 PM, John Hardy via bi=
tcoin-dev
<span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex; border-left:1p=
x #ccc solid; padding-left:1ex">
<div dir=3D"ltr">
<div id=3D"m_9138875837303793420divtagdefaultwrapper" dir=3D"ltr" style=3D"f=
ont-size:12pt; color:#000000; font-family:Calibri,Arial,Helvetica,sans-serif=
">
<p><span id=3D"m_9138875837303793420docs-internal-guid-1be5245f-9a0e-19aa-bd=
44-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:transpar=
ent; vertical-align:baseline; white-space:pre-wrap">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.</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:transpar=
ent; vertical-align:baseline; white-space:pre-wrap">I had an idea for an ano=
nymous, 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:transpar=
ent; vertical-align:baseline; white-space:pre-wrap">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.</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:transpar=
ent; vertical-align:baseline; white-space:pre-wrap">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.</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:transpar=
ent; vertical-align:baseline; white-space:pre-wrap">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.</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:transpar=
ent; vertical-align:baseline; white-space:pre-wrap">Why would we do this?</s=
pan></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:transpar=
ent; vertical-align:baseline; white-space:pre-wrap">Well, it adds a small bu=
t very 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:transpar=
ent; vertical-align:baseline; white-space:pre-wrap">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.</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:transpar=
ent; vertical-align:baseline; white-space:pre-wrap">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.</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:transpar=
ent; vertical-align:baseline; white-space:pre-wrap">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.</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:transpar=
ent; vertical-align:baseline; white-space:pre-wrap">Keen to hear any thought=
s?</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:transpar=
ent; 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:transpar=
ent; 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:transpar=
ent; vertical-align:baseline; white-space:pre-wrap"><a href=3D"mailto:john@s=
eebitcoin.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" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/m=
ailman/listinfo/bitcoin-<wbr>dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>


</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></=
html>=

--Apple-Mail-D1DCE535-19CB-47A9-8730-83951EBC965B--