<p>The <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wpkh" rel="nofollow noreferrer"><code>P2WPKH</code></a> actually uses the <code>HASH160</code> hashing algorithm, which is just <code>RIPEMD160(SHA256(pubkey))</code>.</p>

<p>The reason for using SHA256 is mentioned in BIP141:</p>

<blockquote>
  <p>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</p>
</blockquote>

<p>And yes, like you said, the witness program is determined not only by the version <code>0x00</code> byte, but also the length of the program. See <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wsh" rel="nofollow noreferrer">BIP141 - P2SH</a></p>

CC BY-SA 4.0
2019-01-09T21:34:39.813Z
2019-01-09T21:34:39.813Z
JBaczuk
<p>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.</p>

<p>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.</p>

<ul>
<li>The <code>P2WPKH</code> output script pattern will cause the script machine to evaluate witness and an original <code>P2PKH</code> script with the same public key hash. This script expansion is implied by the <code>P2WPKH</code> script
pattern (<code>[00] [20B]</code>).</li>
<li>The <code>P2WSH</code> 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 (<code>[00] [32B]</code>) can clearly be differentiated from the the <code>P2WPKH</code> script.</li>
</ul>

<p>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.</p>

<p>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 <code>[data_push] [drop]</code> without affecting validity).</p>

CC BY-SA 4.0
2019-01-09T21:58:45.643Z
2019-01-09T22:05:09.480Z
2019-01-09T22:05:09.480Z
James C.
<p>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?</p>

<hash><segregated-witness><sha256><p2wpkh><ripemd160>
SHA256 vs RIPEMD160 in SegWit
dcfg
# SHA256 vs RIPEMD160 in SegWit

(Asked by: username_0 on 2019-01-09)

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?

**Tags:** hash, segregated-witness, sha256, p2wpkh, ripemd160


---

## 2 answers

### Answer by username_1 on 2019-01-09. Score: 3 | Accepted answer

The [`P2WPKH`](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#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](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wsh)


---

### Answer by username_2 on 2019-01-09. Score: 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).


---

