feat(crypto): Add support for Schnorr auxiliary inputs #344
Conversation
|
🤖 Here's your preview: https://qlapq-syaaa-aaaak-qcq2a-cai.icp0.io/docs |
|
LGTM! Left some small improvement suggestions. |
Co-authored-by: Oleksandr Tkachenko <108659113+altkdf@users.noreply.github.com>
|
Looks good to me, we will discuss in the interface spec meeting before marking it final. |
| type sign_with_schnorr_args = record { | ||
| message : blob; | ||
| derivation_path : vec blob; | ||
| key_id : record { algorithm : schnorr_algorithm; name : text }; | ||
| aux: opt schnorr_aux; |
There was a problem hiding this comment.
Is the name aux clear/descriptive enough?
There was a problem hiding this comment.
I'm open to alternatives
There was a problem hiding this comment.
From interface spec meeting: If we don't see any such field being used for EdDSA, and the typing anyway does not guarantee consistency, we could also just have the merkle_root_hash: opt blob here.
There was a problem hiding this comment.
Re aux the consideration here is in the future we wanted to support additional fields such as the context field of Ed25519ctx (see https://www.rfc-editor.org/rfc/rfc8032) this approach would make it easier to support since we could add a new member to the variant.
There was a problem hiding this comment.
Maybe write it out as auxiliary_parameters so that it's a bit clearer (for people that do not spend their free time reading CS theory papers)?
Co-authored-by: mraszyk <31483726+mraszyk@users.noreply.github.com>
|
Superseded by dfinity/portal#3758 |
The PR proposes extending the
sign_with_schnorrfunction 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:
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:
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.