FROST - Revision history

NotATether: Add Ciphersuites and Status sections and expand from RFC 9591

2026-09-13T07:38:56Z

Add Ciphersuites and Status sections and expand from RFC 9591

← Older revision		Revision as of 07:38, 13 September 2026
Line 6:		Line 6:

	FROST, described by Chelsea Komlo and Ian Goldberg, binds each signer to a nonce commitment before the challenge is known, which addresses earlier forgery attacks on naive threshold Schnorr designs. Signing uses two rounds of commitments and signature shares. A coordinator may assemble shares into one signature. Nonce reuse across sessions can leak key material. Partial signature shares must be verified before they are combined. A coordinator that skips share verification can output an invalid aggregate signature and waste a signing round without learning the group secret.		FROST, described by Chelsea Komlo and Ian Goldberg, binds each signer to a nonce commitment before the challenge is known, which addresses earlier forgery attacks on naive threshold Schnorr designs. Signing uses two rounds of commitments and signature shares. A coordinator may assemble shares into one signature. Nonce reuse across sessions can leak key material. Partial signature shares must be verified before they are combined. A coordinator that skips share verification can output an invalid aggregate signature and waste a signing round without learning the group secret.

			RFC 9591 also describes identifiable abort for some failure cases so honest parties can recognize a misbehaving participant's share. Removing the coordinator role is possible when signers broadcast commitments among themselves, at higher communication cost.

	A Taproot-oriented ciphersuite is required for x-only keys and BIP340 hashing conventions. A FROST group key used as a [[Taproot]] internal key still needs the BIP341 tweak applied correctly at keygen or signing time. On-chain, a successful Taproot key-path spend does not reveal that FROST was used.		A Taproot-oriented ciphersuite is required for x-only keys and BIP340 hashing conventions. A FROST group key used as a [[Taproot]] internal key still needs the BIP341 tweak applied correctly at keygen or signing time. On-chain, a successful Taproot key-path spend does not reveal that FROST was used.
Line 13:		Line 15:
	Distributed key generation must produce verifiable shares before signing. Many deployments use a dealer or a multi-round DKG so that no single machine ever holds the full secret. A dishonest coordinator can bias which honest subset completes a signing session, but cannot forge a BIP340-valid signature without ''k'' valid shares. Implementations that target Bitcoin should document their ciphersuite and Taproot tweak handling explicitly.		Distributed key generation must produce verifiable shares before signing. Many deployments use a dealer or a multi-round DKG so that no single machine ever holds the full secret. A dishonest coordinator can bias which honest subset completes a signing session, but cannot forge a BIP340-valid signature without ''k'' valid shares. Implementations that target Bitcoin should document their ciphersuite and Taproot tweak handling explicitly.

	Threshold wallets must define what happens when signers go offline between DKG and spending. Refreshing shares (proactive security) is optional in RFC 9591 deployments and must be documented if used.		Threshold wallets must define what happens when signers go offline between DKG and spending. Refreshing shares (proactive security) is optional in RFC 9591 deployments and must be documented if used. Lost shares below the threshold stall signing until a refresh or a recovery path in the Taproot tree is available.

			== Ciphersuites and Bitcoin ==

			RFC 9591 defines several ciphersuites, including <code>FROST(secp256k1, SHA-256)</code>. Bitcoin wallets that want BIP340 verification must additionally follow x-only key encoding and the Taproot challenge hash as in BIP340 and BIP341. A ciphersuite that verifies on Ed25519 or P-256 is not interchangeable with on-chain Bitcoin verification even when the FROST round structure is the same.

			Because the published signature is an ordinary Schnorr signature, explorers and nodes do not learn ''k'' or ''n''. Operational security still depends on share storage, the honesty threshold, and whether a script-path backup exists when too many sharers disappear.

			== Status ==

			FROST is deployed in threshold-custody and multiparty wallet stacks outside Bitcoin Core consensus. There is no single Bitcoin BIP that mandates one FROST ciphersuite. Integrators should treat RFC 9591 plus their BIP340/BIP341 mapping as the specification surface and publish test vectors for their exact tweak and encoding choices.

			Compared with MuSig2, FROST fits custody settings where not every key holder can be online for every spend. Compared with on-chain multisig Script, it hides the threshold policy on key-path spends and produces a smaller witness.

	== See also ==		== See also ==
