> 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
