As far as I can tell
importmulti does not work with zpub/ypub.
FWIW I prefer only to deal with xpubs, but I am curious.
Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up.Sign up to join this community
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.
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.