Re: [bitcoin-dev] Unique node identifiers

[Eric Voskuil via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Reposting this response since this made it neither to distribution nor
to the moderation archive.


-  Forwarded Message 
Subject: Re: [bitcoin-dev] Unique node identifiers
Date: Wed, 8 Mar 2017 18:59:42 -0800
From: Eric Voskuil <e...@voskuil.org>
To: Pieter Wuille <pieter.wui...@gmail.com>
CC: Jonas Schnelli <d...@jonasschnelli.ch>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>, Libbitcoin Development
<libbitc...@lists.dyne.org>

On 03/08/2017 05:55 PM, Pieter Wuille wrote:
> On Wed, Mar 8, 2017 at 5:16 PM, Eric Voskuil <e...@voskuil.org>
> wrote:
>> On 03/08/2017 03:12 PM, Pieter Wuille wrote:
>>> In that way, I see BIP150 as an extension of IP addresses,
>>> except more secure against network-level attackers. If you
>>> believe the concept of people establishing links along existing
>>> trust lines is a problem, you should be arguing against
>>> features in Bitcoin software that allows configuring preferred
>>> IP addresses to connect to as well (-addnode and -connect in
>>> Bitcoin Core, for example).
>> 
>> Weak identity is insufficient to produce the problem scenario
>> that is at the heart of my concern (excluding people). It is this
>> "[same] except more secure" distinction that is the problem. You
>> brush past that as if it did not exist.
> 
> So you're saying that a -onlyacceptconnectionsfrom=IP option
> wouldn't be a concern to you because it can't exclude people? Of
> course it can exclude people - just not your ISP or a state-level
> attacker.

You seem to look at this from only one perspective. Put yourself on the
other end of the wire (web wallets, APIs, exchanges, miners). Is an IP
address strong enough for them to prove to the state that they are
getting connections only from authorized "customers" that they know? Is
it sufficient for them that they may think they know their customer but
in reality it may be some ISP spoofing their customer (or some state)?
Obviously it is not sufficient, which is why IP addresses do not produce
this problem. They will need another mechanism, and BIP150 just happens
to be it.

> Please, Eric. I think I understand your concern,

I assume you do. The question is ultimately whether the P2P protocol is
an anonymous network of public information or it is a private network
(of private information). Too many arguments have been based on the idea
that the information is private (bloom filters, tainting). There are
anonymizing networks, Bitcoin P2P is not one of them.

Consensus rules exist to validate information obtained from the
anonymous public. That includes your ISP and the state. The rules
validate everything that matters except whether there is a stronger
chain - and seeing the strongest chain cannot be guaranteed by
encryption, unless of course we are all strongly tied to the majority
hash power and trust them.

Making the network private so that we can detect denial/disruption of
service is pointless if the the only threat is your own ISP or the state
.

> but this argument isn't constructive either.

I don't need to continue it, I've made my case. It's up to others to
decide whether it has been constructive and what to do with it. I hope
it is understood that I do not question the motivation of anyone involve
d.

> The proposal here is to introduce visible node identities on the 
> network. I think that's misguided as node count is irrelevant and 
> trivial to fake anyway.

Agreed.

> I know that you equate the concept of having verifiable identity
> keys in the P2P with a step towards making every node 
> identifiable,

There is no question that is a step toward making every person who
connects to the more centralized network identifiable. The next step
doesn't even require a software change. A "bitcoin provider" will only
need to provide you a secret to use when connecting. And they have every
reason to want to control this access.

e


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJY0b+SAAoJEDzYwH8LXOFOzskH/Ak4xTVWuY02dpA7Xcna0/lG
pLCYz5aFOoCRDokHf2uxtZptNaXMcz5eNBwhxRyXL9cMQ1ewME9nWDiM0x7Is0zC
0haiFW1bi81Tak6ELhA7+BwCQNYH4MBWirFo/T91veiaOx3Ttn5Nf8p+kYfbcvCC
eANxCsPM8s9ul7CzpfDtO+K7S9rV/mEZYDsogKT7P3JPbgH4kRWcyt1AcFfw74LU
Z68XkZL6aCl+nymupZR72z/oxykljjPegkZxIkoguNSybZR9dOLRRmkyiPplX+OU
szOlGnwuePxOq/BQE8ouAlfSgAmBHqMj6lnYCgbBUIWrTzjYlpZVA4dWTj/FVCM=
=um+z
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[Aymeric Vitte via bitcoin-dev]

As stated in this thread and as I see it the use of BIP150 is optional, 
so if some parties want to trust each others and use it, then they can, 
if they don't like it and don't want to use it, then they don't use it


Unless I misread, some statements in this thread involving the Tor 
network are wrong, the Tor network is a centralized network, each node 
(except the bridges) have a long term identity key and have to prove  
periodically to the authority servers that they are the owners of this 
key, if not the other nodes will never extend circuits to them, then 
they will be of course quite difficult to reach


Unfortunately the original proposal starting this thread seems to be 
reinventing this system that probably can only lead to something 
centralized which cannot apply for the bitcoin network (the Tor network 
is centralized because the team want to control what is happening: 
sybils, bugs, attacks, blacklist etc)


Unless some peers/nodes have decided to trust each others (BIP150) I 
don't think it's a good idea at all that bitcoin nodes have anything 
similar to long term nodeIDs (see 
https://gist.github.com/Ayms/aab6f8e08fef0792ab3448f542a826bf , already 
posted, not final, not finished, and the title does not really reflect 
what would be the proposal today, but it carefully avoids any 
possibility for a full node to have a long term ID)



Le 09/03/2017 à 02:55, Pieter Wuille via bitcoin-dev a écrit :

On Wed, Mar 8, 2017 at 5:16 PM, Eric Voskuil  wrote:

On 03/08/2017 03:12 PM, Pieter Wuille wrote:

In that way, I see BIP150 as an extension of IP addresses, except more
secure against network-level attackers. If you believe the concept of
people establishing links along existing trust lines is a problem, you
should be arguing against features in Bitcoin software that allows
configuring preferred IP addresses to connect to as well (-addnode and
-connect in Bitcoin Core, for example).

Weak identity is insufficient to produce the problem scenario that is at
the heart of my concern (excluding people). It is this "[same] except
more secure" distinction that is the problem. You brush past that as if
it did not exist.

So you're saying that a -onlyacceptconnectionsfrom=IP option wouldn't
be a concern to you because it can't exclude people? Of course it can
exclude people - just not your ISP or a state-level attacker.

Please, Eric. I think I understand your concern, but this argument
isn't constructive either.

The proposal here is to introduce visible node identities on the
network. I think that's misguided as node count is irrelevant and
trivial to fake anyway. But you bringing up BIP150 here isn't useful
either. I know that you equate the concept of having verifiable
identity keys in the P2P with a step towards making every node
identifiable, but they are not the same. It's just a cryptographic
tool to keep a certain class of attackers from bypassing restrictions
that people can already make.



--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[Pieter Wuille via bitcoin-dev]

On Wed, Mar 8, 2017 at 5:16 PM, Eric Voskuil  wrote:
> On 03/08/2017 03:12 PM, Pieter Wuille wrote:
>> In that way, I see BIP150 as an extension of IP addresses, except more
>> secure against network-level attackers. If you believe the concept of
>> people establishing links along existing trust lines is a problem, you
>> should be arguing against features in Bitcoin software that allows
>> configuring preferred IP addresses to connect to as well (-addnode and
>> -connect in Bitcoin Core, for example).
>
> Weak identity is insufficient to produce the problem scenario that is at
> the heart of my concern (excluding people). It is this "[same] except
> more secure" distinction that is the problem. You brush past that as if
> it did not exist.

So you're saying that a -onlyacceptconnectionsfrom=IP option wouldn't
be a concern to you because it can't exclude people? Of course it can
exclude people - just not your ISP or a state-level attacker.

Please, Eric. I think I understand your concern, but this argument
isn't constructive either.

The proposal here is to introduce visible node identities on the
network. I think that's misguided as node count is irrelevant and
trivial to fake anyway. But you bringing up BIP150 here isn't useful
either. I know that you equate the concept of having verifiable
identity keys in the P2P with a step towards making every node
identifiable, but they are not the same. It's just a cryptographic
tool to keep a certain class of attackers from bypassing restrictions
that people can already make.

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[Pieter Wuille via bitcoin-dev]

On Wed, Mar 8, 2017 at 1:20 PM, Jonas Schnelli via bitcoin-dev
 wrote:
>
>> Am 08.03.2017 um 22:09 schrieb Eric Voskuil :
>>
>> On 03/08/2017 11:47 AM, Jonas Schnelli wrote:
> 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 node ownership“).

