Getting Taproot ready for multisig

As of 5:15 UTC on Sunday, Nov. 14—or block 709,632—the long-anticipated Taproot soft fork is active on the bitcoin network. This upgrade will open the door to several benefits for bitcoin users, particularly those using bitcoin multisig.

Taproot offers to reduce the blockchain footprint of multisig transactions, thus improving multisig users’ privacy and significantly lowering associated fees (multisig transactions tend to be more expensive than singlesig transactions).

But these benefits don’t materialize overnight. A lot of hard work needs to be done at the application layer by hardware and software wallet developers to integrate the features enabled by Taproot into wallets. Ideally, any changes to multisig design need to happen in coordination with, and with full cooperation from, a wide range of wallet developers to ensure that each of their solutions is compatible and leads to fewer engineering headaches!

Taproot at Unchained

Over the past few weeks, we’ve been in discussions with our awesome partners (e.g., Trezor, Ledger, Coldcard) and advisors (thanks in particular to Michael Flaxman and Jimmy Song) on how Taproot might benefit Unchained’s clients in particular. We’d like to take this opportunity to give you insight into our decision-making process and how we have been thinking about implementing support for Taproot.

Why the wait?

Several companies have announced their support for Taproot even prior to activation of the upgrade. The answer lies at the core of our product offering. For custodial service providers, taking advantage of Taproot’s new functionality is relatively straightforward; all of the changes can be made in software unilaterally by the service provider and made available to end-users whenever the changes are ready. Unchained’s product suite, on the other hand, is built on top of the concept of collaborative multisig custody, where both Unchained and our clients share control over funds.

What is the best way for us to proceed?

This is a more subtle question. When building a product that interacts with the Bitcoin network, there are implementation details that don’t require much research and development because there’s a shared understanding in the bitcoin community of what current best practices are and what service providers need to do to implement those BCPs. Examples of this might include avoiding address reuse or batching transactions when possible.

Multisig on Taproot is on the other end of the spectrum; no current best practices are defined. Due to its unique role in the bitcoin ecosystem, Unchained is by definition leading the way in defining what BCPs for multisig on Taproot will look like.

Four questions we’re asking

To that end, we’ve been engaging with external advisors and hardware wallet vendors to map out a way forward for multisig collaborative custody in a post-Taproot world. We’ve focused on four questions in our discussions:

1. What are the options available to us;
2. What will other multisig providers and hardware vendors be supporting;
3. What features can Taproot provide that will provide a meaningful benefit to our clients;

and most importantly,

4. How would a responsible steward of the bitcoin protocol implement multisig on Taproot?

While we don’t yet have comprehensive answers to these questions, we have begun to deeply consider the current state of Taproot multisig, and we have made early decisions about which approaches we intend to support.

The current state of Taproot multisig and how we’re moving forward

While multisignature support for Taproot has been well specified, there are no existing “multisig standards” for Taproot, per se. BIP 342 does helpfully offer several suggestions for how multisig can be implemented via Taproot, which we’ve been using as a guide.

Probably not MuSig or threshold Schnorr signatures

There are four proposed methods in BIP 342 (“Validation of Taproot scripts”) for implementing a threshold k-of-n policy using Taproot and Tapscript. Of these proposed methods, the last two use MuSig (MuSig2 and MuSig-DN) and/or threshold Schnorr signatures. MuSig isn’t standardized yet, and aggregating Schnorr signatures raises concerns about how nonces should be handled to avoid the risk of nonce reuse and how to implement an interactive signing protocol. Given these constraints, we have decided against those two approaches for the time being.

OP_CHECKSIGADD and multiple k-of-k look promising

The remaining two choices are both implemented using OP_CHECKSIGADD, a new Tapscript specific opcode. There’s a straightforward single branch k-of-n construction described in BIP 342:

The second option is to implement a k-of-n policy using multiple k-of-k leaves:

After extensive deliberations, we’ve decided we’d ideally like to support both OP_CHECKSIGADD based approaches, with a preference for the multiple k-of-k approach, in order to offer increased privacy to Unchained clients. We believe that any additional bit of protection against unnecessary and unwarranted surveillance of bitcoin transaction data that we can offer to Unchained’s customer base is worth the effort.

We’ve begun the process of reaching out to hardware wallet providers to see what they’re comfortable supporting and let them know our decision-making process and how we intend to proceed.

Transparency and collaboration as we go

Getting from where we are now—having preliminary discussions with hardware wallet vendors—to actually offering support for Taproot to Unchained’s clients will be a lengthy process. We might take detours along the way, e.g., providing support for withdrawing to Taproot P2TR addresses as an interim step, or even elect to hold off on implementing multisig on Taproot based on what we discover and what will benefit our clients.

Whatever approach we elect to take, we’ll share our decision-making process openly and engage with our peers in the bitcoin community. Expect us to have some more updates early next year!