Multisig Enhanced Privacy Scheme

I've been working on ways to prevent privacy leaks in multisig quorums, and have come up with a creative use of BIP32 paths.

Working code with broadcasted transactions can be found here: https://github.com/mflaxman/blind-xpub

This scheme allows for some powerful new features:

- If an unauthorized party gains access to a BIP39 seed phrase, that party learns nothing about transactions in any multisig quorum that seed participates in
- It allows trusted-minimized third parties (e.g. a lawyer, accountant, heir, close friend, "uncle Jim" bitcoiner, collaborative custody service, etc) to hold an emergency recovery key in a multisig quorum with zero knowledge of what that key protects

This scheme has been live on mainnet for some time and has multi-vendor support from several Coordinators and Signers. I am anecdotally aware of large sums of bitcoin that are currently being HODLed with it.

My hope in publishing this is to encourage more interoperable hardware wallet / coordinator software support for enhanced privacy, along with improved UX at each step. Feedback is welcome.

Best,

Michael

On Tue, Jul 20, 2021 at 07:44:19PM +0000, Michael Flaxman via bitcoin-dev wrote:

> I've been working on ways to prevent privacy leaks in multisig
> quorums, and have come up with a creative use of BIP32 paths.

It seems to me like it would be rare for an attacker to obtain a private BIP32 seed but not simultaneously learn what HD paths it's being used with. I assume basically everyone is storing their descriptors (or descriptor equivalents) alongside their seeds; doing so helps ensure a robust recovery.

However, to the degree that privacy from seed thieves is a problem we want to solve, I think it's largely fixed by using taproot with multisignatures and threshold signatures. As long as participants aren't reusing the same keys in different contexts, it shouldn't be possible for a third party who doesn't know all involved pubkeys to determine that any particular aggregated pubkey contained material from a certain base pubkey.

I would suggest that it's probably more beneficial for wallet authors to work on implementing support for taproot and MuSig or MuSig2 than support for this scheme, although maybe I'm misunderstanding this scheme's motivation.

-Dave