I believe this discussion is getting sidetracked.

There is a difference between identification/fingerprinting (who are
you?) and proving identity (prove that you are who I think you are?).

BIP150 only facilitates the second, not the first. I don't think you
disagree about that, but I want to make it clear for anyone else
following the discussion.

The question is whether it encourages people to establish known and
pre-shared identities for nodes. Perhaps, but not in any way that
IP/onion addresses don't already. Think about it:
* If you know an IP/onion address, you can verify whether some node
has it. If you know an IP/onion address + BIP150 PSK, you can verify
whether some node has it.
* If you know 2 IP/onion addresses, you cannot figure out whether they
correspond to the same node (and if you can, that is a bug, not by
design). If you know 2 (IP/onion addresses, BIP150 PSK) pairs, you
cannot figure out whether they correspond to the same node (and if you
can, that is a bug, not by design).
* If you receive a connection from a node, you cannot know what their
onion address is. If you receive a connection from a node, you cannot
figure out what their PSK is.

In that way, I see BIP150 as an extension of IP addresses, except more
secure against network-level attackers. If you believe the concept of
people establishing links along existing trust lines is a problem, you
should be arguing against features in Bitcoin software that allows
configuring preferred IP addresses to connect to as well (-addnode and
-connect in Bitcoin Core, for example).

