Bitcoin Supports
Schnorr Signatures

Schnorr signature verification

threshold signatures

multi-sigs

blind signatures

...

on-chain

off-chain

Schnorr Signatures in Bitcoin

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

Unforgeability

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

Robustness

\(t\) honest signers
can reliably produce
a valid signature
(even if other \(n-t\) signers are malicious).

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

Applications of
Threshold Signatures

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

FROST: Native Schnorr
Threshold Signatures

\(\textsf{SchnorrVerify}(\widetilde{pk},\sigma, m)\)

ordinary Schnorr public key
obtained via interactive
Distributed Key Generation (DKG)

ordinary Schnorr signature
obtained via interactive signing protocol involving at least \(t\) honest signers

Existing Work: FROST

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

  • Produces ordinary Schnorr signatures

  • Unforgeable under concurrent signing sessions,
    (assuming a suitable DKG protocol)
  • No restrictions on \(t\) with respect to \(n\)

Problem: FROST does not provide Robustness.

FROST

  • Unforgeable under concurrent signing sessions
  • "Semi-interactive" signing
    • Presignature round
      • can be performed without knowing
        message or exact subset of \(t\) signers
    • Signature round
  • Problem: FROST  does not provide Robustness

Contribution: ROAST

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

Contribution: ROAST

ROAST is a wrapper around FROST,
a threshold Schnorr signature protocol.

ROAST turns FROST into a robust protocol.

Setting the Stage

Coordinator

Coordinator not trusted
for unforgeability

Signer

Signer

Signer

Signer

Setting the Stage

Conventions

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

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!
  • Attacker cannot force honest signers into a timeout.

FROST Session

FROST Session

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

2-of-4 example

FROST Session

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

2-of-4 example

FROST Session

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

2-of-4 example

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

2-of-4 example

Problem: 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

?

2-of-4 example

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

Goal: Robustness

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

FROST has Identifiable Aborts

  • Informal definition
    • If all received messages are valid, the protocol will terminate.
    • Whenever the coordinator receives a protocol message, it can tell immediately whether the message is valid or not.
  • We give a formal game-based definition in the paper.
  • Consequences
    • Coordinator can (in theory) simply ignore invalid messages.
    • We can assume that all messages received are valid.
    • In other words: It suffices to consider crash faults.

Contribution: ROAST

ROAST is a wrapper around the signing protocol
of FROST, a threshold Schnorr signatures scheme.

ROAST turns FROST into a robust protocol.

Contribution: ROAST

  • Given a threshold signature scheme (e.g., FROST) that
    • has two rounds, the first of which can be preprocessed,
    • provides Identifiable Aborts, and
    • is unforgeable under concurrent signing sessions,
  • ROAST turns it into a threshold signing protocol that
    • is robust
    • in an asynchronous network.

ROAST

?

  1. Always keep sessions open.
  2. Piggyback a fresh nonce on every signature share.
  3. Maintain a set of signers ready
    to be selected for the second round.
  4. Whenever there are \(t\) ready signers, select them.

1

1

ROAST

?

  1. Always keep sessions open.
  2. Piggyback a fresh nonce on every signature share.
  3. Whenever there are \(t\) fresh nonces signers, select them.

1

1

ROAST

  1. Always keep sessions open.
  2. Piggyback a fresh nonce on every signature share.
  3. Whenever there are \(t\) fresh nonces, select them.

1

1

2

2

?

ROAST

?

  1. Always keep sessions open.
  2. Piggyback a fresh nonce on every signature share.
  3. Maintain a set of signers ready
    to be selected for the second round.
  4. Whenever there are \(t\) ready signers, select them.

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.

Robustness

Theorem (Robustness, informal)

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

Proof idea.

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

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

Round Complexity

ROAST terminates after
 \(2(n −t) + 3 = O(n-t)\)
asynchronous rounds.

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

  • Python prototype
  • Round-trip time: 153 ms
  • 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
Central 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 in asynchronous networks
  • is very simple: all it does is start multiple FROST sessions

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

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

Don’t Trust. Verify.

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

FROST

  • Unforgeable under concurrent signing sessions
  • "Semi-interactive" signing
    • Nonce round
      • can be performed without knowing
        message or exact subset of \(t\) signers
    • Signature round

Contribution: ROAST

  • Given a threshold signature scheme (e.g., FROST)  that
    • is semi-interactive,
    • provides Identifiable Aborts, and
    • is unforgeable under concurrent signing sessions,
  • ROAST turns it into a threshold signing protocol that
    • is robust
    • in asynchronous networks.

FROST has Identifiable Aborts

  • Informal definition
    • If all received messages are valid, the protocol will terminate.
    • Whenever the coordinator receives a protocol message, it can tell  immediately whether the message is valid or not.
  • We give a formal game-based definition in the paper.
  • Consequences
    • Coordinator can (in theory) simply ignore invalid messages.
    • We can assume that all messages received are valid.
    • In other words: It suffices to consider crash faults.

ROAST

Signers

  • upon init:
    • send presignature share
  • upon receive presignature:
    • send signature share for presignature

ROAST

  • Given a threshold signature scheme that
    • is semi-interactive,
    • provides Identifiable Aborts, and
    • is unforgeable under concurrent signing sessions,
  • ROAST turns it into a threshold signing protocol that
    • is robust
    • in asynchronous networks.

Running Time

Fraction  \(f/(n-t)\) of faulty signers

Runnung time [s]

Running Time

Fraction  \(f/(n-t)\) of faulty signers

Runnung time [s]

"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

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.

ROAST: Robust Asynchronous Schnorr Threshold Signatures (CCS 2022)

By real-or-random

ROAST: Robust Asynchronous Schnorr Threshold Signatures (CCS 2022)

CCS 2022, Los Angeles

  • 481

More from real-or-random

  • Copy of ROAST: Robust Asynchronous Schnorr Threshold Signatures (Chaincode Labs)
    real-or-random
    301
  • ROAST: Robust Asynchronous Schnorr Threshold Signatures (Chaincode Labs)
    real-or-random
    442
  • ROAST: Robust Asynchronous Schnorr Threshold Signatures (TABConf 2022)
    real-or-random
    1117