<p>I do not think that a wrapped segwit version of P2PK would have been attractive regarding weight in comparison.</p>
<p>The wrapped segwit outputs work by putting the witness program in the P2SH-redeemscript in the input script and a hash of the redeemscript in the output script. In the case of a P2SH-P2WPK, a witness program in the style of P2SH-P2WPKH could perhaps have been <code>&lt;version&gt; &lt;pubkey&gt;</code> (OP_CHECKSIG implied, like with the other segwit output constructions) and then just a signature instead of signature and public key in the witness stack.</p>
<p>A <a href="https://bitcoin.stackexchange.com/q/111392/5406">P2SH-P2WPKH redeemscript is 22 B long</a>. The hypothetical P2SH-P2WPK redeemscript would work out to be 35 B instead—13 B more. On the other hand, the witness stack would have been 34 B shorter because the public key is not appearing there, but because of the witness discount, this only saves 8.5 vB.</p>
<p>So, P2SH-P2WPK would have been 21 B less data on the wire, but 4.5 vB more expensive for the receiver to spend.</p>
<p>P2TR now is a spiritual successor of P2PK: it locks funds directly to a key and only requires a signature to spend the funds. Since P2TR was packaged with the more compactly serialized Schnorr signatures, the reduced input weight can almost balance out the increased cost of storing the whole public key instead of a 20-byte hash. The combination with the Schnorr signatures made it a lot more attractive by simplifying key aggregation.</p>
<p>There was <a href="https://bitcoin.stackexchange.com/a/107182/5406">no wrapped variant of P2TR</a> offered because 1) the P2SH-wrapper uses additional data increasing cost and blockspace footprint, 2) having only one output type leads to better privacy and homogeneity of transactions in the long term. The main reason to provide the wrapped variants when segwit came out was to provide forwards-compatibility for old wallets, so that they would be able to send to non-malleable segwit outputs immediately. Since many wallets can now send to bech32(m) addresses, this is no longer as pressing.</p>

CC BY-SA 4.0
2023-01-09T16:49:07.730Z
2023-01-13T18:51:30.707Z
2023-01-13T18:51:30.707Z
Murch
<p><a href="https://bitcoin.stackexchange.com/questions/109741/pure-p2wsh-invoice-address-in-legacy-wallets#comment124499_109742">Pieter Wuille wrote this</a>:</p>
<blockquote>
<p>There is no such thing as P2WPK; the only valid witness v0 programs are P2WPKH (OP_0 + hash160 of pubkey) or P2WSH (OP_0 + sha256 of script).</p>
</blockquote>
<p>But I don't understand the reason why. If P2SH-wrapped P2WPK would be hash-protected by P2SH already, didn't back in the day made sense to offer that script combination for the sake of shorter script and smaller fees?</p>

<segregated-witness><p2sh><bip>
Why wasn't P2SH-wrapped P2WPK added to any BIP?
Mercedes
# Why wasn't P2SH-wrapped P2WPK added to any BIP?

(Asked by: username_0 on 2023-01-07)

[Pieter Wuille wrote this](https://bitcoin.stackexchange.com/questions/109741/pure-p2wsh-invoice-address-in-legacy-wallets#comment124499_109742):

> There is no such thing as P2WPK; the only valid witness v0 programs are P2WPKH (OP\_0 + hash160 of pubkey) or P2WSH (OP\_0 + sha256 of script).

But I don't understand the reason why. If P2SH-wrapped P2WPK would be hash-protected by P2SH already, didn't back in the day made sense to offer that script combination for the sake of shorter script and smaller fees?

**Tags:** segregated-witness, p2sh, bip


---

## 1 answers

### Answer by username_1 on 2023-01-09. Score: 1 | Accepted answer

I do not think that a wrapped segwit version of P2PK would have been attractive regarding weight in comparison.

The wrapped segwit outputs work by putting the witness program in the P2SH-redeemscript in the input script and a hash of the redeemscript in the output script. In the case of a P2SH-P2WPK, a witness program in the style of P2SH-P2WPKH could perhaps have been `<version> <pubkey>` (OP\_CHECKSIG implied, like with the other segwit output constructions) and then just a signature instead of signature and public key in the witness stack.

A [P2SH-P2WPKH redeemscript is 22 B long](https://bitcoin.stackexchange.com/q/111392/5406). The hypothetical P2SH-P2WPK redeemscript would work out to be 35 B instead—13 B more. On the other hand, the witness stack would have been 34 B shorter because the public key is not appearing there, but because of the witness discount, this only saves 8.5 vB.

So, P2SH-P2WPK would have been 21 B less data on the wire, but 4.5 vB more expensive for the receiver to spend.

P2TR now is a spiritual successor of P2PK: it locks funds directly to a key and only requires a signature to spend the funds. Since P2TR was packaged with the more compactly serialized Schnorr signatures, the reduced input weight can almost balance out the increased cost of storing the whole public key instead of a 20-byte hash. The combination with the Schnorr signatures made it a lot more attractive by simplifying key aggregation.

There was [no wrapped variant of P2TR](https://bitcoin.stackexchange.com/a/107182/5406) offered because 1) the P2SH-wrapper uses additional data increasing cost and blockspace footprint, 2) having only one output type leads to better privacy and homogeneity of transactions in the long term. The main reason to provide the wrapped variants when segwit came out was to provide forwards-compatibility for old wallets, so that they would be able to send to non-malleable segwit outputs immediately. Since many wallets can now send to bech32(m) addresses, this is no longer as pressing.


---

