State: draft Created: 2021-2-17
This RFC specifies the cryptographic primitives used to transfer secrets through transactions with adaptor signatures and specifies the cryptographic setup required at the beginning of a swap to guarantee funds safety and recovery. Key, signature and proof formats are dependent on the blockchain and the type of cryptography used, see 08. Transactions for more examples with Bitcoin.
We describe the cryptographic keys needed by both swap roles defined in 01. High Level Overview.
A private_key type and a public_key type is defined for the arbitrating blockchain for each cryptographic approach and for the accordant blockchain.
For each public key described in the following section, we assume knowledge of the corresponding private key.
Arbitrating example: For Bitcoin ECDSA the public_key is an ECDSA secp256k1 public key. For Bitcoin Schnorr the public_key is a Schnorr secp256k1 public key.
Accordant example: for Monero the public_key is an ed25519 public key.
Keys generated by Alice role at the beginning of the swap phase:
Ab: arbitrating buy public_key;
Ac: arbitrating cancel public_key;
Ar: arbitrating refund public_key;
Ap: arbitrating punish public_key;
Ta: arbitrating adaptor public_key;
K_s^a: accordant spend public_key;
K_v^a: accordant view public_key;
where
Ta = K_s^a projection over the arbitrating group
Keys generated by Bob role at the beginning of the swap phase:
Bf: arbitrating fund public_key;
Bb: arbitrating buy public_key;
Bc: arbitrating cancel public_key;
Br: arbitrating refund public_key;
Tb: arbitrating adaptor public_key;
K_s^b: accordant spend public_key;
K_v^b: accordant view public_key;
where
Tb = K_s^b projection over the arbitrating group
We define a signature type for the arbitrating blockchain role related to the private_key/public_key types defined previously.
Arbitrating example: for Bitcoin ECDSA the signature is an ECDSA signature, and for Bitcoin Schnorr, the signature is a Schnorr signature following [2] BIP 0340: Schnorr Signatures for secp256k1.
The interface for interacting with arbitrating signatures is composed of three functions:
-
Gen: A key generation algorithm, this function must follow the rules of the chosenprivate_keytype. -
Sign: An algorithm that signs a given message as defined in the chosen signing primitive, e.g. ECDSA, Schnorr, etc. -
Vrfy: Verify a signature based on public parameters. If validation passes, the signature is a valid signature.
We define an adaptor_signature type for the arbitrating blockchain related to the private_key/public_key types defined previously.
An adaptor signature scheme extends a standard signature (Gen, Sign, Vrfy) scheme with:
-
EncGen: An encryption key generation algorithm, in this protocol the encryption key generation is linked to the cross-group DLEQ proof. -
EncSig: Encrypt a signature and return an adaptor signature. This RFC uses the public key tweaking method, see [3] Adaptor signature -Schnorr signature and ECDSA- section 3. Adaptor Signatures for examples. -
EncVrfy: Verify an adaptor signature based on public parameters, if validation passes the decrypted adaptor signature is a valid signature. -
DecSig: Decrypt an adaptor signature by injecting the encryption key. -
RecKey: Recover the key material needed for extracting the encryption key withRec. -
Rec: Recover the encryption key based on the adaptor signature and the decrypted signature.
We describe an adaptor signature interface and two instantiations, one for ECDSA inside Bitcoin scripts and one for Schnorr inside Taproot scripts.
EncSig:
pi = PDLEQ( (G, R'), (T, R), k )
s' = k^-1 ⋅ ( hash(m) + f(R)d )
return (R, R', s', pi)
where
f(): x-coordinate mod q
P = dG
R = kT
R' = kG
PDLEQ produces a zero-knowledge proof of knowledge of the same relation k between two pairs of elements in the same group, i.e. (G, R') and (T, R).
The adaptor_signature type is define as (R, R', s', pi) for this instantiation.
EncVrfy:
VDLEQ( (G, R'), (T, R), pi ) =? 1
R' =? ( H(m)G ⋅ f(R)P )^{s'^-1}
where
f(): x-coordinate mod q
P = dG
R = kT
R' = kG
VDLEQ verifies a zero-knowledge proof of knowledge of the same unknown relation x between two pairs of elements in the same group.
DecSig:
s = s't^-1
= k^-1 ⋅ ( hash(m) + f(R)d ) ⋅ t^-1
return (f(R), s)
where
f(): x-coordinate mod q
P = dG
R = kT
R' = kG
RecKey:
Convenience function for making ECDSA and Schnorr APIs consistent.
return (T, s')
Rec:
t' = s^-1 ⋅ s'
┌ s' if s'G = T
t = ├ -s' if s'G = T^-1
└ NaN otherwise
Vrfy: as defined in [5] BIP 0143: Transaction Signature Verification for Version 0 Witness Program
This notation follows BIP 340, with some simplication on even y coordinate check for private keys:
EncSig:
s' = k + tagged_hash( bytes(R + T) || bytes(P) || m )d
The adaptor_signature type is defined as (R, s') for this instantiation.
EncVrfy:
s'G =? R + tagged_hash( bytes(R + T) || bytes(P) || m )P
where
P = dG
DecSig:
s = s' + t
= k + t + tagged_hash( bytes(R + T) || bytes(P) || m )d
where
P = dG
R = kG
T = tG
RecKey:
Convenience function for making ECDSA and Schnorr APIs consistent.
return s'
Rec:
t = s - s'
Vrfy: as defined in [2] BIP 0340: Schnorr Signatures for secp256k1
sG =? R + tagged_hash( bytes(R) || bytes(P) || m )P
We define a cross_group_proof type for the Arbitrating-Accordant blockchain pair dependent on the private_key groups. If the groups are the same, the proof is set to null.
A cross-group Discrete Logarithm proving system is defined with:
-
XDLGen: An algorithm that generates the parameters based on the given security level. -
XDLProve: An algorithm that produces a proof in zero-knowledge of a relationxfor the tuple(xG', xH')whereGandHare prime-order groups where the discrete logarithm problem is assumed to be hard andG' ∈ GandH' ∈ H, among other proof elements. -
XDLVrfy: Verify the proof for a given relation(xG', xH').
An example instantiation of this system is described in [4] Discrete logarithm equality across groups.