Cheers,

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers (and BIP150)

[Tom Zander via bitcoin-dev]

On Wednesday, 8 March 2017 20:47:54 CET Jonas Schnelli via bitcoin-dev 
wrote:
> Please Eric. Stop spreading FUD.
> BIP150 has a fingerprint-free **OPTIONAL** authentication. It’s designed
> to not reveal any node identifier/identity without first get a
> crypto.-proof from other peer that he already knows your identity.
> **Peers can’t be identified without having the identity-keys pre shared
> by the node operators.**

Do you know the trick of having an open wifi basestation in a public street 
and how that can lead to tracking? Especially if you have a network of them.
The trick is this; you set up an open wifi base station with a hidden ssid 
and phones try to connect to it by saying “Are you ssid=xyz?”
This leads the basestation to know that the phone has known credentials with 
another wifi that has a specific ssid. (the trick is slightly more elaborate, 
but the basics are relevant here).

Your BIP is vulnarable to the same issue, as a node wants to connect using 
the AUTHCHALLENGE which has as an argument the hash of the person I’m trying 
to connect with.

Your BIP says "Fingerprinting the requesting peer is not possible”.
Unfortunately, this is wrong. Yes the peer is trivial to fingerprint. Your 
hash never changes and as you connect to a node anyone listening can see you 
sending the same hash on every connect to that peer, whereever you are or 
connect from.

Just like the wifi hack.

I think you want to use industry standards instead, and a good start may be 
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[Eric Voskuil via bitcoin-dev]

On 03/08/2017 11:47 AM, Jonas Schnelli wrote:
>>> 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 node ownership“).
> 
> Please Eric. Stop spreading FUD.

I'm always willing to debate this issue. I'm generally a little
suspicious of one who demands another person to stop arguing. I got at
least one such demand (along with a threat) on this subject privately
last summer from a notable Core dev. There is a lengthy thread on this
subject in which I raised these issues. Everyone is free to review that
discussion.

> BIP150 has a fingerprint-free **OPTIONAL** authentication. It’s designed
> to not reveal any node identifier/identity without first get a
> crypto.-proof from other peer that he already knows your identity.
> **Peers can’t be identified without having the identity-keys pre shared
> by the node operators.**

The "presharing" of keys is how provable identity works, and is
precisely what this new proposal is also promoting. And in response to
that, the above statement was made by a Core dev (and not disputed):

>>> Nodes are by design not supposed to be identifiable in any way...

