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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1]
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
------
[1] 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
