<blockquote>
<p>If I got it right, my legacy wallet seems to be able to get me:</p>
<ul>
<li>Classic P2PKH invoice addresses (appearing as base58).</li>
<li>P2SH-wrapped P2WSH invoice addresses (appearing as base58).</li>
<li>P2WPKH invoice addresses (appearing as 42-length bech32 sequences).</li>
</ul>
</blockquote>
<p>Almost. It is producing P2SH-wrapped P2WPKH; not P2SH-wrapped P2WSH.</p>
<blockquote>
<p>If I got it right, it won't ever get me P2TR invoice addresses until migrated into descriptors wallet.</p>
</blockquote>
<p>Only descriptor wallets support creating P2TR receiving addresses. It still requires actually having a taproot descriptor in that wallet. This won't become the default until probably some time after taproot is active on mainnet (currently estimated to happen around November 16th 2021).</p>
<blockquote>
<p>But why it doesn't feature a stream of &quot;pure&quot; P2WSH invoice addresses (appearing as 62-length bech32 sequences)? Is it because those make sense only in non-trivial script environments such as multi signature or others, and therefore hidden to me as a shorter-length-addresses simplification?</p>
</blockquote>
<p>Well, let's take a step back. P2WSH, like P2SH, is a mechanism for turning other scripts into addressable outputs. So what you're talking about is probably really something like P2WSH-P2PK or P2WSH-P2PKH. Both of these are completely pointless, as they're strictly more expensive to use than the corresponding P2WPKH variant. P2WSH is only useful when there is a script that's more complex than a single-key policy, like multisig, or the more advanced contracts used e.g. in Lightning.</p>
<p>It isn't so much that these are hidden from you - they're just not supported by the legacy wallet as automatically-created addresses. It is possible to explicitly import such a script (I think), and it would work, but you'd need to do it for every address individually. The wallet simply generates public keys, and can expose them as P2PKH, P2WPKH, or P2SH-wrapped P2WPKH addresses.</p>
<p>In a descriptor wallet, if you wanted to, you could import a descriptor for such a P2WSH-P2PK(H) script if you wanted to, and it'd actually generate addresses for it. If you really wanted to, you could even construct P2SH-P2WSH-P2PKH scripts. All of these are still pointless, though.</p>

CC BY-SA 4.0
2021-09-19T20:49:42.630Z
If P2SH (when used for wrapping) walls contents behind it in some way that contents aren't revealed until spent, then why `getnewadress label p2sh-segwit` defaults to P2SH-wrapped P2WPKH instead of optimizing it to P2SH-wrapped P2WPK? Is it because OP_HASH and the pubkey hash is cheaper than just the pubkey? (I can promote this to question if that's more comfortable).
Mercedes
CC BY-SA 4.0
2021-09-19T21:10:09.257Z
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).
Pieter Wuille
CC BY-SA 4.0
2021-09-19T20:35:51.617Z
2021-09-19T20:35:51.617Z
Pieter Wuille
<p>If I got it right, my legacy wallet seems to be able to get me:</p>
<ul>
<li>2000s-era P2PKH invoice addresses (appearing as base58).</li>
<li>P2SH-wrapped P2WSH invoice addresses (appearing as base58).</li>
<li>P2WPKH invoice addresses (appearing as 42-length bech32 sequences).</li>
</ul>
<p>If I got it right, it won't ever get me P2TR invoice addresses until migrated into descriptors wallet.</p>
<p>But why it doesn't feature a stream of &quot;pure&quot; P2WSH invoice addresses (appearing as 62-length bech32 sequences)? Is it because those make sense only in non-trivial script environments such as multi signature or others, and therefore hidden to me as a shorter-length-addresses YAGNI simplification?</p>

<bitcoin-core><wallet><p2wsh>
"pure" P2WSH invoice address in legacy wallets?
Mercedes
# "pure" P2WSH invoice address in legacy wallets?

(Asked by: username_0 on 2021-09-19)

If I got it right, my legacy wallet seems to be able to get me:

* 2000s-era P2PKH invoice addresses (appearing as base58).
* P2SH-wrapped P2WSH invoice addresses (appearing as base58).
* P2WPKH invoice addresses (appearing as 42-length bech32 sequences).

If I got it right, it won't ever get me P2TR invoice addresses until migrated into descriptors wallet.

But why it doesn't feature a stream of "pure" P2WSH invoice addresses (appearing as 62-length bech32 sequences)? Is it because those make sense only in non-trivial script environments such as multi signature or others, and therefore hidden to me as a shorter-length-addresses YAGNI simplification?

**Tags:** bitcoin-core, wallet, p2wsh


---

## 1 answers

### Answer by username_1 on 2021-09-19. Score: 0 | Accepted answer

> If I got it right, my legacy wallet seems to be able to get me:
>
> * Classic P2PKH invoice addresses (appearing as base58).
> * P2SH-wrapped P2WSH invoice addresses (appearing as base58).
> * P2WPKH invoice addresses (appearing as 42-length bech32 sequences).

Almost. It is producing P2SH-wrapped P2WPKH; not P2SH-wrapped P2WSH.

> If I got it right, it won't ever get me P2TR invoice addresses until migrated into descriptors wallet.

Only descriptor wallets support creating P2TR receiving addresses. It still requires actually having a taproot descriptor in that wallet. This won't become the default until probably some time after taproot is active on mainnet (currently estimated to happen around November 16th 2021).

> But why it doesn't feature a stream of "pure" P2WSH invoice addresses (appearing as 62-length bech32 sequences)? Is it because those make sense only in non-trivial script environments such as multi signature or others, and therefore hidden to me as a shorter-length-addresses simplification?

Well, let's take a step back. P2WSH, like P2SH, is a mechanism for turning other scripts into addressable outputs. So what you're talking about is probably really something like P2WSH-P2PK or P2WSH-P2PKH. Both of these are completely pointless, as they're strictly more expensive to use than the corresponding P2WPKH variant. P2WSH is only useful when there is a script that's more complex than a single-key policy, like multisig, or the more advanced contracts used e.g. in Lightning.

It isn't so much that these are hidden from you - they're just not supported by the legacy wallet as automatically-created addresses. It is possible to explicitly import such a script (I think), and it would work, but you'd need to do it for every address individually. The wallet simply generates public keys, and can expose them as P2PKH, P2WPKH, or P2SH-wrapped P2WPKH addresses.

In a descriptor wallet, if you wanted to, you could import a descriptor for such a P2WSH-P2PK(H) script if you wanted to, and it'd actually generate addresses for it. If you really wanted to, you could even construct P2SH-P2WSH-P2PKH scripts. All of these are still pointless, though.

> **Comments:**
> **username_0**: If P2SH (when used for wrapping) walls contents behind it in some way that contents aren't revealed until spent, then why `getnewadress label p2sh-segwit` defaults to P2SH-wrapped P2WPKH instead of optimizing it to P2SH-wrapped P2WPK? Is it because OP_HASH and the pubkey hash is cheaper than just the pubkey? (I can promote this to question if that's more comfortable).  
> **username_1**: 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).  

---

