What happens if he refuses to accept that block, and another miner creates a block without that transaction, and he accepts that. Won't this create a soft fork, and it will be up to other miners to decide which fork to run with. My guess would be that most nodes and miners won't want the overhead of checking transactions, so it would need to be an automatic check in the core software. Spammer support seems to exerting an influence here, and that is a bit concerning.
If somebody would program a node to reject certain blocks, whilst they are valid when it comes to the consensus rules at height X, not much would happen. This node would just receive the next block at height X+ 1 and would not be able to verify said block since he has rejected block at height X (and you need the hash of the block header at height X to verify the block at height X+1). The node would just stop being an active part
syncingof the
network, it could never sync the chain to the same height as the rest of the network, since no miner would create blocks "especially" for the reprogrammed node
), a fork would not happen. As far as i know, such functionality does not exist, it would not make any sense to add it.
If a node would reject an unconfirmed transaction (thus, not put it in it's mempool nor relay it), not much would happen either as long as the node isn't hardcoded to reject blocks containing said transaction. Other nodes would put it in their mempool, it would get included in a block and the node rejecting the unconfirmed transaction could still just verify said block (offcourse, if the transaction was invalid, non-standard or had other problems, it's possible most other nodes would reject it aswell... in this case, it would probably never end up in a block, unless some nodes still accepted it and it got mined by pure luck)