there is a they.. there are actual people that like to view the block data and find strange things. we see it alot when people shout out that early adopter coins have moved or there is a pattern of a few blocks that are "empty blocking". even times where blocks are just full of junk meme data

there are people monitoring and announcing issues, and there are some devs that discuss and have core privilege to change the protocol and create a release candidate to change the ruleset to ban nodes for certain reasons. we have seen it happen in the past. where certain things occur and the protocol changes to compensate for the change

you trying to pretend that the algo is just the algo and no one governs it is the ignorance of not realising core devs have control and its them that have political governance of the ruleset and yes this governnance in many ways is a bad thing also (to have one single group of ~ a dozen core devs in ultimate power..) but to then assume they dont exist is a double layer of ignorance to then not see the attack vector which the centralisation of core can present

i know you think a mining 51% attack is a mega threat.. however its actually the core centralised governance of the protocol thats more of the real threat to bitcoin long term

research what happened in july-aug 2017 where a group of devs and economic nodes(services) decided to ignore certain versions of blocks to falsify a 100% consensus(its unnatural/unrealistic to actually get the 100%) to cause a move of the protocol to a new version.. so yes devs a economic nodes can react to things they see in blocks they dont like, such as needing over 80% vote for a feature the devs wanted activating but the pools only gave 45% vote towards segwit, pre july 2017. so they ignored blocks to falsely get 100%

well in 2013 there was a leveldb bug which was fixed in 13 hours

in 2017 it was decided they would at a certain date start ignoring certain blocks with a specific version bit. and at that exact mandated time, the blocks with the disliked version bit were ignored

economic nodes dont need to wait for the network to adapt, they can ban nodes propagating blocks it doesnt like, meaning they keep the blocks pre re-org and thus throw the malicious pool off their view of the network leaving it creating its own altcoin (again research events of 2017)
the economic nodes communicate with each other for many reasons of chain analysis. not just looking for funky blocks but also looking for tainted coin and blacklisted coin(AML/KYC stuff) so they are always on the lookout.

again as said already..
when CEX(economic nodes) get deposits and then a malicious pool does a re-org to then double spend a coin. if the CEX see's another deposit using a utxo it already seen used. the cex can firstly freeze the user account from doing any trading on its cex platform. and then send a redflag message to the core devs that a re-org occurred.. although the core devs would also already see that a re-org happened as even some core devs do block analysis and can create a patch to update to, to officially ban that re-org.. however economic nodes can manually ban certain things without needing official update patches
other mining pools can also reject blocks and just continue with their pre-org chain.
theres lots of mitigating factors

its not like the blockchain is not transparent.. as soon as a re-org happens everyone can see it and as said things like CEX's have things in place to protect their trades and deposits from double spends

there are already other mitigations such as block creators cant spend their rewards for 100confirms. so thats 16 hours before a malicious pool can even attempt to spend rewards so they wont benefit from reward profits unless their attack continued for atleast 16 hours (plenty of time inbetween to react)

you keep skipping over alot of stuff avoiding details you dont want to see

anyways
to get an official patch(like in 2013) took 13 hours.. but nodes didnt need to wait that long. they can and did self ban certain nodes propagating dodgy blocks and then only accept blocks from the chain that was not funky..
..and guess what.. 11 years later bitcoin is still running. so your fear of bitcoin will die in a 13 hour event are proven wrong...

also (separate example of different event) it did not require every node to upgrade in summer 2017 for the network to change path. economic nodes only accepted certain blocks it mandated that they would accept and the rest of the network just received blocks which the economic nodes accepted and passed on.

i think you need to spend alot more time learning about bitcoin. as it seems you are becoming less interested in wanting to get answers and instead just wanting to throw out questions get responses and ignore things that dont fit your narrative you want to pursue.. so now me and others seem to be getting annoyed by your requesting to be spoonfed and then spitting out and not liking whats been fed to you.. so if you really want to learn, please take some time out from the forum which you endlessly post questions you dont want real answers to.. and instead spend those same wasted days on actually learning about bitcoin from the many sources available
i have only mentioned a few mitigating factors and you keep stepping over them, causing the discussion to keep circling around the same basics and not evolving the conversation further... so now its probably best you learn more about bitcoin for your own self education and then come back when more informed to realise where your theories get debunked

if you researched about what happened in 2013 and in 2017 you would not be responding in the way you were responding
so if you really want to know things, go research it in full

ok first lets zoom into just one attack vector.. re-orging a chain of old blocks...

if a malicious pool went back say 6 blocks and then had 60% of network would still require ~55 blocks to catch up and get ahead of the honest network to even be able to sway the network to change its history.. but here is the thing
core nodes have a "banman" (ban manager) that looks at the changetips and header data and would reject blocks that dont match its history and then give the nodes sending such blocks a score whereby if the persistence of sending dodgy blocks continues to uprate the score then the node will ban the peer sending it
the node would also ignore/drop/reject/stale/orphan/evict the block(s) in question

if you spent some time looking at these things you will see that there are many mitigating factors involved that stop a malicious/misbehaving actor from sending data that does not correspond to the honest chain

my personal node for instance checks the block hash Id (and the 'chainwork' and othe things) of the current chain and if a new block appears with a new height. but its previous block hash does no match the one i have, nor does its previous or its previous for 6 blocks.. then my node just treats it as misbehaving and rejects it if the ancestry does not match within 6 block heights
thus my node sticks to the 6 confirm rule and not allow a chain re-org older than 6 confirms

