As the protocol is upgraded with soft-forks changing script interpreter behaviour, the script-machine is extended with additional runs. Each new upgrade brings a new script run with new rules, whilst previous script runs continue to be evaluated according to older rules. Arguments need to be supplied to determine whether the newer script runs are to be executed.
Native witness transaction introduced script types P2WPKH and P2WSH, which have mutually exclusive evaluation paths. Following the "standard" input and output script run, both script types evaluate to true, but no signatures or embedded scripts are evaluated yet.
- The
P2WPKH output script pattern will cause the script machine to evaluate witness and an original P2PKH script with the same public key hash. This script expansion is implied by the P2WPKH script
pattern ([00] [20B]).
- The
P2WSH output script pattern will cause the script machine to
evaluate both embedded and unlocking scripts loaded from the witness. No implied script expansion here. The script pattern ([00] [32B]) can clearly be differentiated from the the P2WPKH script.
Deciding which of the two evaluation paths should be followed requires an argument which is not explicit in either script type operations. This argument is supplied by the hash digest size.
Btw, this argument cannot be supplied in the witness data, because valid input scripts (now in the witness) do not follow a unique, recognisable pattern (e.g. I can always add [data_push] [drop] without affecting validity).