<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://en.bitcoin.it/w/index.php?action=history&amp;feed=atom&amp;title=FROST</id>
	<title>FROST - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://en.bitcoin.it/w/index.php?action=history&amp;feed=atom&amp;title=FROST"/>
	<link rel="alternate" type="text/html" href="https://en.bitcoin.it/w/index.php?title=FROST&amp;action=history"/>
	<updated>2026-09-11T19:33:04Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.43.9</generator>
	<entry>
		<id>https://en.bitcoin.it/w/index.php?title=FROST&amp;diff=71236&amp;oldid=prev</id>
		<title>NotATether: FROST stub — threshold Schnorr / RFC 9591</title>
		<link rel="alternate" type="text/html" href="https://en.bitcoin.it/w/index.php?title=FROST&amp;diff=71236&amp;oldid=prev"/>
		<updated>2026-09-09T13:27:41Z</updated>

		<summary type="html">&lt;p&gt;FROST stub — threshold Schnorr / RFC 9591&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;&amp;#039;&amp;#039;&amp;#039;FROST&amp;#039;&amp;#039;&amp;#039; (Flexible Round-Optimized Schnorr Threshold signatures) is a two-round threshold signature protocol. Any subset of &amp;#039;&amp;#039;k&amp;#039;&amp;#039; honest participants out of &amp;#039;&amp;#039;n&amp;#039;&amp;#039; can produce a single BIP340 Schnorr-compatible signature for a shared public key, and fewer than &amp;#039;&amp;#039;k&amp;#039;&amp;#039; 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.&lt;br /&gt;
&lt;br /&gt;
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 &amp;#039;&amp;#039;k&amp;#039;&amp;#039; shares are needed to sign.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== See also ==&lt;br /&gt;
* [[MuSig]]&lt;br /&gt;
* [[Taproot]]&lt;br /&gt;
* [[Multi-signature]]&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
* [https://www.rfc-editor.org/rfc/rfc9591 RFC 9591: Two-Round Threshold Schnorr Signatures with FROST]&lt;br /&gt;
* [https://eprint.iacr.org/2020/852.pdf FROST paper (IACR ePrint 2020/852)]&lt;br /&gt;
* [https://frost.zfnd.org/ ZF FROST documentation]&lt;br /&gt;
* [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340: Schnorr signatures for secp256k1]&lt;br /&gt;
&lt;br /&gt;
[[Category:Technical]]&lt;/div&gt;</summary>
		<author><name>NotATether</name></author>
	</entry>
</feed>