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

Reply via email to