> 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