Multisig and privacy

If you have a multisig wallet, you need a few pieces of information to successfully spend your coins: you need signatures from enough keys (eg if you have a 3 of 5, you need at least 3 signatures), and you need know how to assemble the signatures so that it can produce a final transaction with signatures that match the locking script on that particular address.

I love multisig wallets.

Having a threshold n of m kind of setup allows you to have some redundancy in case of lost keys and it allows you to avoid a single point of failure (keys can be geographically distributed and you can use different devices with each key).

An additional advantage of multisig is that you can safely involve other people in your key setup without giving them spending control over your coins. Most commonly this looks like collaborative custody setups like Unchained, Nunchuk, and Bitkey. Your wallet is a 2 of 3 and you give at least one key to a company that promises to sign on your behalf or provide the key back to you in the event that you lose one of your primary keys.

These kind of setups allow you to retain unilateral control (unless you lose a key), but also give you some assurance that if you screw up and lose one of your keys, you can still recover. It’s a pretty good deal!

The privacy problem

Unfortunately, most of these collaborative custody setups involve the user providing a descriptor or extended public key to the company with whom they are collaborating. This is because in order to create signatures for multisig wallets, you don’t just need a key, you also need to know how the key “fits” in the particular locking script (aka address) for which you are trying to create a valid signature.

Descriptors and public keys carry a lot of information about your wallet – so much so that your collaborator will be able to see all your past transactions and keep track of any new ones you make, even if you sign them with the keys you unilaterally control.

High tech solutions

Taproot introduced a new way to do multisigs where you hide each possible spending path in a separate leaf so when the transaction gets included in the blockchain it doesn’t reveal if there are other spending paths. In this case you would only need to give your collaborator the public key corresponding to the spending paths that involve their key – and they wouldn’t be able to tell when you used spending paths that didn’t involve their key.

FROST is another way to get around this: you can create a master key by combining a number of individual keys. When it comes time for signing, the collaborator can contribute to the signature without knowing enough information to track other signatures.

Both of these solutions involve Schnorr signatures and while adoption for taproot addresses has been pretty strong, FROST is still just getting going.

The chaincode solution

The folks at Bitkey recently proposed a BIP for a new way to preserve privacy for multisig users who want to work with a collaborator and it is pretty cool.

The public key a user shares with their collaborator has a little more information than just the key – and they are usually referred to as an extended public key (xpub). If you really want to go deep on what makes up an xpub, check out this Stack Exchange answer and this article from LearnMeABitcoin.

As far as Bitkey’s BIP, all we need to know is that an xpub includes something called a chaincode. The chaincode is used in deriving the individual keys used each time you generate a new address. It prevents someone from using the information revealed in the signature of one address to derive information about your other addresses, particularly their private keys. The chaincode is an extra secret that makes it so that the keys to your addresses aren’t derived solely from your master keys.

Bitkey is proposing a kinda cool way of using the chaincode to limit the amount of visibility a collaborator (in their case: Bitkey) has into your transactions.

They propose that the collaborator holds a key without the chaincode. When a signature is requested from the collaborator, the user provides a slightly altered chaincode that will work for signing that particular transactions but that won’t give the collaborator insight into the users other transactions.

If such a limited key got compromised the damage would be significantly less than for a normal key. From the delving discussion:

As the custodian learns of scalar tweaks, it is signing transactions that spend the associated UTXOs, which quickly limits the usefulness of the child keys that the tweak derives. If a custodian’s systems are fully compromised, at most an attacker would be able to race the counterparty to sign for UTXOs as scalar tweaks are disclosed. Of course, in addition to the custodian key, such an attacker would also need to have compromised sufficient keys to sign for the multisig script.

In addition to being used in a collaborative custody setup, this method could also be used in a multisig where a user has one key that they keep in a slightly less secure environment. Such a key could be “limited” in the manner so that it is only able to contribute to spends when the more powerful keys provide the chaincode information.

Conclusion and further reading

This is a pretty neat idea. I’m pleased to see Bitkey thinking this way. It sounds like they are eager and plan on being the first to implement it. As I said at the top: multisig is awesome and things like taproot, FROST, and this chaincode delegation idea are making it even better.