2

As far as I can tell importmulti does not work with zpub/ypub.

Why not?

FWIW I prefer only to deal with xpubs, but I am curious.

3

The "xpub" format was defined by BIP32. It's a standard that specifies how to derive public keys from master public keys and seeds. Parts of it are widely adopted, some parts aren't. However, it does not say anything about how the keys it generate should be turned into addresses, only the keys themselves.

Now, at the time, there was only really one obvious way of turning a key into an addresses: by using its hash in a P2PKH (1...) address. This was implemented by numerous pieces of software, which more often than not treated "importing an xpub" as "importing an xpub and watching all P2PKH addresses for the resulting keys". This made sense, because it was how everyone wanted to use them anyway.

Then came along Segwit, which introduced two new common ways of paying to single-key outputs. Wallet software needed a way to "mark" an xpub as being intended to be used for P2WPKH (bc1...) or P2SH-P2WPKH (3...), instead of the traditional P2PKH. As the xpub standard had become interpreted as P2PKH only (rather than an address-agnostic way of describing public keys), something other than xpubs were needed. This is why some people adopted ypub/zpub for this purpose.

I believe this is confusing, as it is unclear now what an xpub means, and it is not scalable: we can't keep inventing new xpub-like formats for all types of addresses that may be invented. Especially with the introduction of multisig and more complex constructions, which simply don't fit into a single xpub-like thing (because you'll need to combine multiple of them).

For this reason, Bitcoin Core is using (and further developing) an approach called Output Descriptors. These are strings that specify exactly and unambiguously what scripts/addresses are desired, based on the involved public keys. These expressions support xpubs, but only in the original address-neutral meaning - the rest is conveyed using functions on top of them. For example:

  • pkh(xpub.../44'/0'/0'/0/*) would describe the BIP44 addresses derived from a particular xpub (P2PKH).
  • sh(wpkh(xpub.../49'/0'/0/*)) would describe the BIP49 addresses derived from a particular xpub (P2SH-P2WPKH).
  • wsh(multi(2,xpub1.../*,xpub2.../*,xpub3.../*)) represents a 2-of-3 P2WSH-embedded multisig.

There are many more features in descriptors, and there is ongoing development.

Disclaimer: I'm the author of BIP32.

1

ypub and zpub are not things that are specified in BIPs. They are things that people have decided to use and specify outside of the BIPs process.

Furthermore, they are a layer violation. They specify what kind of addresses a public key should be used to create, but key generation and the address type to create from a key are entirely separate things that shouldn't be mixed together.

Lastly, Bitcoin Core does not currently support having a public key be for a specific address type. Any public key in Bitcoin Core can be used for all 3 address types and there is no separation of derivation paths or master keys for different address types.

  • Good to know, I agree with that philosophy. I think adding extra layers of confusion to something that is already hard to grasp for average wallet users is not a good idea either... – Fontaine Jul 20 at 18:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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