Line 20:		Line 33:
	* [[Taproot]]		* [[Taproot]]
	* [[Multi-signature]]		* [[Multi-signature]]
			* [[Descriptor wallet]]
			* [[PSBT]]

	== External links ==		== External links ==
Line 26:		Line 41:
	* [https://frost.zfnd.org/ ZF FROST documentation]		* [https://frost.zfnd.org/ ZF FROST documentation]
	* [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340: Schnorr signatures for secp256k1]		* [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340: Schnorr signatures for secp256k1]
			* [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341: Taproot]

	[[Category:Technical]]		[[Category:Technical]]

NotATether: Expand Signing section on share verification

2026-09-13T07:35:48Z

Expand Signing section on share verification

← Older revision		Revision as of 07:35, 13 September 2026
Line 5:		Line 5:
	== Signing ==		== Signing ==

	FROST, described by Chelsea Komlo and Ian Goldberg, binds each signer to a nonce commitment before the challenge is known, which addresses earlier forgery attacks on naive threshold Schnorr designs. Signing uses two rounds of commitments and signature shares. A coordinator may assemble shares into one signature. Nonce reuse across sessions can leak key material.		FROST, described by Chelsea Komlo and Ian Goldberg, binds each signer to a nonce commitment before the challenge is known, which addresses earlier forgery attacks on naive threshold Schnorr designs. Signing uses two rounds of commitments and signature shares. A coordinator may assemble shares into one signature. Nonce reuse across sessions can leak key material. Partial signature shares must be verified before they are combined. A coordinator that skips share verification can output an invalid aggregate signature and waste a signing round without learning the group secret.

	A Taproot-oriented ciphersuite is required for x-only keys and BIP340 hashing conventions. A FROST group key used as a [[Taproot]] internal key still needs the BIP341 tweak applied correctly at keygen or signing time. On-chain, a successful Taproot key-path spend does not reveal that FROST was used.		A Taproot-oriented ciphersuite is required for x-only keys and BIP340 hashing conventions. A FROST group key used as a [[Taproot]] internal key still needs the BIP341 tweak applied correctly at keygen or signing time. On-chain, a successful Taproot key-path spend does not reveal that FROST was used.

NotATether: Add Signing and Key generation sections

2026-09-13T07:32:57Z

Add Signing and Key generation sections

← Older revision		Revision as of 07:32, 13 September 2026
Line 2:		Line 2:

	Script-based k-of-n multisignature publishes keys and multiple signatures on chain. [[MuSig]] (MuSig2) aggregates keys into one on-chain key but requires every listed participant to sign (n-of-n). Threshold Schnorr schemes share the secret so only ''k'' shares are needed to sign.		Script-based k-of-n multisignature publishes keys and multiple signatures on chain. [[MuSig]] (MuSig2) aggregates keys into one on-chain key but requires every listed participant to sign (n-of-n). Threshold Schnorr schemes share the secret so only ''k'' shares are needed to sign.

			== Signing ==

	FROST, described by Chelsea Komlo and Ian Goldberg, binds each signer to a nonce commitment before the challenge is known, which addresses earlier forgery attacks on naive threshold Schnorr designs. Signing uses two rounds of commitments and signature shares. A coordinator may assemble shares into one signature. Nonce reuse across sessions can leak key material.		FROST, described by Chelsea Komlo and Ian Goldberg, binds each signer to a nonce commitment before the challenge is known, which addresses earlier forgery attacks on naive threshold Schnorr designs. Signing uses two rounds of commitments and signature shares. A coordinator may assemble shares into one signature. Nonce reuse across sessions can leak key material.

	A Taproot-oriented ciphersuite is required for x-only keys and BIP340 hashing conventions. A FROST group key used as a [[Taproot]] internal key still needs the BIP341 tweak applied correctly at keygen or signing time. On-chain, a successful Taproot key-path spend does not reveal that FROST was used.		A Taproot-oriented ciphersuite is required for x-only keys and BIP340 hashing conventions. A FROST group key used as a [[Taproot]] internal key still needs the BIP341 tweak applied correctly at keygen or signing time. On-chain, a successful Taproot key-path spend does not reveal that FROST was used.

			== Key generation ==

	Distributed key generation must produce verifiable shares before signing. Many deployments use a dealer or a multi-round DKG so that no single machine ever holds the full secret. A dishonest coordinator can bias which honest subset completes a signing session, but cannot forge a BIP340-valid signature without ''k'' valid shares. Implementations that target Bitcoin should document their ciphersuite and Taproot tweak handling explicitly.		Distributed key generation must produce verifiable shares before signing. Many deployments use a dealer or a multi-round DKG so that no single machine ever holds the full secret. A dishonest coordinator can bias which honest subset completes a signing session, but cannot forge a BIP340-valid signature without ''k'' valid shares. Implementations that target Bitcoin should document their ciphersuite and Taproot tweak handling explicitly.

			Threshold wallets must define what happens when signers go offline between DKG and spending. Refreshing shares (proactive security) is optional in RFC 9591 deployments and must be documented if used.


	== See also ==		== See also ==

NotATether: Add DKG and coordinator trust bounds

2026-09-12T21:11:31Z

Add DKG and coordinator trust bounds

← Older revision		Revision as of 21:11, 12 September 2026
Line 6:		Line 6:

	A Taproot-oriented ciphersuite is required for x-only keys and BIP340 hashing conventions. A FROST group key used as a [[Taproot]] internal key still needs the BIP341 tweak applied correctly at keygen or signing time. On-chain, a successful Taproot key-path spend does not reveal that FROST was used.		A Taproot-oriented ciphersuite is required for x-only keys and BIP340 hashing conventions. A FROST group key used as a [[Taproot]] internal key still needs the BIP341 tweak applied correctly at keygen or signing time. On-chain, a successful Taproot key-path spend does not reveal that FROST was used.

			Distributed key generation must produce verifiable shares before signing. Many deployments use a dealer or a multi-round DKG so that no single machine ever holds the full secret. A dishonest coordinator can bias which honest subset completes a signing session, but cannot forge a BIP340-valid signature without ''k'' valid shares. Implementations that target Bitcoin should document their ciphersuite and Taproot tweak handling explicitly.

	== See also ==		== See also ==

NotATether: FROST stub — threshold Schnorr / RFC 9591

2026-09-09T13:27:41Z

FROST stub — threshold Schnorr / RFC 9591

New page

'''FROST''' (Flexible Round-Optimized Schnorr Threshold signatures) is a two-round threshold signature protocol. Any subset of ''k'' honest participants out of ''n'' can produce a single BIP340 Schnorr-compatible signature for a shared public key, and fewer than ''k'' cannot. With a Bitcoin-compatible ciphersuite the result verifies like an ordinary Schnorr signature. FROST is specified in [https://www.rfc-editor.org/rfc/rfc9591 RFC 9591]. It is not a Bitcoin consensus change and is not a BIP. It is an off-chain signing protocol whose output is a normal signature.

Script-based k-of-n multisignature publishes keys and multiple signatures on chain. [[MuSig]] (MuSig2) aggregates keys into one on-chain key but requires every listed participant to sign (n-of-n). Threshold Schnorr schemes share the secret so only ''k'' shares are needed to sign.

FROST, described by Chelsea Komlo and Ian Goldberg, binds each signer to a nonce commitment before the challenge is known, which addresses earlier forgery attacks on naive threshold Schnorr designs. Signing uses two rounds of commitments and signature shares. A coordinator may assemble shares into one signature. Nonce reuse across sessions can leak key material.

A Taproot-oriented ciphersuite is required for x-only keys and BIP340 hashing conventions. A FROST group key used as a [[Taproot]] internal key still needs the BIP341 tweak applied correctly at keygen or signing time. On-chain, a successful Taproot key-path spend does not reveal that FROST was used.

== See also ==
* [[MuSig]]
* [[Taproot]]
* [[Multi-signature]]

== External links ==
* [https://www.rfc-editor.org/rfc/rfc9591 RFC 9591: Two-Round Threshold Schnorr Signatures with FROST]
* [https://eprint.iacr.org/2020/852.pdf FROST paper (IACR ePrint 2020/852)]
* [https://frost.zfnd.org/ ZF FROST documentation]
* [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340: Schnorr signatures for secp256k1]

[[Category:Technical]]