You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
This is interpreted as witness version 1 due to
OP_1
and the 32 byte push is the (tweaked) public keyQ
(P
is the untweaked public key).The spending rules are slightly more complicated...
Key Path
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
The witness stack contains multiple entries, but the penultimate entry is always the script
S
followed by the public keyP
(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 extractQ
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 verifyQ
.The text was updated successfully, but these errors were encountered: