Schnorr Signatures in Bitcoin

  • Bitcoin supports Schnorr signatures
  • BIP 340 (Wuille, Nick, Ruffing) has been activated as
    part of Taproot softfork (Nov 2021)
  • Reasons to prefer Schnorr signatures over ECDSA:
    • Provable security (theory)
    • Efficiency
    • Easier constructions of advanced signing protocols

Vision

Schnorr signature verification

threshold signatures

multi-sigs

blind signatures

...

on-chain

off-chain

  • On-chain consensus layer is kept simple
  • Off-chain protocols are hidden from verifiers
  • Efficiency and compactness

Threshold Signatures ("Multisig")

Unforgeability

\(t-1\) malicious signers
cannot produce
a valid signature.

Robustness

\(t\) honest signers
can reliably produce
a valid signature.

(Anti-DoS)

\(t\)-of-\(n\)

Why Threshold Signatures?

  • 2-of-3: secure personal wallet
  • 3-of-6: Bitfinex cold wallet
  • 11-of-15: Liquid watchmen
  • ...

"Multisig" in Bitcoin

  • requires \(n\) pubkeys and \(t\) signatures
  • valid "threshold" signature is just \(t\) signatures
OP_CHECKSIGADD

OP_CHECKSIGADD

  • very simple
  • non-interactive key gen
  • non-interactive signing
  • accountable
  • \(n\) public keys
  • \(t\) signatures
  • \(t\) and \(n\) limited
  • distinguishable on chain

Threshold signatures should look like ordinary Schnorr signatures!

Native Threshold Signatures

FROST

  • "FROST: Flexible Round-Optimized Schnorr Threshold Signatures" (Komlo and Goldberg 2020)

  • Unforgeable under concurrent signing sessions
    (assuming a suitable key generation protocol)

Problem:
FROST does not provide Robustness.

Setup

Coordinator

Not trusted for unforgeability

Relied upon for robustness

Signer

Signer

Signer

Signer

Goal: Robustness (Anti-DoS)

  • Consider a run of the signing protocol with all \(n\) signers.
  • Signers are assumed to agree on a message to sign.
  • \(t\) signers are honest and willing to sign.
  • Remaining \(n-t\) signers are malicious and try to prevent honest signers from signing.
  • Signing protocol is robust if it is guaranteed to terminate with the coordinator outputting a valid signature.

Asynchronous Network

  • We know that network messages between honest signers and coordinator arrive "eventually".
  • But we don't assume any deadline in which messages arrive.
  • No timeouts allowed in the protocol!

?

Contribution: ROAST

ROAST is a wrapper around FROST that
turns it into a robust threshold signing protocol.

Setting the Stage

Conventions

  • 2-of-4 example
  • "We" are the coordinator.
  • All messages we receive
    are valid.
  • "Session" means
    "FROST session"

FROST Session

FROST Session

  • Signers send nonces \(\phantom{t}\)
  • Coordinator
    • waits for \(t\) nonces

FROST Session

  • Signers send nonces \(\phantom{t}\)
  • Coordinator
    • waits for \(t\) nonces
    • aggregates them into aggnonce
    • sends aggnonce back

FROST Session

  • Signers send nonces \(\phantom{t}\)
  • Coordinator
    • waits for \(t\) nonces
    • aggregates them into aggnonce
    • sends aggnonce back
  • Signers send signature shares

FROST Session

  • Signers send nonces \(\phantom{t}\)
  • Coordinator
    • waits for \(t\) nonces
    • aggregates them into aggnonce
    • sends aggnonce back
  • Signers send signature shares
  • Coordinator outputs signature

FROST is not Robust

  • Signers send nonces \(\phantom{t}\)
  • Coordinator
    • waits for \(t\) nonces
    • aggregates them into aggnonce
    • sends aggnonce back
  • Signers send signature shares

?

Trivial "Solution"

Run a session for every subset of size \(t\).

Trivial "Solution"

Trivial "Solution"

  • needs \(\binom{n}{t}\) FROST sessions
  • \(\binom{4}{2} = 6\)
  • \(\binom{15}{11} = 1365\)
  • \(\binom{100}{67}= 294692427022540894366527900\)

Towards a Better Solution

?

  1. No need to abort this session.
  2. Pending signer should be excluded from further sessions.\(\phantom{t}\)
  3. We need to start a further session to ensure progress.

Towards a Better Solution

?

  1. No need to abort this session.
  2. Pending signer should be excluded from further sessions.\(\phantom{t}\)
  3. We need to start a further session to ensure progress.
  4. If we had piggybacked a fresh nonce  on every signature share, we could start a new session immediately.

ROAST

Observations

  1. No need to abort this session.
  2. Pending signer should be excluded from further sessions.\(\phantom{t}\)
  3. We need to start a further session to ensure progress.
  4. If we had piggybacked a fresh presignature share on every signature share, we could start a new session immediately.

ROAST

  1. Always keep sessions open.
  2. Maintain a set of "pending" signer
    (= not responding).
  3. Whenever there are \(t\) signers that are not pending, put them in a session.
  4. Piggyback a fresh nonce on every signature share.

Example Execution

Example Execution

Example Execution

1

1

Example Execution

1

1

Example Execution

1

2

2

Example Execution

1

2

2

Example Execution

1

2

3

3

Key Invariant

1

2

3

3

Every signer is pending in at most one session.

Robustness

Theorem (Robustness, informal)

The coordinator outputs a valid signature after initiating at most \(n-t+1\) signing sessions of FROST.

Proof idea.

  • Every signer can hold up at most one session, so
    \(n-t\) disruptive signers can hold up at most \(n-t\) sessions.

  • \(t\) honest signers will respond eventually, so we can always start a new session and make progress.

Experimental Evaluation

  • Unoptimized Python prototype

    • Elliptic curve operations with fastecdsa library (GMP)

  • Network

    • Coordinator on a server in San Francisco
    • All signers on a single server in Frankfurt
    • Round-trip time: 153 ms

Experimental Evaluation

Simulated Attacker:

\(n-t\) malicious signers crash after nonce round

11-of-15 67-of-100
Uncoordinated Attack 0.6 s 0.7 s
Coordinated Attack 1 s 7 s

Getting Rid of the Coordinator

  • We know there are at most \(n-t\) malicious signers.
  • Take \(n-t+1\) signers and let them play the role of the coordinator in \(n-t+1\) ROAST runs.
  • One run will have an honest coordinator.

ROAST

ROAST turns FROST it into a threshold signing protocol that

  • is robust (anti-DoS) in asynchronous networks
  • is very simple: all it does is start multiple FROST sessions

This talk: https://slides.com/real-or-random/roast-tabconf22/

Paper: https://ia.cr/2022/550

Blog post: https://medium.com/blockstream/ddda55a07d1b

Prototype: https://github.com/robot-dreams/roast

Don’t Trust. Verify.