It is extremely difficult to write a specification for a complex format that is 100% watertight and has no poorly defined corner cases. I can't find a link right now but I remember a study posted recently about differences in validation behavior between different implementations of a common signature scheme.

This leads to a problem in consensus-based protocols like bitcoin, if there are multiple implementations then they might disagree about whether a given block is valid, either because someone accidentally ran into a corner case or because a malicious actor is submitting blocks deliberately crafted to run into corner cases.

If a minority implementation accepts a block that the implementation used by the majority of miners rejects, then little harm is done, the "strongest chain" rules mean that everyone follows the rules set by the majority implementation.

But if the minority implementation rejects a block and the majority implementation accepts it then there will be a fork. Users of the minority implementation will stop seeing new blocks from the main chain and (if the minority implementation has mining support) may start to form their own chain with conflicting history.

So using a new implementation for "full validation" bitcoin chain processing is risky, even if the implementer has gone through the whole history so-far and checked it validates with their new implementation, users of that implementation could find themselves cut off from the rest of the network at any time.

It is extremely difficult to write a specification for a complex format that is 100% watertight and has no poorly defined corner cases. Further even if the specification itself is watertight it's extremely difficult to implement it without making any mistakes. I can't find a link right now but I remember a study posted recently about differences in validation behavior between different implementations of a common signature scheme.

This leads to a problem in consensus-based protocols like bitcoin, if there are multiple implementations then they might disagree about whether a given block is valid, either because someone accidentally ran into a corner case or because a malicious actor is submitting blocks deliberately crafted to run into corner cases.

If a minority implementation accepts a block that the implementation used by the majority of miners rejects, then little harm is done, the "strongest chain" rules mean that everyone follows the rules set by the majority implementation.

But if the minority implementation rejects a block and the majority implementation accepts it then there will be a fork. Users of the minority implementation will stop seeing new blocks from the main chain and (if the minority implementation has mining support) may start to form their own chain with conflicting history.

So using a new implementation for "full validation" bitcoin chain processing is risky, even if the implementer has gone through the whole history so-far and checked it validates with their new implementation, users of that implementation could find themselves cut off from the rest of the network at any time.