Taproot and
Schnorr Multisignatures
Tim Ruffing
@real_or_random
UTXOs in Bitcoin
OP_DUP OP_HASH160 <Public KeyHash> OP_EQUAL OP_CHECKSIG
- Spending condition encoded as a script.
- Typically: you need to provide a signature of the desired transaction under a given public key
- current: public key inside a script
- Taproot: script inside a public key
Elliptic Curve Public Keys
can serve as Commitments
\textit{pk} = g^{x+H(g^x,\ \textit{data})}
\textit{sk} = x+H(g^x,\ \textit{data})
Taproot
\textit{pk} = g^{x+H(g^x,\ \textit{script})}
Key-path spending
- produce Schnorr signature valid under public key \(pk\)
Script-path spending
- reveal \(g^x\) and \(\textit{script}\)
- fulfill script
- script can actually be a Merkle tree of scripts
Smart Contracts
\textit{sk} = x_1 + x_2 +H(g^{x_1+x_2},\ \textit{script})
x_1
x_2
Parties can cooperate to produce a multi-signature,
i.e., a single Schnorr signature valid under \(g^{x_1+x_2}\)
Taproot is Cool
- All UTXOs look the same: just a public key
- All UTXOs are short: 32 bytes
- Most spends look the same: just a signature
- Most spends are short: 64 bytes
- Only exception:
Uncooperative parties in a smart contract
Applications
Schnorr Signature Verification
Multisignatures
Threshold Sigs
Blind Signatures
...
Consensus
Contracts
- Contracts are hidden from verifiers
- Consensus layer is kept simple
Taproot BIPs
- BIP340: Schnorr Signatures for secp256k1
- BIP341: Taproot: SegWit version 1 spending rules
- BIP342: Validation of Taproot Scripts
Research Agenda
- Multi-signatures...
- Threshold signatures...
- Blind signatures...
- ? signatures...
...that look like ordinary Schnorr signatures.
Schnorr Multisignatures
Schnorr Signatures
\( \textsf{Sign}(\textit{sk} = x, \textit{pk} = g^x, m) \)
\( r \leftarrow \$ ; R = g^r \)
\( c = H(\textit{pk}, R, m) \)
\( s = x\cdot c + r \)
\( \text{return}\ (R, s) \)
\( \textsf{Verify}(\textit{pk} = X, (R, s), m) \)
\(\phantom{r \leftarrow \$; R = g^r }\)
\( c = H(\textit{pk}, R, m) \)
\(\text{return}\ g^s == X^c \cdot R \)
\(\textit{sk}=x\)
\(\textit{pk}=g^x\)
Deterministic Randomness
\( \textsf{Sign}(\textit{sk} = x, \textit{pk} = g^x, m) \)
\( r = H_{non}(x, \textit{pk}, m, \text{rand}) ; R = g^r \)
\( c = H(\textit{pk}, R, m) \)
\( s = x\cdot c + r \)
\( \text{return}\ (R, s) \)
\(s = c \cdot x + r\)
\(s' = c' \cdot x + r\)
\(s-s'= x(c-c')\)
\(x= (s-s')/(c-c')\)
Naive Multisignatures (Insecure!)
\begin{matrix}
x\!\!\!\! &=\!\!\!\! &x_1\!\!\!\! &+\!\!\!\! &x_2\!\!\!\! &+\!\!\!\! &\dotsc\!\!\!\! &+\!\!\!\! &x_n\\[1ex]
r\!\!\!\! &=\!\!\!\! &r_1\!\!\!\! &+\!\!\!\! &r_2\!\!\!\! &+\!\!\!\! &\dotsc\!\!\!\! &+\!\!\!\! &r_n
\end{matrix}
\dotsm
\(X_1=g^{x_1}\)
\(R_1 = g^{r_1}\)
\(X_2=g^{x_2}\)
\(R_2 = g^{r_2}\)
\(X_3=g^{x_3}\)
\(R_3 = g^{r_3}\)
\dotsm
Naive Multisignatures (Insecure!)
\( \textsf{BrokenMultiSign}(\textit{sk}_i = x_i, \textit{pk} = g^x, m) \)
\( r_i \leftarrow \$; R_i = g^{r_i} \)
\( \text{broadcast} R_i ; R = \prod R_i\)
\( c = H(\textit{pk}, R, m) \)
\( \text{broadcast} s_i = x_i\cdot c + r_i; s = \sum s_i\)
\( \text{return}\ (R, s) \)
\( \textsf{Sign}(\textit{sk} = x, \textit{pk} = g^x, m) \)
\( r \leftarrow \$; R = g^r \)
\( c = H(\textit{pk}, R, m) \)
\( s = x\cdot c + r \)
\( \text{return}\ (R, s) \)
Issue 1: Rogue-Key Attack
\begin{aligned}
pk_1 &= g^{x_1}\\
pk_2 &= g^{x_2}\\
\phantom{\color{#e06666}pk_3} &\phantom{\color{#e06666}= g^{x_3}/(pk_1\cdot pk_2)}
\end{aligned}
pk = \prod pk_i = g^{x_1+x_2+(x_3-x_1-x_2)} = g^{x_3}
\begin{aligned}
pk_1 &= g^{x_1}\\
pk_2 &= g^{x_2}\\
&\phantom{pk_3 = g^{x_3}/(pk_1\cdot pk_2)}
\end{aligned}
\begin{aligned}
\phantom{pk_1} &\phantom{= g^{x_1}}\\
\phantom{pk_2} &\phantom{= g^{x_2}}\\
\color{#e06666}pk_3 &\color{#e06666}= g^{x_3}/(pk_1\cdot pk_2)
\end{aligned}
Avoiding Rogue-Key Attacks
MSDL-pop
[Boneh, Drijvers, Neven (2018)]:
proofs of possesion ("pop")
MuSig
[Maxwell, Poelstra, Seurin, Wuille (2018)]
key-aggregation with tweak
MuSig Key Aggregation
pk = \prod pk_i^{a_i} = g^{a_1x_1+a_2x_2+a_3x_3}
where
a_i = H_\textit{agg}(i, pk_1, pk_2, pk_3)
Issue 2: Parallel Security
Can we run multiple signing sessions in parallel?
Wagner's Algorithm
Find \(m_0,m_1\):
\(H(m_0) = H(m_1)\)
Find \(m_0,m_1,\dotsc,m_{100}\):
\(H(m_0) = H(m_1) + \dotsc + H(m_{100}) \)
Hard
Easy
Attack Using Wagner's Algorithm
- Let \(pk=g^{x+x'}\) with \(x\) belonging to victim and \(x'\) to attacker.
- Open 100 sessions with victim with messages \(m_1, \dotsc, m_{100}\).
- Victim sends nonces \(R_1, \dotsc, R_{100}\).
- Set \(R= R_1 \cdot \dotsc \cdot R_{100} \).
- Find reply nonces \(R'_1, \dotsc, R'_{100}\) using Wagner's Algorithm:
\(H(pk,R,m) = H(pk, R_1 \cdot R'_1, m_1) + \dotsc + H(pk, R_{100} \cdot R'_{100}, m_{100}) \) - Obtain partial signatures \(s_1, \dotsc, s_{100}\).
- \(s = s_1 + \dotsc + s_{100}\) is a partial signature on \(m\) with nonce \(R\).
- \((R, s + x'\cdot H(pk,R,m))\) is a forgery on \(m\).
Parallel Security
- Attacker controls hash value (because it controls its nonce \(R'\))
- Reduction must know \(R = \prod R_i\) before the attacker.
- Required for programming the random oracle on \(H(pk, R, m)\)
- Required for simulating signatures
Let every signer \(i\) send a commitment \(H(R_i)\) upfront.
Resulting protocol needs 3 rounds.
MuSig
\( \textsf{MuSigSign}(\textit{sk}_i = x_i, \textit{pk}=\prod \textit{pk}_i^{a_i}, m) \)
\( r_i \leftarrow \$; R_i = g^{r_i};\)
\( \text{broadcast} h_i = H(R_i)\)
\( \text{broadcast} R_i; R = \prod R_i\)
\(\text{fail if } H(R_i) \ne h_i \text{ for some } i \)
\( c = H(\textit{pk}, R, m) \)
\( \text{broadcast} s_i = x_i a_i c + r_i; s = \sum s_i\)
\( \text{return}\ (R, s) \)
\( \textsf{Sign}(\textit{sk} = x, \textit{pk} = g^x, m) \)
\( r \leftarrow \$; R = g^r \)
\( c = H(\textit{pk}, R, m) \)
\( s = x\cdot c + r \)
\( \text{return}\ (R, s) \)
Extensions to MuSig
MuSig-DN
- Schnorr/ECDSA signature generation needs randomness ("nonce")
- Lesson from history: True randomness is broken, leads to catastrophic failures
- Best practice: Use pseudorandom generator (seeded by secret key)
- If you apply this to multi-signatures: catastrophic failure
- MuSig-DN fixes this using (expensive?) zero-knowledge proofs
- On the way, we get a 2-round signing protocol (instead of 3 rounds)
- (Paper accepted at CCS conference this year)
- Joint work with Jonas Nick, Yannick Seurin, Pieter Wuille
Disclaimer
The following is work in progress.
(Simple) 2-round MuSig
- MuSig story:
- First revision of MuSig paper had a 2-round scheme
- Security proven under OMDL assumption
-
Drijvers, Edalatnejad, Ford, Kiltz, Loss, Neven, Stepanovs (2019): The proof is broken, here is an attack
- Reverted paper to 3-round variant
- Now we have a new (very simple) idea for 2-round scheme
- Hopefully will enable also "nested MuSig"
- Joint work with Jonas Nick, Yannick Seurin, Duc Le
Threshold MuSig
- Multisignatures: n-of-n, Threshold signatures: t-of-n
- When we started to write the Schnorr signature BIP,
we believed that Threshold Schnorr signatures are solved - Many papers in the literature using secret sharing
- Restrictions of those existing solutions
- honest majority assumption (e.g., can't do 7-of-10)
- assume broadcast channel (broken otherwise)
- parallel security?
- Future work. We believe this becomes easier with 2-round MuSig.
- Watch my talk at CES Summit 2019 for more background.
Don’t Trust. Verify.
Taproot and Schnorr Multisignatures
By real-or-random
Taproot and Schnorr Multisignatures
London Bitcoin Devs 0.24, 2020-06-17
