<p>Maybe one of the authors of BIP143 will correct me, but I think this was done to simplify the implementation in Bitcoin Core.</p>
<p>If you look at the <a href="https://github.com/bitcoin/bitcoin/blob/v27.0/src/script/interpreter.cpp#L1898" rel="nofollow noreferrer">code for P2WPKH validation</a>, you can see it actually builds and executes a P2PKH script. This is just one way you could implement P2WPKH validation, and indeed <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program" rel="nofollow noreferrer">BIP141</a> doesn't say anything about executing a script, however this simple 5-line implementation is only possible if the <code>scriptCode</code> for P2WPKH is the corresponding P2PKH script.</p>

CC BY-SA 4.0
2024-05-16T12:13:16.380Z
I believe the design decision was just to treat P2WPKH as a "special short notation" for a specific single-key P2WSH. That resulted in both the current code, and the effect that the scriptCode equals this specific form. In retrospect, this was a bad decision, because it means P2WPKH spends can be malleated into equivalent P2WSH spends by third parties, which slightly reduces the feerate of the transaction even.
Pieter Wuille
CC BY-SA 4.0
2024-05-16T14:51:48.100Z
@PieterWuille How can it be malleated when the signature commits to the outpoint(s)?
Vojtěch Strnad
CC BY-SA 4.0
2024-05-16T19:33:39.280Z
I misremembered; it's a somewhat different setting. The issue is with hardware signing devices: a malicious software wallet could create a P2WSH signature, present it as a P2WPKH spend to the signer, which would present a higher fee to the user.
Pieter Wuille
CC BY-SA 4.0
2024-05-16T11:59:41.037Z
2024-05-16T11:59:41.037Z
Vojtěch Strnad
<p>When signing a P2WPKH input, the P2WPKH locking script is converted to the pattern of a legacy P2PKH when creating the scriptCode.</p>
<p>From <a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki" rel="nofollow noreferrer">BIP 143</a>:</p>
<blockquote>
<p>For <code>P2WPKH</code> witness program, the <code>scriptCode</code> is <code>0x1976a914{20-byte-pubkey-hash}88ac</code>.</p>
</blockquote>
<p>What's the reason for this?</p>
<p>Why not just use the original P2WPKH as the scriptCode?</p>

<segregated-witness><p2pkh><p2wpkh><sighash><bip143>
What's the reason for the scriptCode format for a P2WPKH? (BIP 143)
inersha
# What's the reason for the scriptCode format for a P2WPKH? (BIP 143)

(Asked by: username_0 on 2024-05-16)

When signing a P2WPKH input, the P2WPKH locking script is converted to the pattern of a legacy P2PKH when creating the scriptCode.

From [BIP 143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki):

> For `P2WPKH` witness program, the `scriptCode` is `0x1976a914{20-byte-pubkey-hash}88ac`.

What's the reason for this?

Why not just use the original P2WPKH as the scriptCode?

**Tags:** segregated-witness, p2pkh, p2wpkh, sighash, bip143


---

## 1 answers

### Answer by username_1 on 2024-05-16. Score: 1 | Accepted answer

Maybe one of the authors of BIP143 will correct me, but I think this was done to simplify the implementation in Bitcoin Core.

If you look at the [code for P2WPKH validation](https://github.com/bitcoin/bitcoin/blob/v27.0/src/script/interpreter.cpp#L1898), you can see it actually builds and executes a P2PKH script. This is just one way you could implement P2WPKH validation, and indeed [BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#witness-program) doesn't say anything about executing a script, however this simple 5-line implementation is only possible if the `scriptCode` for P2WPKH is the corresponding P2PKH script.

> **Comments:**
> **username_2**: I believe the design decision was just to treat P2WPKH as a "special short notation" for a specific single-key P2WSH. That resulted in both the current code, and the effect that the scriptCode equals this specific form. In retrospect, this was a bad decision, because it means P2WPKH spends can be malleated into equivalent P2WSH spends by third parties, which slightly reduces the feerate of the transaction even.  
> **username_1**: @username_2 How can it be malleated when the signature commits to the outpoint(s)?  
> **username_2**: I misremembered; it's a somewhat different setting. The issue is with hardware signing devices: a malicious software wallet could create a P2WSH signature, present it as a P2WPKH spend to the signer, which would present a higher fee to the user.  

---

