[bitcoin-dev] Unique node identifiers

Marcel Jamin marcel at jamin.net
Sun Mar 5 06:29:16 UTC 2017

> 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 at 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
> john at seebitcoin.com
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170305/baaa502c/attachment.html>

More information about the bitcoin-dev mailing list