Why Threshold?

  • Tension between Security and Availability
  • Threshold cryptography can increase both!

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

"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

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

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!

?

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.

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 Session

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

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

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.

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

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

  • 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

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

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.

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]

Copy of ROAST: Robust Asynchronous Schnorr Threshold Signatures (Chaincode Labs)

By real-or-random

Copy of ROAST: Robust Asynchronous Schnorr Threshold Signatures (Chaincode Labs)

Chaincode Labs, 2022-11-15

  • 301

More from real-or-random

  • ROAST: Robust Asynchronous Schnorr Threshold Signatures (Chaincode Labs)
    real-or-random
    442
  • ROAST: Robust Asynchronous Schnorr Threshold Signatures (CCS 2022)
    real-or-random
    482
  • ROAST: Robust Asynchronous Schnorr Threshold Signatures (TABConf 2022)
    real-or-random
    1118