I'm calling out the obvious relationship between BIP150 and this new
proposal. Restating how identity works, or that its use is optional does
not refute my position. It's not FUD.

e



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers (and BIP150)

[Jonas Schnelli via bitcoin-dev]

Hi Tom

> Do you know the trick of having an open wifi basestation in a public street
> and how that can lead to tracking? Especially if you have a network of them.
> The trick is this; you set up an open wifi base station with a hidden ssid
> and phones try to connect to it by saying “Are you ssid=xyz?”
> This leads the basestation to know that the phone has known credentials with
> another wifi that has a specific ssid. (the trick is slightly more elaborate,
> but the basics are relevant here).
> 
> Your BIP is vulnarable to the same issue, as a node wants to connect using
> the AUTHCHALLENGE which has as an argument the hash of the person I’m trying
> to connect with.

This thread is not about BIP150/151.
The hash includes the encryption session which makes it impossible to distinct 
identities.

> 
> Your BIP says "Fingerprinting the requesting peer is not possible”.
> Unfortunately, this is wrong. Yes the peer is trivial to fingerprint. Your
> hash never changes and as you connect to a node anyone listening can see you
> sending the same hash on every connect to that peer, whereever you are or
> connect from.

Not true. The hash includes the encryption session which is based on a 
ephemeral ECDH/HKDF per connection-session.

Have you read the BIP?





signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[Jonas Schnelli via bitcoin-dev]

> Am 08.03.2017 um 22:09 schrieb Eric Voskuil :
> 
> On 03/08/2017 11:47 AM, Jonas Schnelli wrote:
 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 node ownership“).
>> 
>> Please Eric. Stop spreading FUD.
> 
> I'm always willing to debate this issue. I'm generally a little
> suspicious of one who demands another person to stop arguing. I got at
> least one such demand (along with a threat) on this subject privately
> last summer from a notable Core dev. There is a lengthy thread on this
> subject in which I raised these issues. Everyone is free to review that
> discussion.

What you did say in the sentence above (and I think is FUD) is, that BIP150 
will lead to every node being identifiable. This is just completely wrong.
There is nothing to say against a technical debate (and we had this), but I 
will ask you to stop if I see you attacking BIP150/151 at every occasion with 
FUDish arguments like this.





signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[Jonas Schnelli via bitcoin-dev]

> 
>> 
>> > 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 
> node ownership“).

Please Eric. Stop spreading FUD.
BIP150 has a fingerprint-free **OPTIONAL** authentication. It’s designed to not 
reveal any node identifier/identity without first get a crypto.-proof from 
other peer that he already knows your identity.
**Peers can’t be identified without having the identity-keys pre shared by the 
node operators.**



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[bfd--- via bitcoin-dev]

I feel you're conflating social identifiability with technical
identifiability. Sure, a node operator must always be able to remain
anonymous, but nodes themselves require a certain level of
identifiability otherwise there would be no means to communicate
between them.


Nodes running through networks like cjdns, onion, and i2p can
effectively communicate with no knowledge of the counterparty
whatsoever. Bitcoin does make an assumption that you are connected to
at least one non-partitioned peer, and that there is a cost in having
a large number of sybil nodes in many different ranges. Nothing
says you have to do your communication exclusively on one network or
another, so long as you have *some* source of information which is not
partitioned.



On 2017-03-08 05:44, Eric Voskuil via bitcoin-dev wrote:

On Mar 5, 2017, at 5:57 AM, John Hardy via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:


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 node ownership").


I feel you're conflating social identifiability with technical
identifiability. Sure, a node operator must always be able to remain
anonymous, but nodes themselves require a certain level of
identifiability otherwise there would be no means to communicate
between them.


Anonymous node identity is pointless, and is why I object to BIP151.
It provides no actual security/privacy benefit and is a stepping stone
to non-anonymous 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 like this is a way to help highlight the latter when it
is occurring I think it has value. I 'm not convinced that node
identifiers or identity persistence would have any meaningful impact
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 <btcd...@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 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
‘address’/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’s unique
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 identifier can be done by sending a message
the command ‘identify’ and a challenge. The node can then
respond 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 “first seen”, and how many IPs the same
identifier has broadcast from. Also, crucially, we could see what
software 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 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 add 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

