[bitcoin-dev] Multisig Enhanced Privacy Scheme

[bitcoin-dev] Multisig Enhanced Privacy Scheme

[Michael Flaxman]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1367 bytes --]

Re: [bitcoin-dev] Multisig Enhanced Privacy Scheme

[David A. Harding]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]