[neospice]

Please forgive my ignorance if I’m missing something obvious but in your PGP public key tampering example, wouldn’t this attack be ineffective against a blockchain that is stored in multiple peers. I.E your hashes wouldn’t match those of the peer copies of the blockchain?

[vec]

Nope. The whole point of proof of work is that it informs clients which version to consider authoritative in the case of a conflict. If my tampered copy has higher proof of work than the peer with the correct version then, by definition, mine is correct and the other peer's is outdated. Correctly implemented peers will recognize this and overwrite their local cache with mine, and even if they don't other peers will always prefer my version to theirs when deciding which update to sync.

[neospice]

How is "higher proof of work" defined in this context? Also, doesn't consensus of the majority of peers have any bearing on which is more authoritative? I.e. if all nodes except for your malicious node report a single chain, why would yours not be rejected?

[vec]

"Proof of work" means the total number of hashing functions, from the point of divergence forward, used in signing the blocks.

Consensus doesn't work like you're implying. If it did, I could spin up a peer on N+1 AWS servers, where N is the current number of peers on the network, and now my version has the majority of peers supporting it.

The whole idea behind proof of work is that it's impossible to fake. The version that took the most net computing power to generate is by definition authoritative. This means that the only way to make a malicious version of a chain is to actually, genuinely do more total work than the legitimate actors collectively did. The other side of this coin, though, is that it explicitly allows me to generate a malicious version of the chain by actually, genuinely doing more total work than the legitimate actors collectively did.