ROAST: Robust Asynchronous Schnorr Threshold Signatures
Tim Ruffing¹
@real_or_random
²Friedrich-Alexander-Universität
Erlangen-Nürnberg
Elliott Jin¹
@robot__dreams
Jonas Schneider-Bensch³
@jonschben
Viktoria Ronge²
Dominique Schröder²
@doschroeder
³CISPA Helmholtz Center
for Information Security
¹Blockstream
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
?
- No need to abort this session.
- Pending signer should be excluded from further sessions.\(\phantom{t}\)
- We need to start a further session to ensure progress.
Towards a Better Solution
?
- No need to abort this session.
- Pending signer should be excluded from further sessions.\(\phantom{t}\)
- We need to start a further session to ensure progress.
- If we had piggybacked a fresh nonce on every signature share, we could start a new session immediately.
ROAST
Observations
- No need to abort this session.
- Pending signer should be excluded from further sessions.\(\phantom{t}\)
- We need to start a further session to ensure progress.
- If we had piggybacked a fresh presignature share on every signature share, we could start a new session immediately.
ROAST
- Always keep sessions open.
- Maintain a set of "pending" signer
(= not responding). - Whenever there are \(t\) signers that are not pending, put them in a session.
- 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.
ROAST: Robust Asynchronous Schnorr Threshold Signatures (TABConf 2022)
By real-or-random
