> On Mar 5, 2017, at 5:57 AM, John Hardy via bitcoin-dev
> <[email protected]> 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 <[email protected]>
> 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
>> <[email protected]> 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
>> [email protected]
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> [email protected]
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
