Who are "you" in this scenario?
"You" are a software developer, trying to introduce backward-incompatible changes, and thinking, that by having 51%, "you" can change the way how existing software works. "You" cannot. Nodes simply won't understand "your" messages, if "you" are going to "ignore the database".
How do you know what is the "Bitcoin product" and what isn't?
By reading the protocol. If you have "tx" P2P network message, then you can send transactions. In some strictly-defined format. Not just "arbitrary data, no matter what". You have to stick to the protocol messages:
https://en.bitcoin.it/wiki/Protocol_documentationIf you produce something unusual, it will be instantly rejected, in the same way, as if you speak Quenya, your content will be rejected by English-based community.
For example: we had "checkorder" message, when we had Pay-to-IP features. Now we don't have it. And you can have 99% hashrate, it doesn't matter, by having that, you won't reintroduce Pay-to-IP messages to the protocol, if your peers won't understand it.
How does the software automatically detect this?
By having code, which is responsible for detecting that. If you start broadcasting bad messages to the network, then other nodes will automatically execute "setban" command on your IP, for example up to 24 hours. If you try to execute 600k block reorg, then first, long before that, people will need to download and verify your blocks (and then, they will notice that something is wrong). But even if they don't, then by trying to wiping away 500 GB of history, you will trigger all kinds of protections, related to allowed data transfer in P2P network, so either you stick with the bandwidth, allowed by other nodes (and then it takes time to share those blocks), or you send more than allowed, and other nodes will ban you automatically, or disconnect from you for the next hours, and try other peers automatically.
How would holders of Bitcoin know who to trust and who not to trust in real time?
By playing the game of trust, and sticking to some simple, universal rules:
https://ncase.me/trust/There are many CopyCat nodes, which can win the war in the long term. You can try to introduce some new node type, and compete with CopyCat. If it will be successful, then it may be adopted, and used by the majority of users. But if your node is a Cheat node, producing incompatible messages, then it will quickly lose the game, by being banned by most of the network, and having no peer to connect to, for the next 24 hours.
How can they tell the difference between a node that has been secretly taken over by a government or some other entity and one that hasn't?
Nodes are judged by their behaviour. If you send invalid P2P message, you will first receive some kind of warning, then some short ban, and then it can escalate, up to 24h ban. You can test it in regtest on localhost, if you want to know, how exactly debug log file will look like.
What part of the client determines that?
See "setban" command, and CTRL+F or grep places in the code, leading to those parts.
Where is the code, in the client, that establishes, in real-time, whether a node is "evil" or not?
https://github.com/bitcoin/bitcoin/blob/master/src/banman.h#L28// Banman manages two related but distinct concepts:
//
// 1. Banning. This is configured manually by the user, through the setban RPC.
// If an address or subnet is banned, we never accept incoming connections from
// it and never create outgoing connections to it. We won't gossip its address
// to other peers in addr messages. Banned addresses and subnets are stored to
// disk on shutdown and reloaded on startup. Banning can be used to
// prevent connections with spy nodes or other griefers.
//
// 2. Discouragement. If a peer misbehaves enough (see Misbehaving() in
// net_processing.cpp), we'll mark that address as discouraged. We still allow
// incoming connections from them, but they're preferred for eviction when
// we receive new incoming connections. We never make outgoing connections to
// them, and do not gossip their address to other peers. This is implemented as
// a bloom filter. We can (probabilistically) test for membership, but can't
// list all discouraged addresses or unmark them as discouraged. Discouragement
// can prevent our limited connection slots being used up by incompatible
// or broken peers.
And then when it does, what does it do about that?
Just read "banman.h" and "banman.cpp" files, to find out.
Now, if you are telling me that individuals can simply pick and choose which part of the network they will accept, and which part they won't, well, that's another security risk, now isn't it?
Why? If you connect to your own server, you can trust it. It is your server, your node, the same entity, the same party. You can also trust localhost. There are many things you have to trust, to have some basic computing ability. For example: you have to trust, that your random number generator is "random" enough. If it is not, then all of your private keys could be compromised.
There are no people involved in this decision. Bitcoin is an algorithm, not a committee.
And command-line options like "setban" or "invalidateblock", or even "preciousblock" are there for what? Because developers had nothing better to do with their time?
Obviously, most nodes run on autopilot, for most of the time. But: there are ways to grep debug log, and catch some unexpected behaviour. Even when some mining pool violated sigops limit, it was quickly noticed, and you even had forum topics about it:
https://bitcointalksearch.org/topic/error-connectblock-too-many-sigops-invalidchainfound-invalid-block-5447129See? Some people are reading those logs. And in the Open Source world, it is normal to have some eyes, watching some logs, reading some code, and talking about what they can see, if they observe something unusual.
