UTXOs in Bitcoin

• 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

Taproot

Smart Contracts

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

Consensus

Contracts

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...

Schnorr Multisignatures

Schnorr Signatures

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)$

Naive Multisignatures (Insecure!)

Naive Multisignatures (Insecure!)

$\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

Avoiding Rogue-Key Attacks

MuSig Key Aggregation

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)$

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

MuSig

$\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.