@fabrice and @scholtz: thank you both very much for your thoughtful responses!
@ fabrice:
So their approximate physical location is not really secret and cannot be secret. See The default list of Relay Nodes for example for how to get the list.
Got it.
Are the locations of archival, non-relay nodes kept secret? I could imagine that being useful in the event of a community-wide crisis of confidence. e.g. imagine bad actor Bob wants to erase record of his debt which appears early in the blockchain (way before 1000 rounds ago, say) and manages to corrupt the archived blockchain of all publicly known such archives at some block before the record of his debt. So Bob is a really bad, resourceful dude; I don’t doubt that a strong majority, I daresay all, node operators operate in good faith, but Bob is the one who worries me…
…but Bob can’t corrupt not-publicly-known archived blockchain copies. So even if Bob causes this a priori crisis of confidence by corrupting all publicly known archived blockchain copies, e.g. the archived copies stored at all relay nodes, anyone operating a secret (and correct) archived blockchain copy could broadcast their copy to the network and restore faith.
Of course, if Bob is really such a bad dude, you might then worry that Bob corrupts the restored archived copies at the relay nodes. And again. And again. And … Is there any way to prevent this sort of attack, by a terrible actor like Bob, on all blockchains archived at publicly known locations?
From the point of view of security when querying the blockchain, since you only query a given node, the only thing that matters is that this given node is trustworthy. If there are 1000 nodes you can query and 999 are honest but 1 is not, what matters is that you query one of the honest nodes. There is no way we can prevent a malicious node provider from answering wrong information. This is the case for all blockchains.
I see your point. But if Bob actually manages to corrupt every relay node, there are only 106 listed at the link scholtz sent, what then?
The scenario I’m asking about might be kind of far-fetched. And I agree these are issues every blockchain would face. But I’m trying to understand our community’s stance on this issue for our own blockchain.
I hope this will change in the future as the relay function is not the same as data persistant function and the costs for these two functions should be optimized.
Good point. As above, I think that secret archived copies of the blockchain could also serve a useful purpose from a security point of view.