Isn't SSSS each seed at 2-of-2 with Codex32 or SLIP39 and encrypting the descriptor better than this?

[BenWestgate]

BIP85 has a way to generate GPG keys from the root master xprv, that can create a decryption key for each extended key in a descriptor and the descriptor can be encrypted to all keys it contains. Then the seed backup that derives those keys can be secret split.

This seems to allow more flexibility as the privacy could be threshold 3 or more and extra backups could be made of the seed so that any T of them restores the seed and can decrypt the descriptor (that's stored more or less publicly).

Is the only reason for this proposal to still support BIP39?

In the case of an over-eager heir, or crooked estate lawyer, simply don't encrypt the descriptor to them. As long as the descriptor is encrypted to N - T + 1 parties it will not block spending policies.

[BenWestgate]

https://github.com/BlockstreamResearch/codex32/discussions/65#discussion-5627321

This was something we arrived on in this discussion in the context of codex32 (SSSS enabled seed backups).

It's possible to even threshold encrypt so that it takes any T (which could be a different T than the multisig) keys to decrypt the descriptor.

[mflaxman]

I don't understand the question, so I'm afraid I don't have a good answer.

My understanding is that BIP85 is for one user to create many seeds they alone control. Although these seeds could be used in a threshold multisig scheme, that's not really the purpose (you won't find the word multisig in BIP85). And of course creating multiple seeds on a single device partially defeats the point of multisig in the first place!

The primary use-case for blinded xpubs has been third party blinding (non-interactively) in a threshold multisig scheme. The multisig wallet collaboratively controls funds and different parties have different spending/viewing access, and each alone creates their own keys. First-party blinding is neat and has interesting use-cases (a seed phrase in a bank vault for example), but has more tradeoffs.

One of the main benefits of this scheme is that it's been used live in production for many years now, and works across several existing hardware wallets.

As for BIP39, it's quite pervasive and even though I don't love everything about it it has some great features (checksum) and near 100% adoption. Everything blinded xpubs accomplishes could be better done via a stealth address construction, but BIP32 standards compliance is what allows this to work in production across vendors, which for multisig is the top priority.

Since every party creates their own keys, some/all can create a BIP39 seed phrase using BIP85. Nobody else would know and that's perfectly fine.

[BenWestgate]

BIP85 can also be used to generate a gpg RSA key pair from your master seed. I was suggesting encrypting the descriptor to that rsa public key (and perhaps to some co-signers) rather than randomizing the bip32 path.

Seems simpler to back up and more private.

how to blind xpub(s) such that possession of a given seed phrase reveals nothing about what it protects.

Regarding this, usually you'd use shamir secret sharing or a bip39 passphrase to make possession alone of one backup reveal nothing, correct?

Doesn't a random derivation path seem more complicated?

To me that looks like a convoluted 2-of-2 secret sharing scheme where to recover the child key you need to find both the seed and the derivation path. Two "things-you-have" to recover analogous to (but not as flexible as) two threshold 2 Shamir shares.

One of the main benefits of this scheme is that it's been used live in production for many years now...

So has gpg. And it would also blind things like threshold, number of keys and other details from the wallet descriptor that normally leaks privacy in a multisig backup.

I'll need private multisig backups for my own project and your solution is all I found.

[mflaxman]

I was suggesting encrypting the descriptor to that rsa public key (and perhaps to some co-signers) rather than randomizing the bip32 path.

Under current multisig standards (p2sh/p2wsh), possession of a single seed phrase that was never used to sign anything reveals info about your spent (and potentially unspent) UTXOs. An attacker doesn't even need your output descriptor at all, just a single seed phrase. That's the problem this exists to solve.

I do think there's room for an SSSS standard for encrypting (multisig) output descriptors, but that's for all multitisg output descriptors regardless of whether they use anything in this repo.

[BenWestgate]

Under current multisig standards (p2sh/p2wsh), possession of a single seed phrase that was never used to sign anything reveals info about your spent (and potentially unspent) UTXOs.

Is that still true for taproot's multi_a()?

An attacker... just [needs] a single seed phrase. That's the problem this exists to solve.

Why not use a passphrase or shamir secret sharing to protect the seed phrase then? It would be someone's entire savings if it were a single sig backup, it should be protected.

I do think there's room for an SSSS standard for encrypting (multisig) output descriptors,

I may write a proposal next year.