The Internet Computer continues to improve cross-chain interoperability, with the Deuterium milestone enabling containers to create threshold Schnorr signatures, including the Schnorr standardized in BIP340 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 adjustments in threshold Schnorr signatures extend the cross-chain functionality of container smart contracts, making it easier to integrate with the Bitcoin meta-protocol.
P2TR Address
P2TR addresses specified in BIP341 allow using two different 'paths' to spend funds:
Key Path: If a transaction conducted via a key path contains a Schnorr signature that is successfully verified using the public key specified in the P2TR address, then the transaction is valid.
Script Path: Transactions conducted via a script path require the spender to provide inputs that satisfy arbitrary scripts 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 prior to spending occurring, the content (and even the number) of the scripts that satisfy the conditions are kept confidential; furthermore, even after spending occurs, only the actual script inputs used to satisfy the conditions will be made public.
Moreover, if an address supports both key and script paths simultaneously, consumption via the key path will hide the existence of the script path, these properties enhance the privacy of transactions because chain observers cannot infer specific internal financial arrangements of a particular address, such as the existence of multi-signature setups.
Initial Limitations of P2TR on ICP
Initially, the Internet Computer only supported a limited type of P2TR address, 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 key paths; the Internet Computer has supported this since the release of the Deuterium milestone, as key path spending only requires a valid Schnorr signature, deliberately omitting the Merkle root to hide whether any alternative spend scripts exist.
P2TR with No Available Key Path: This type of address can only be used via script paths, which may include Schnorr public keys inside the Merkle tree leaves; although these addresses contain the internal public key of the key path, the Internet Computer does not support using it to sign.
This limitation means that containers creating P2TR addresses must choose in advance which path to support; containers cannot create addresses that allow consumption via both key paths and script paths simultaneously.
Key Adjustment in Threshold Schnorr Signatures
Consuming from a P2TR address involves creating a signature using the public key derived from the internal key via an additive key derivation scheme; this process involves:
Hash the internal public key and Merkle tree root (representing alternative scripts) to derive the 'additional adjustment';
Add this adjustment to the secret key and internal public key;
Generate 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 complete form; rather, they are distributed across multiple copies running in subnets, each holding a part of the key, requiring each copy to apply the adjustment to their respective parts.
When the Deuterium milestone was released, the Internet Computer did not support key adjustments when requesting threshold Schnorr signatures, meaning containers could not generate P2TR addresses that allow spending through key paths and script paths; therefore, containers had to decide how to utilize funds when creating addresses, reducing the flexibility of Dapps that require dynamic spending options.
Additionally, most Bitcoin libraries do not support Taproot addresses themselves, which can be used via key paths with unadjusted keys; developers integrating threshold Schnorr signatures into 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 use adjusted internal keys to support script path and key path spending, 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 in 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 parameter sign_with_schnorr_args of the sign_with_schnorr API has been expanded to include an optional field aux to specify some auxiliary information; initially, this enumeration will have a BIP341 variant for specifying the root hash of the Merkle script path, and further expansions 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 fusion documentation, BIP341 specifications, and the Internet Computer example library that includes examples of handling Taproot spending.
IC Content You Care About
Technical Progress | Project Information | Global Activities
Follow IC Binance Channel
Stay Updated
