0

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?

Improve this question

1 Answer 1

Reset to default
0

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.

Improve this answer
2
  • 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
    Commented Sep 19, 2021 at 20:49
  • 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
    Commented Sep 19, 2021 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.