Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Taproot support #606

Open
gregdhill opened this issue May 18, 2022 · 0 comments · May be fixed by #607
Open

Taproot support #606

gregdhill opened this issue May 18, 2022 · 0 comments · May be fixed by #607

Comments

@gregdhill
Copy link
Member

gregdhill commented May 18, 2022

General ticket for discussions related to taproot support on the interBTC parachain.

Overview

As far as I can tell there are no breaking changes that would impact the continued operation of Kintsugi and Interlay. However, I welcome input on ways to utilize the new cryptography - e.g. can Vaults make use of Schnorr signatures for payments?

Addresses

The primary new address format (introduced in BIP 341) is the P2TR (pay-to-taproot) construction.

The output has the following format:

scriptPubKey: OP_1 <32 bytes>

This is interpreted as witness version 1 due to OP_1 and the 32 byte push is the (tweaked) public key Q (P is the untweaked public key).

The spending rules are slightly more complicated...

Key Path

scriptSig: -
witnessStack: sig(Q)

The witness stack contains one entry, the Schnorr signature (BIP 340) for public key Q over the "common signature message".

-> Verify(pk, m, sig)

Script Path

scriptSig: -
witnessStack: [args ...] S P

The witness stack contains multiple entries, but the penultimate entry is always the script S followed by the public key P (which is always the last entry).

-> Q = tweak(P, S) = P + hash(P || S) * G

Notes

To support P2TR addresses we need to add a new variant to the BtcAddress enum. Calculating the "address" from a transaction output is relatively easy, assuming we simply extract Q as defined above. However, calculating the corresponding "address" from the subsequent spending transaction input alone, at least for key path spending, is simply not possible as the Schnorr construction does not support public key recovery. The only way to do this is to also provide the output that is spent and verify Q.

@gregdhill gregdhill linked a pull request May 18, 2022 that will close this issue
@nud3l nud3l added this to Backlog Jan 3, 2023
@nud3l nud3l moved this to Todo ⏳ in Backlog Jan 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

Successfully merging a pull request may close this issue.

1 participant