j...@seebitcoin.com

Re: [bitcoin-dev] Unique node identifiers

[Eric Voskuil via bitcoin-dev]

> On Mar 5, 2017, at 5:57 AM, John Hardy via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> > 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 
node ownership").

> I feel you're conflating social identifiability with technical 
> identifiability. Sure, a node operator must always be able to remain 
> anonymous, but nodes themselves require a certain level of identifiability 
> otherwise there would be no means to communicate between them.

Anonymous node identity is pointless, and is why I object to BIP151. It 
provides no actual security/privacy benefit and is a stepping stone to 
non-anonymous 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 like 
> this is a way to help highlight the latter when it is occurring I think it 
> has value. I 'm not convinced that node identifiers or identity persistence 
> would have any meaningful impact 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 <btcd...@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 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
>>  ‘address’/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’s unique 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 identifier can be done by sending a message
>>  the command ‘identify’ and a challenge. The node can then respond 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 “first seen”, and how many IPs the same identifier has 
>> broadcast from. Also, crucially, we could see what software 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 
>> 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 add 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
>> j...@seebitcoin.com
>> 
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[John Hardy via bitcoin-dev]

> Nodes are by design not supposed to be identifiable in any way

I feel you're conflating social identifiability with technical identifiability. 
Sure, a node operator must always be able to remain anonymous, but nodes 
themselves require a certain level of identifiability otherwise there would be 
no means to communicate between them.

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 like this 
is a way to help highlight the latter when it is occurring I think it has 
value. I 'm not convinced that node identifiers or identity persistence would 
have any meaningful impact on privacy, though am open to being convinced 
otherwise.



From: Btc Drak <btcd...@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 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<mailto: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 ‘address’/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’s unique 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 identifier can be done by sending a message the command 
‘identify’ and a challenge. The node can then respond 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 
“first seen”, and how many IPs the same identifier has broadcast from. Also, 
crucially, we could see what software 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 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 add 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

j...@seebitcoin.com<mailto:j...@seebitcoin.com>

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[Btc Drak via bitcoin-dev]

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
> ‘address’/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’s unique 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 identifier can be done by sending a message the
> command ‘identify’ and a challenge. The node can then respond 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 “first seen”, and how many IPs the same identifier has broadcast from.
> Also, crucially, we could see what software 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 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 add
> 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
>
> j...@seebitcoin.com
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[John Hardy via bitcoin-dev]

> Wouldn't this actually *need* to be a bitcoin address that is included in a 
> block

I think it being a bitcoin address probably makes the most sense. The address 
could even be used for donations to incentivise identifier use.

I had not really envisaged this having any blockchain presence though. It was 
just an easy way to give third party node monitors like coin.dance and 
bitnodes.21.co a few more metrics.

That said, it would allow the creation of a 'nodepool', where each node could 
broadcast its latest status like a transaction, and every node has a register 
of active nodes. Like a mempool, but for nodes.

By leveraging the randomness of node identities, it could be that a 
deterministic subset of nodes randomly check that a new node status update is 
legitimate by querying the node directly (a small enough subset to not cause a 
DDOS). If a threshhold of those random checking nodes reports that the node 
either doesn't exist or is responding with conflicting information, this will 
become evident to the network and can be flagged.

This should paint a pretty accurate picture of the state of the network, and 
might also prove useful for developing lightning routing?


From: Marcel Jamin <mar...@jamin.net>
Sent: Sunday, March 5, 2017 6:29 AM
To: John Hardy; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Unique node identifiers

> 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<mailto: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 ‘address’/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’s unique 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 identifier can be done by sending a message the command 
‘identify’ and a challenge. The node can then respond 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 
“first seen”, and how many IPs the same identifier has broadcast from. Also, 
crucially, we could see what software 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 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 add 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

j...@seebitcoin.com<mailto:j...@seebitcoin.com>

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[Marcel Jamin via bitcoin-dev]

> 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
> ‘address’/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’s unique 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 identifier can be done by sending a message the
> command ‘identify’ and a challenge. The node can then respond 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 “first seen”, and how many IPs the same identifier has broadcast from.
> Also, crucially, we could see what software 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 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 add
> 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
>
> j...@seebitcoin.com
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev