Thanks for the reply. You write:
The "special validity rules" [ of relay nodes ] are not consensus rules unlike the validation rules which are consensus rules. Those rules are called standardness rules and both miners and full nodes have them. The standardness rules are local node policy so they tend to change more often than consensus rules because if something is non-standard it can still be valid.
The word "standardness" implies that someone is setting a standard that should be followed by all nodes; but it is known that different relay nodes are using different arbitrary criteria to censor transactions and blocks.
Full nodes are even more important nowadays due to the prevalence of SPV mining. Many miners now aren't running full nodes, meaning they are not fully validating every single block and transaction they receive. The only nodes that do should do this now are the full nodes and they are should be what are enforcing the consensus rules because most miners aren't doing it and SPV wallets cannot.
Fixed that for you. They
should validate the blocks that they receive, but (unlike the miners) they have no motivation to do so, and there is no way for a client to check that they are.
The miners have a strong incentive to use only valid blocks as parents; when they gamble, as in the (badly named) "SPV mining" of empty blocks, it is because they have high confidence that the parent block is valid. In the case of classic "SPV mining", they steal the hash of the parent block from another pool via Stratum. Therefore, if that block was invalid, that other pool would be screwing all its members and itself. In other words, when miners do "SPV mining" they gamble that the same incentives that spur them to validate their non-mepty blocks will spur the miner who assembled the previous non-empty block to validate it too.
Non-mining relay nodes have no incentives to validate the blocks that they relay. On the contrary, they have a significant incentive to skip validation altogether.
These full nodes should protect against [ ... ] malicious miners.
How exactly are they going to do that? A relay node can only withhold a mined block that it considers invalid. But if the malicious miners have a minority of the hashpower, that block will not get many confirmation, and soon be orphaned and rejected even by SPV clients. On the other hand, if it comes form a majority branch, then sooner or later the SPV clients will receive it and accept it as valid, rejecting the "good" minority block that some relays offered instead. And, in that case, bitcoin is done for anyway: nothing will save it if malicious miners have a majority of the hashpower.
On the other hand, a relay can withhold blocks from the majority branch and serve instead blocks from a minority branch, created by old, buggy, or malicious miners. If all the relay nodes that are contacted by an SPV client do that, the SPV client will be screwed. Given the way that clients get the addresses of relay nodes, and that such malicious relays are very easy to set up (much easier than setting up an effective malicious miner), this risk is far form negligible.
Perhaps the faith that some people have on relay nodes comes from experience with SMTP, NNTP, bitTorrent and other decentralized p2p networks, where nodes can (must) be assumed to be well-intentioned by default? Bitcoin is quite unlike those networks...
These full nodes protect should protect against major mining screw ups like the July 4th fork
The blame for that incident should go to the Core devs, who choose to deploy BIP66 when 5% of the miners were still not ready, without a grace period and without alerts. The miners should be blamed only for trusting that the devs knew what they were doing.
It seems that the miners did learn their lesson, because at the next soft fork (BIP65, IIRC) AntPool held back its vote until most of the tiny miners had upgraded, and prodded them to do so. I wonder if the Core devs have learned theirs?
