SHA256 vs RIPEMD160 in SegWit

Question

In Pay-To-Witness-Public-Key-Hash (P2WPKH), the RIPEMD160 hash function is used to hash the public key of the recipient in the locking script. On the contrary, Pay-To-Witness-Script-Hash (P2WSH) uses the SHA256 for hashing the redeem script. Why has this difference been made? Just to differentiate the two types of witness programs?

Answer 1

The P2WPKH actually uses the HASH160 hashing algorithm, which is just RIPEMD160(SHA256(pubkey)).

The reason for using SHA256 is mentioned in BIP141:

The increased size improves security against possible collision attacks, as 2^80 work is not infeasible anymore (By the end of 2015, 2^84 hashes have been calculated in Bitcoin mining since the creation of Bitcoin). - BIP141

And yes, like you said, the witness program is determined not only by the version 0x00 byte, but also the length of the program. See BIP141 - P2SH

Answer 2

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).