feat(crypto): Add support for Schnorr auxiliary inputs

[mraszyk]

The PR proposes extending the sign_with_schnorr function to support "key-tweaking" as specified in Taproot (BIP341). An optional auxiliary argument is added to the function inputs, allowing the caller to specify the root of the Merkle tree that encodes alternative spending paths, which is then used by the replicas to tweak the signing key. This enhancement enables canisters to create Bitcoin Taproot addresses that fully comply with the BIP341 specifications.

Background

The Deuterium Milestone introduced support for threshold Schnorr signatures, including Schnorr-BIP340 signatures used in Bitcoin. This allowed canisters to generate Pay-to-Taproot (P2TR) addresses and execute Taproot transactions. P2TR addresses, as defined in BIP341, support two possible spending paths:

• Key path: Spending by signing a transaction with a Schnorr key.
• Script path:Spending by revealing an alternative script stored in the leaf of a Merkle tree.

A P2TR address consists of a public key that is derived through an additive key derivation scheme. This process involves hashing the internal public key and the Merkle tree root (representing alternative spending scripts) to derive an "additive tweak." The tweak is then added to both the secret and public keys. To spend using the key path, a transaction must include a signature generated with the tweaked secret key, which corresponds to the tweaked public key embedded in the address.

Motivation

Currently, on the Internet Computer, two types of restricted P2TR addresses can be created:

• P2TR with an untweaked public key: This type of address does not include a Merkle tree of alternative scripts, meaning it can only be spent via the key path. The creation of such addresses is supported since, for key-path spends, the transaction only requires a valid signature, and the Merkle root is intentionally omitted to conceal whether alternative spending scripts exist.
• P2TR address with a public key in a Merkle tree leaf: This type of address can only be spent via the script path because canisters currently cannot request the Internet Computer (IC) to sign transactions with a tweaked public key.

This limitation restricts canisters from creating P2TR addresses that support spending using both the key path and script paths. As a result, canisters must decide at the time of address creation how they intend to spend the funds in the future. While this does not seem to constitute an issue to integrate with most Bitcoin meta-protocols, it does reduce the overall flexibility for dapps that require dynamic spending options. Additionally, most libraries do not natively support creating Taproot addresses that can be spent using untweaked keys via the key path. This forces developers to have a deeper understanding of Taproot to integrate the Schnorr signing API in their dapps.

By adding support for key-tweaking in the Schnorr signing API, canisters will be able to create standard Taproot addresses that support both script path and key path spending with a tweaked internal key. This enhancement would make the IC more flexible and aligned with standard Taproot functionality, reducing complexity for developers and dapps.

[github-actions]

🤖 Here's your preview: https://ruw63-qaaaa-aaaam-abeca-cai.icp0.io

[Dfinity-Bjoern]

Please merge coordinated with release in replica