Turning the page.
Bringing the next chapter into view…
Psst… make reading your own.
Fonts + themes live in Appearance. Your eyes get a vote.
Bringing the next chapter into view…
A signature produced cooperatively by a threshold of participants holding shares of a signing key, without requiring any participant to reconstruct the complete private key.
Checking this browser’s read-aloud support…
Komlo and Goldberg study the communication cost of threshold Schnorr signing. Participants each possess a share of a common signing key, so generating a signature involves coordination that ordinary single-party signing does not. FROST reduces signing interaction to two rounds and addresses forgery risks that arise when concurrent signing sessions are combined incorrectly. Read the construction as a protocol among potentially untrustworthy participants, not simply an arithmetic trick for dividing a password.
The research question is narrower than whether an institution has safe custody. The paper's result concerns the signing scheme under its adversary model. It does not decide who should hold shares, how they verify a payment request, or how a company replaces an employee. Those operational choices determine whether the mathematical threshold corresponds to independent authorization in practice.
RFC 9591 specifies FROST signing and ciphersuites, with participant commitments followed by signature shares and aggregation. It includes nonce-generation and nonce-reuse warnings: secret signing material must not be recycled across incompatible sessions. The document's security assumption limits how many participants the adversary can corrupt. It also distinguishes signing from the broader problem of establishing participants' secret shares.
The June 2024 RFC is an IRTF Informational publication, not an Internet Standards Track specification. That status is useful context, not a dismissal of the protocol. For an implementation review, trace how the message, participant list, commitments and session are bound together. Confirm what happens when a participant aborts or supplies a bad share. A protocol can prevent forgery while an unavailable participant still prevents a particular signing attempt from completing.
Suppose a fictional organization requires three of five signers for a treasury transaction. Losing one signer leaves four, enough to authorize a payment. Compromising two shares alone should not satisfy the intended threshold, provided the scheme and its assumptions hold. But five laptops controlled by one administrator are not five independent decision makers. A shared recovery account or identical malware infection can undermine the organizational separation without breaking any cryptographic theorem.
For a tabletop exercise, assign each signer an independent task: validate the destination, inspect the transaction's meaning, and check the spending policy. Then remove two participants and test the recovery plan. Record whether recovery changes the threshold or introduces a master key. These questions expose the difference between distributed key material and distributed authority, and they can be answered before moving any real assets.
BIP-340 specifies a particular Schnorr signature format and verification procedure for Bitcoin, including encoding and tagged hashing. Sharing the word Schnorr does not establish that every threshold implementation emits a signature valid under BIP-340. The group, challenge computation, nonce treatment and serialization must line up with the target verifier. This is why a protocol name is insufficient evidence of wallet compatibility.
A useful comparison with on-chain multisignature starts at the verifier. Does the chain see several distinct signatures and an explicit policy, or one signature under a shared public key? Then ask what audit trail remains off-chain, how signers authenticate each other, and how backups work. Threshold signing can reduce what is revealed on-chain, but it also moves some evidence about approval into the signing system's logs and procedures.