pull down to refresh

The still a impressive @Rsync25 posted about this back in 2024 (#619760), but there's been a lot of progress and it now has a BIP number!

FROST is cool for a number of reasons, but the one that most often gets mentioned is that it allows users of a multisig to make signatures that are indistinguishable from single sig signatures.

Unfortunately, while a lot of progress has been made for FROST signing, the kind of Schnorr signatures now used in Bitcoin aren't quite compatible with FROST:

However, the signatures produced by RFC 9591 (the FROST standard) are incompatible with BIP340 Schnorr signatures due to the X-only public keys introduced in BIP340. Additionally, RFC 9591 does not specify key tweaking mechanisms, which are essential for Bitcoin applications such as BIP32 key derivation and BIP341 Taproot. This document addresses these limitations by specifying a BIP340-compatible variant of FROST signing protocol that supports key tweaking.

So here comes BIP 445 with a proposal for how FROST signing could be made to work with Schnorr signatures as they are used in Bitcoin.

This is cool because:

  1. The on-chain footprint of a FROST Taproot output is essentially a single BIP340 public key, and a transaction spending the output only requires a single signature cooperatively produced by at least t signers. This is more compact and has lower verification cost than each signer providing an individual public key and signature, as would be required by an t-of-n policy implemented using OP_CHECKSIGADD as introduced in BIP342. As a side effect, the number n of signers is not limited by any consensus rules when using FROST.
  2. FROST Taproot outputs are indistinguishable for a blockchain observer from regular, single-signer Taproot outputs even though they are actually controlled by multiple signers. By tweaking the threshold public key, the shared Taproot output can have script spending paths that are hidden unless used.

There is still work that needs to be done actually generating keys that could be used on this way, but at least we've got a plan for how to do signatures if we had such distributively generated keys.

Also, cryptography is kinda crazy, so take this with a grain of salt.

Here is a link to the discussion on the BIP PR:
https://github.com/bitcoin/bips/pull/2070