Orchard spending keys are encoded using Bech32m (not Bech32).
That’s great. But what about sapling?
Section 5.6.3.4 describes sapling raw spending key encoding’s human readable part but doesn’t specify the encoding to use. I might infer bech32 or bech32m, and given that Orchard calls out that it is bech32m rather than bech32, I might even infer that sapling must be the bech32 that orchard is differentiating itself from.
Not every ZIP has been fully incorporated into the protocol document, that mostly happened for only consensus-critical content. Yeah it can be a bit confusing.
Thanks, but it looks like ZIP-32 only describes the extended keys. I was looking for the raw key encoding.
However I just convinced myself it’s a non-issue, because nothing works with the raw 32-byte sapling spending key. Everything, even key derivation, seems to be based on the expanded key instead. And since it’s impossible to transform from expanded key back to non-expanded key, that makes the only 32-byte sapling key to ever exist (evidently) to be the ZIP-32 sapling master key, which isn’t that interesting when you already have a ZIP-32 extended sapling encoding.
So, without a use case and without a spec definition, I’m guessing the raw sapling encoding (whatever it is) with HRP of secret-spending-key-main has never been used nor will be.
That is indeed the case. This is an artifact of our attempt in ZIP 32 to preserve BIP 32’s hardened / non-hardened derivation logic, which required significant complexity and only works when using the expanded key format as the base (which the extended key format embeds). It’s impossible to both use ZIP 32 derivation for Sapling, and have a raw 32-byte Sapling spending key.
For Orchard we shed all the non-hardened complexity because we had never observed anyone using it. ZIP 32 derivation for Orchard is a much simpler process that directly produces the 32-byte Orchard spending key, and then the full Orchard key tree applies. Per the comment therein, we only define the Orchard extended spending key format for completeness; it’s expected that most wallets will only use the Orchard spending key format.