FROST

Imagine an association whose savings are managed by Anna, Jan and Eva. They choose a 2-of-3 rule: Anna and Jan, Anna and Eva, or Jan and Eva can approve a payment. Each holds a different secret share, a cryptographically constructed piece of the shared key material. One share is insufficient, but these are not three copies of the same password either. If Eva is unavailable, the other pair can cooperate. The same boundary applies to an attacker: obtaining enough shares also makes signing possible. Distribution therefore helps only when compromising one device or account does not open the way to all the others. [1] [2]

Anna should not confirm an operation merely because an app says a signature is waiting. She needs to know the recipient, the amount, the fee and whether any change returns to the association. Every signer needs a trusted way to verify the actual transaction. A hash, a short cryptographic fingerprint of data, does not explain its contents to a person. FROST enables cooperation on the same message; it cannot judge whether an invoice is genuine or someone understood what they were approving. Even a completed signature is not a payment confirmation in a block. A block is a group of transactions recorded in the Bitcoin network’s shared history. RFC 9591 is an informational protocol specification, not a security certificate for an entire application. [1] [2]

Taproot is a Bitcoin upgrade that allows funds to be spent either with a signature for the relevant key or by meeting predetermined conditions. A suitably constructed threshold signature used for a Taproot key-path spend can look like an ordinary signature made with one key. The signature alone does not reveal the internal share count or threshold. That helps with privacy and the size of signature data, but does not make the whole transaction or communication between participants anonymous. Bitcoin requires the exact rules of BIP 340; generic FROST on the secp256k1 curve, the mathematical basis for calculations with Bitcoin keys, is insufficient. Zcash Foundation (ZF) therefore offers frost-secp256k1-tr specifically for Taproot. The key tweaks used by Taproot must also be handled correctly. A matching curve name does not prove compatibility, and a library being available does not mean every wallet supports it. [3] [4]

Before the association can sign anything, it must create the shares securely. A trusted dealer can create the full key and split it. This introduces a sensitive moment: the dealer knows the complete key, and a retained copy would bypass the intended joint approval. The alternative is DKG, distributed key generation, in which the whole secret key need not appear at any single participant. It requires authenticated, protected communication and correct protocol execution. Simply emailing a few files is insufficient. RFC 9591 focuses on signing; it does not automatically promise DKG in every product. A long-term key share is also different from a signature share for one particular payment. [1] [2]

Signing itself takes two rounds, excluding earlier key generation. First, each selected participant creates two secret one-time values called nonces and sends their public commitments, values that cryptographically bind them to those nonces. They then receive the common message and commitment list, verify the inputs and calculate their signature share. The coordinator combines these shares. Binding factors tie the calculations to the specific message, group public key and commitments. With a 2-of-3 rule, a session can start with two participants. If all three are selected for that session, however, all must contribute; the one who falls silent cannot simply be omitted. [1] [3]

A nonce here is a secret value for a single signing attempt, not a password to use repeatedly. Reusing it can expose secret key material. If Jan’s computer crashes after sending a signature share, restoring old state must not mark already used nonces as fresh. An unfinished payment does not justify reusing them either. A secure implementation needs good randomness, separation of concurrent attempts and reliable disposal of consumed values. This is one reason not to assemble FROST yourself from arbitrary scripts. Correct mathematics alone cannot protect mishandled secret data. [1]

The coordinator arranges messages, but that role alone does not let it sign for the association. It needs contributions from the selected share holders. It can nevertheless withhold communication or abort a session, just as a participant’s invalid contribution can derail it. Checks can detect an invalid signature share; attributing the fault to a particular person requires trustworthy knowledge of message origins. Detecting a problem does not guarantee completion. A new attempt needs an available authorized group and fresh nonces. The association therefore needs a plan for outages and disagreements, not just a threshold displayed on the welcome screen. [1] [2]

If Eva loses her device, the FROST label alone will not recover her funds. A backup must preserve her share, identifier, necessary group information and a way to load them into compatible software. It is not automatically an ordinary Seed Phrase, a wallet’s word-based backup. Recovering a share with help from others and refreshing shares are additional procedures that the particular system must support. A copy of Eva’s share remains the same share; it adds no independent voter. Refreshing under the same group key also does not neutralize a sufficient set of previously stolen shares. Before using real savings, a trial therefore needs to cover recovery, outages and the exact software version, not just one successful signature. [2] [3]