The Internet Computer continues to improve cross-chain interoperability, with the Deuterium milestone enabling containers to create threshold Schnorr signatures, including the BIP340 standardized Schnorr used in Bitcoin, allowing containers to generate Pay-To-Taproot (P2TR) addresses and initiate Taproot transactions.
In this blog post, we will explain the development of P2TR support on the Internet Computer, the initial limitations faced by containers, and how the recently added key adjustment in threshold Schnorr signatures expands the cross-chain capabilities of container smart contracts, making it easier to integrate with the Bitcoin meta-protocol.
P2TR Address
The P2TR addresses specified in BIP341 allow for funds to be spent using two different 'paths':
Key Path: A transaction conducted through the key path is valid if it contains a Schnorr signature successfully verified by the public key specified in the P2TR address.
Script Path: Transactions conducted through the script path require the spender to provide inputs that satisfy any script using Bitcoin's script opcodes, a key feature of the script path is that an address can contain multiple scripts (any of which can be used to spend funds), and the contents (even quantity) of the qualifying scripts remain confidential until spending occurs; furthermore, even after spending, only the actual script inputs used to meet the conditions will be revealed.
Additionally, if an address supports both key and script paths, consumption through the key path will obscure the existence of the script path. These properties enhance transaction privacy, as chain observers cannot infer the internal financial arrangements of a specific address, such as the existence of multisignature setups.
Initial Limitations of P2TR on ICP
Initially, the Internet Computer only supported a limited type of P2TR address, thereby restricting the available payment mechanisms:
P2TR without Script Path: This type of address does not contain a Merkle tree of alternative scripts, meaning it can only be used via the key path. The Internet Computer has supported this since the release of the Deuterium milestone, as key path spending only requires a valid Schnorr signature, intentionally omitting the Merkle root to obscure whether any alternative spending scripts exist.
P2TR without Available Key Path: This type of address can only be used via the script path, which may include Schnorr public keys within the leaves of the Merkle tree. Although these addresses contain the internal public key of the key path, the Internet Computer does not support its use for signing.
This limitation means that containers creating P2TR addresses must choose in advance which path to support; containers cannot create addresses that allow consumption through both key paths and script paths simultaneously.
Key Adjustment in Threshold Schnorr Signatures
Consuming from a P2TR address involves creating signatures using public keys derived from the internal key via an additive key derivation scheme. This process involves:
Hashes the internal public key and Merkle tree root (representing alternative scripts) to derive the 'adjustment';
Adds this adjustment to the secret key and internal public key;
Generates a signature corresponding to the adjusted public key embedded in the address using the adjusted key.
In the threshold variant of Schnorr signatures, key adjustments are inherently more complex because the keys do not exist in their complete form; instead, they are distributed across multiple copies running in the subnet, with each copy holding a part of the key, requiring each copy to apply the adjustment to its respective part.
When the Deuterium milestone was released, the Internet Computer did not support key adjustments when requesting threshold Schnorr signatures, meaning that containers could not generate P2TR addresses that allow spending through key paths and script paths; thus, containers had to decide how to use funds when creating addresses, reducing the flexibility of Dapps that require dynamic spending options.
Moreover, most Bitcoin libraries themselves do not support Taproot addresses, which can be used via the key path with unadjusted keys. Developers integrating threshold Schnorr signatures into their Dapps need to have a deeper understanding of the Taproot mechanism.
Expanding P2TR Support on ICP
We are excited to announce that the Schnorr signature API now supports key adjustments - containers can now create more common and flexible Taproot addresses that support script path and key path spending using adjusted internal keys, this enhancement:
Combining the Internet Computer with standard Taproot functionality;
Simplifying development for Dapp creators;
Expanded the flexibility of Bitcoin-based smart contracts on the Internet Computer.
The new key adjustment feature can be used as an optional auxiliary parameter within the existing sign_with_schnorr API, allowing developers to include the MAST root in their signature requests, thereby fully supporting the script path spending mechanism of Taproot on the Internet Computer.
Specifically, the sign_with_schnorr API's parameter sign_with_schnorr_args has been expanded to include an optional field aux for specifying some auxiliary information. Initially, this enumeration will have a BIP341 variant for specifying the Merkle root hash of the script path, and further extensions of the API can reuse this auxiliary input to encode additional auxiliary information.
This new interface allows applications to fully support a range of transactions supported by Taproot, ensuring that containers running on the Internet Computer can participate in any Bitcoin meta-protocol, such as Ordinals, BRC-20, Runes, Atomical, etc.
For more details, please refer to the Internet Computer specifications, chain integration documentation, BIP341 specifications, and the Internet Computer example library containing examples of handling Taproot spending.
IC Content You Care About
Technical Progress | Project Information | Global Activities
Follow the IC Binance Channel
Stay Informed
