📅 Original date posted:2017-03-05
📝 Original message:> Nodes are by design not supposed to be identifiable in any way
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.
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.
________________________________
From: Btc Drak <btcdrak at 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 at lists.linuxfoundation.org<mailto: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<mailto:john at seebitcoin.com>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org<mailto: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/3f0fadb5/attachment.html>;
John Hardy [ARCHIVE] /
npub15f…get3u
2023-06-07 17:56:57
in reply to nevent1q…jsvf
Author Public Key
npub15fe6jcj3a2vykwk9tshyjc47s4q0t7jza444dnffcympur2v7myq6get3uPublished at
2023-06-07 17:56:57Event JSON
{
"id": "25d711d6b42ff719645833877cca9196f27df61a423574bacbec2e956771d9bb",
"pubkey": "a273a96251ea984b3ac55c2e4962be8540f5fa42ed6b56cd29c1361e0d4cf6c8",
"created_at": 1686160617,
"kind": 1,
"tags": [
[
"e",
"9dd5ee30e00a8982beef06bc0de72f4df99da3649e3263091c6819d269e9eb1c",
"",
"root"
],
[
"e",
"6c156b4e6a4ed13febafd6685b520f93f4ba62cf51efa77e8507b6077acb338c",
"",
"reply"
],
[
"p",
"fdf31024ca0537ed828d895ddc8525f8af023f0dc935a8327a8a496d0d7a9f83"
]
],
"content": "📅 Original date posted:2017-03-05\n📝 Original message:\u003e Nodes are by design not supposed to be identifiable in any way\n\nI 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.\n\nI 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.\n\n\n________________________________\nFrom: Btc Drak \u003cbtcdrak at gmail.com\u003e\nSent: Sunday, March 5, 2017 1:27 PM\nTo: John Hardy; Bitcoin Protocol Discussion\nSubject: Re: [bitcoin-dev] Unique node identifiers\n\nNodes 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.\n\nAs a side note, this should probably have started out as a bitcoin-discuss post.\n\nOn Sat, Mar 4, 2017 at 4:04 PM, John Hardy via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\nThe 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.\n\n\nI had an idea for an anonymous, opt-in, unique node identification mechanism to help counter this.\n\n\nThis would give every node the opportunity to create a node ‘address’/unique identifier. This could even come in the form of a Bitcoin address.\n\n\nThe 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.\n\n\nAsking 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.\n\n\nWhy would we do this?\n\n\nWell, it adds a small but very useful piece of data when compiling lists of active nodes.\n\n\nAny 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.\n\n\nThis 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.\n\n\nThis 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.\n\n\nKeen to hear any thoughts?\n\n\nThanks,\n\n\nJohn Hardy\n\njohn at seebitcoin.com\u003cmailto:john at seebitcoin.com\u003e\n\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170305/3f0fadb5/attachment.html\u003e",
"sig": "5b6350e443c0a898230d37f60c9c0d06bf7771bd8ac96bc756c6551b202cd3fe3262a23833d465a43effe2e5bcafd5b47e9a4e2bafdc15976ead127ca57c8df6"
}