Taproot Support for BitGo Wallets

https://blog.bitgo.com/taproot-support-for-bitgo-wallets-9ed97f412460

Taproot Support for BitGo Wallets

 

 

As we draw closer to soft fork activation of Taproot on Bitcoin block 709,632, we’d like to share more details about Taproot support for BitGo hot and Qualified Custody wallets. We’re proud to announce that BitGo will have full API support for both sending to and receiving on Taproot addresses. As is typical with new Bitcoin features, Taproot is 100% opt in. There will be no interruption in Bitcoin services, nor requirements to create new wallets, upgrade old coins or move to new addresses.

Once we enable Taproot for BitGo wallets, it will be possible to create new Taproot addresses for receiving transactions, and these addresses will work seamlessly with existing wallets. It’s important to note that it may take time for other software in the Bitcoin ecosystem to upgrade, and until that time they may not be able to validate and send to Taproot addresses.

Please note that we are only releasing full Taproot support for our API at this time. UI support for sending to Taproot addresses will be available at launch, but creation of new Taproot addresses and spending Taproot inputs in transactions will not be available and will be enabled at a later date.

Upgrade Timeline

Here’s what we expect to happen over the next few days as we enable Taproot across our services:

11/12, ~15:00 PST - Taproot support will be enabled for BitGo wallets on Bitcoin’s Testnet.

11/14, ~00:00 PST - Block 709,632 mined, activating the new Taproot consensus rules.

11/14, ~17:00 PST - After monitoring the chain to ensure the new consensus rules have activated successfully and are behaving as expected, Taproot support will be enabled for BitGo hot wallets on Bitcoin’s Mainnet. BitGo Qualified Custody wallets will be able to create new Taproot addresses and receive funds on those addresses, but we will not be able to service withdrawals from Taproot addresses until approximately Wednesday, 11/17.

11/17 - Withdrawals enabled for funds on Taproot addresses in Qualified Custody wallets.

Note that these times are approximate and may change without notice. Please contact support@bitgo.com or subscribe to status.bitgo.com for the most up-to-date information.

What is Taproot?

There are lots of great articles explaining what Taproot is and what it means for users of Bitcoin. In summary, this upgrade allows for more flexibility in how Bitcoin codifies spending conditions, along with introducing support for Schnorr signatures, which is a simpler and more flexible type of digital signature. Also part of the Taproot upgrade is a new variant of the Bech32 address type, Bech32m.

Flexibility in Spending Conditions

Taproot changes the way complex scripts used for locking Bitcoin can be expressed. Instead of creating a single large script with many disjoint spending conditions, Taproot allows those conditions to each be expressed individually. Only the spending condition which is actually used ever needs to be revealed to the network, increasing privacy and potentially decreasing fees.

To make this all a bit more concrete, let’s take a look at a typical BitGo multi-signature wallet. We have three keys that are used with our wallets: the Client Key, which is held by our customer; the BitGo Key, which is held by us; and the Backup Key, which is held by a third party. Any two of these three keys for the specified wallet can be used to authorize a Bitcoin transaction.

Until Taproot came along, we needed to express this spending condition using OP_CHECKMULTISIG, which requires us to reveal all three of the public keys and two signatures. We are forced to write an extra public key to the blockchain, even though there isn’t a signature for that public key. Wouldn’t it be great if we could only reveal the public keys which correspond to the signatures actually used to spend?

With Taproot, only one of these three disjoint spending conditions needs to be satisfied:

• Signatures from Client and BitGo Keys
• Signatures from Client and Backup Keys
• Signatures from Backup and BitGo Keys

Instead of revealing all three of these public keys and signatures for two of them, it’s now possible to break these cases into three separate 2-of-2 multisig scripts and commit them into a Merkle tree. This tree of scripts is called a TapTree and only a small amount of data known as an inclusion proof is needed to show that a given spending script is present within it. When spending Taproot outputs, revealing the script to be used along with the inclusion proof and the two signatures needed to satisfy that particular script is enough to authorize the spend.

When Bitcoin locked in a 2-of-3 Taproot output of this design is spent, it costs slightly more (107.5 vBytes vs 104.5 vBytes) per input than spending a Native SegWit input using OP_CHECKMULTISIG due to the need to encode the inclusion proof of the 2-of-2 script. So, why would anyone use Taproot?

Privacy Improvements

When using Taproot, those watching the blockchain cannot know what other spending conditions went unused in the TapTree. There could have been no other conditions, or hundreds. Before Taproot, each of these spending conditions would have to be revealed and this is both a waste of space on the blockchain and makes for transactions that stand out from the crowd. By using Taproot, there’s less information required to be put on the public blockchain, and therefore less information that can be used to fingerprint transactions, all while remaining 100% accountable as to who signed the transaction.

