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

 

see https://github.com/bitcoin/bips

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.