Ok, I guess you don't know how verification works. Here are the 19 steps: https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messag...
Step 4) "Block hash must satisfy claimed nBits proof of work"
The bad actor has full control of that, he just has to make sure the fake header has enough leading 0s in phony header nBits, the function that checks this is CheckProofOfWork() at https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L... Step 10) "Verify Merkle hash"
Well gee-wiz, how are we going to do that without having all the transaction in the block that the phony header hashMerkleRoot represents? GetHash() at https://github.com/bitcoin/bitcoin/blob/master/src/primitive...The malicious actor cannot fake that. They have to produce massive amounts of proof of work to find a value in the nonce data field in the block header that results in that hash meeting the required difficulty, and even if the malicious actor delays transmitting the whole block, they cannot delay transmitting the block header, or other nodes will not even bother trying to extend their block.
So all miners can immediately verify if the block headers they are receiving have the required PoW behind them, and it would be very costly for a malicious actor to generate fake block headers with enough PoW to be accepted, while giving the malicious actor very little advantage in an attack, meaning it would be a completely impractical and ineffective way to attack way to attack Bitcoin.
Verifying blocks is trivial. You aren't still saying that needing to receive 900KB is a big deal are you?
You seem to be acting like there is some sort of prediction that there will be a problem. Ethereum already produces blocks every 13 seconds at three times bitcoin's throughput.
I said that you can't verify the header until you have downloaded the entire block - meaning the time between a false header being submitted and the last transaction in the block being downloaded is time the miner either abandons its work on the last real block and then sits idle or risks hashing a new block prior to verifying the false header. He implied that you can somehow verify using the PoW. I demonstrate that you cannot. I'm not sure how you could have missed it.
Malicious actors can't give a bogus header, because you can verify the bogus header doesn't have enough PoW. If the malicious actor does produce sufficient PoW for their bogus header, they are foregoing massive block rewards to fool your node for a few seconds. That's why this kind of malicious activity doesn't happen, and why miners do validation free mining on a new header until they've verified the whole block.