Schnorr Signatures

For the first time in the history of Bitcoin, a new digital signature algorithm is being added alongside the traditional Elliptic Curve Digital Signature Algorithm (ECDSA) signatures. These new signatures are known as Schnorr signatures, and have a fixed 64 byte size and are also faster to compute since they have no need for a complex modular inverse operation.

It’s particularly noteworthy that Schnorr signatures can be aggregated with simple addition operations. This makes it easier to express some common spending conditions as a single key, requiring a single signature. The MuSig2 multisignature scheme will enable participants to safely compute aggregate public keys and signatures with only a small amount of added communication. Spending an input locked with such an aggregate key saves a whopping 47 vBytes per input (57.5 vBytes vs 104.5 vBytes) compared to Native SegWit OP_CHECKMULTISIG.

In a nod to Bitcoin’s traditional long time preference, BitGo Taproot addresses created from the very beginning will have a MuSig2 aggregate public key. The ability to spend using that aggregate public key will not be available at launch, as the details were still changing as late as July, 2021, and the reference implementation is not complete as of this writing. However, we’re very excited to release MuSig2 support in the near future, which will be an automatic and seamless upgrade for existing wallets with Taproot UTXOs. In essence, collecting Taproot UTXOs at launch will reduce future fees.

How do I use it with my BitGo wallet?

Once block 709,632 is mined, the new rules for Taproot will become activated on Bitcoin’s Mainnet. Shortly thereafter, we will allow API users to create new Taproot addresses. This will be possible by providing the chain: 30 parameter to the BitGo API.

BitGo API Example

export ACCESS_TOKEN="..."
export WALLET_ID="..."
export API_PATH="api/v2/tbtc/wallet/$WALLET_ID/address"
http "https://app.bitgo-test.com/$API_PATH" "Authorization:Bearer $ACCESS_TOKEN" chain:=30 | jq -r .address
# tb1paffnrlefgzafsvh4u40456009ylmexmj4fwk4q4ehl67r6ucpy4qpt63v5

 

If you’re using the BitGoJS SDK or BitGo Express, you’ll also need to provide the addressType: ‘p2tr’ parameter in addition to the chain: 30 parameter to the createAddress() function on Wallet objects. The minimum supported versions for Taproot support are 13.1.0 for the BitGoJS SDK and 9.10.1 for BitGo Express.

BitGo Express Example

docker run -it - rm -p 3080:3080 -d bitgosdk/express:9.10.1
export ACCESS_TOKEN="..."
export WALLET_ID="..."
export API_PATH="api/v2/tbtc/wallet/$WALLET_ID/address"
http "http://localhost:3080/$API_PATH" "Authorization:Bearer $ACCESS_TOKEN" chain:=30 addressType=p2tr | jq -r .address
# tb1p38fe05djt2lqa8y6vvp6uy9632km9c8jr23r2ul20pkn95hrcmjquv6mj8

BitGoJS SDK Example

const { BitGo } = require('bitgo');
const accessToken = '...';
const walletId = '...';

(async function main() {
  const bitgo = new BitGo({ accessToken, env: 'test' });
  const tbtc = bitgo.coin('tbtc');
  const wallet = await tbtc.wallets().get({ id: walletId });
  const { address } = await wallet.createAddress({ chain: 30, addressType: 'p2tr' });
  console.log(address);
  // tb1prgeah9zluyp3wkr374tgytc7kv6r6hza0h77t4e8gnc6nh4c03mqxm3qtn
})();

Long Term Impact

We expect adoption of Taproot to be a gradual process with wallets adding support for it over time, much like the adoption pattern for SegWit. As a multisig-only wallet service, the benefits for BitGo wallets are more pronounced and we expect to see significant long-term fee savings over our current multisig implementation as more of our customers switch to using Taproot and as we enable support for MuSig2.

In the short term, some wallets may not be able to send to Taproot addresses, and we expect that it may take several months for software across the Bitcoin ecosystem to be updated to fully support this new feature. We understand the importance of this upgrade to all BitGo wallet users, and we’re passionate about enabling our customers to use the most advanced features that Bitcoin offers.

If you share our vision for building the world’s most scalable Bitcoin services platform, apply here to join BitGo’s Bitcoin team. We’re looking for experienced engineers who are passionate about advancing the adoption of Bitcoin and are up for the challenge of the deeply technical projects on our roadmap. We see a future where Bitcoin can be used simply and securely by all.