thus if a malicious actor who did try to go back 6 blocks to its previous.. and then tried to catch up.. meaning it had a new chain of 55 blocks of different hashes compared to the honest chain i follow. it has no chance

it cant simply just go back one block edit it and then broadcast the edited block. as the honest network is already ~2 blocks ahead of the malicious pool, so the malicious pools broadcast would just get rejected as a lower height with a non matching block hash..
it would need to add more blocks and catch up overtake the honest network blockheight to have a height bigger then the honest network to even get a chance to be seen.

if a mining pool went one block back to edit one confirmed block.. and with a 60% of network hashrate, it might get to overtake and re-org the network within 10 blocks catchup time.. at very best 5 block catch up time.. thus only affect 6 blocks that get re-orged (5 after the rewind and 1 of the historic change)

if it managed to overtake and get its blockchain of edited blocks accepted, those transactions of the honest chain of parallel height blocks(6) just change from confirmed to unconfirmed and get put back in mempool to be rebroadcast again.. which the malicious pool can decide to just not put into blocks again and leave the network congested whilst the malicious pool "empty blocks"

however at the very minute that it broadcast the blockheight that overtakes the honest chain to make the honest chain drop its own 6 blocks.. the nodes create a log alert that its dropping blocks to then pursue the new version of 6 blocks thus unconfirming transactions back into mempool.. so people would react and notice.. and just affects transactions of upto 6 confirms
economic nodes as already said would and do have configured nodes to know which of its cex platform user accounts database is credited with balance from which utxo was spent and if there was a doublespend they would halt that cex account spending habits within its platform

other services also 'taint' certain utxos deemed unconfirmed again and if the tx is not spend in the same tx manner as the first time to purely re-confirm it again and instead the tx has been altered and replaced by the key holder those analysis services would flag it too

..
but lets concentrate on the nodes themselves.
as hinted at already, each block has a block id of its block and within that block it also has the Id of the previous block.. there are a set of rules in ban manager that can be set to reject blocks where they dont match the set the network already obtained

so not only is a malicious pool limited in how far back it can go due to it requiring more power or time to catch up and overtake.. but also nodes can treat blocks as misbehaving if their block ID's dont match the nodes own ancestry of id's at a certain depth

(there are more mitigating factors but lets atleast get you passed these little spoons first)

Do you even... I really don't understand if we are even talking about the same thing. If I owned a big mining farm, I will turn off the power. Why would I need FBI or Satoshi to do it? Hack my server, I switch off the power. Why would I let you run my rigs and I pay for your bills? What on earth are you talking about man?

Or like @hd49728 says, I would just reconfigure and put my hash to another pool.

And then 'Russia' or whoever it is in your scenario would be, what, out of costs spending on the hack and MAYBE built 10 blocks. Hooray?

Again, successful means profitable. You ignore this again and again.

So somebody just downloads banman, builds it, and any node on the Bitcoin network you want to be banned is... banned?

So why wouldn't the attackers simply ban nodes that aren't part of their attack?

I'm not sure if you are being obtuse on purpose, or that's just how it's coming out, but I'll try to ask this question a different way.

What will it accomplish if I, one of millions of Bitcoin holders, downloaded banman and banned some nodes I read about--if I am one of the only ones doing this? How would the millions of Bitcoin wallet holders know to do this? I would imagine that 95% of wallet holders have never used GitHub, and don't have access to a build system where they could build it, and then they wouldn't know which nodes to ban (where would they find this out?). Indeed, I suspect most Bitcoin holders don't get day-to-day Bitcoin news, and wouldn't update their wallet's node list for weeks, if ever. Then what?

If the thing defending the Bitcoin network is a "gossip network", then obviously the attackers would generate their own gossip and tell people to ban the good nodes.

(That you keep resorting to personal attacks isn't helping your argument either).

Help me understand:

The only identifying information in a block is what the miner chooses to provide. How would a pool or node recognize that a block is from an anonymous malicious miner?

It only takes one node for the blocks to spread to the rest of the network. How are nodes prevented from receiving blocks from a malicious miner?

If a portion of the network rejects valid blocks, then the result would be a hard fork. What would be the impact of the hard fork, and how would it be mitigated?

in a situation of re-org when a malicious pool finally overtakes the honest network to broadcast a new higher height block. the nodes will see the newest blocks 'previous hash' does not compare to the current hash of the honest network


it doesnt take one node to spread.. initially the malicious pool that creates a block has to broadcast it to other nodes, then those nodes broadcast it further out to other nodes if the block is valid and suitable. or if not, within the inner layer of the spiders web would not broadcast it out and so the outer layers wont see it
what nodes do is if say honest network had 861203 and one of its peers(malicious) had 861204 the honest node would request the ..204 block, however the peer that had it has to have accepted it to update its own height. if the honest node gets it and rejects it, the honest node stays at ..203 and so its own other peers wont see a height update from the honest node so doesnt ask for a new block because they too are still on ..203
 

there would need to be a different in the nodes of whats acceptable and whats rejectable.. and if there is a difference. an altcoin is made where differing chain of blocks from different pools doing different chain of 'prev block' hashes compared to the other set

as said if its just one malicious pool and the malicious entity has not got a army of nodes to back it, especially not the economic nodes of the major services/exchanges.. that altcoin would be a waste of resources no one sees bar the malicious entity. the honest network would have seen the ancestry of many previous blocks dont match the chain they support so would just reject it

the only way a malicious pool could re-org by editing a previous confirmed block is to not go back very far. and then have WAY MORE then equal hash to honest network to catch up and over take super fast to get under the threshold of acceptable number of block ancestry that can be replaced