Stolen content from @Rob1Ham on Xitter. Worthy of nostr, methinks. ––––– Good morning! Grab a cup of coffee, and lock in for a bitcoin tech thread 🧵.

Today I’ll do a light rambling on Schnorr Signature aggregation and current use cases, as well as some shoutouts to some of the companies pioneering the use of this in production.

Lets Begin 👇

First, lets talk about how bitcoin signatures work today.

For a multisig (say 2 of 3), you have to put all 3 public keys on chain, and then you use OP_CHECKMULTISIG to verify the 2 signatures.

That is a total of 3 keys and 2 signatures on chain

Signature aggregation allows for multiple keys to be combined off chain, and only the combined key is put on chain.

The same is done for signatures, combined off chain, and only the final signature is put on chain.

This makes Multisigs indistinguishable from single sigs!

This requires the taproot upgrade, because the original bitcoin client uses the ECDSA (Eliptic Curve Digital Signature Algorithim). Schnorr signatures were under patent when Bitcoin originally released. When the patent lapsed, it was added into the taproot upgrade.

There are two implementations leveraging Schnorr Signatures for use in Bitcoin today:

MUSIG2, and FROST.

Lets talk about MUSIG2 first.

MUSIG does key aggregation on an N of N basis.

So if you have 4 parties, they can combine their key so instead of it being a 4 of 4 multisig, there is a single aggregated 4 of 4 key.

Then to sign, all 4 parties must sign the transaction.

4 parties, but 1 key and 1 signature.

You see use of it already today in projects like @ArkLabsHQ. The power in having an ASP (Ark Service Provider) in holding a key, and the user holding a key, is that the ASP effectively is able to act as policy enforcement for the movement of funds.

arkadeos.com/

Said another way, since the ASP has to cosign the funds, if they rules are followed, they sign, so its all enforced off chain.

Today, this means covenants, tomorrow, it can be whatever you want to code up. Since its just a signature, this can all be done without a fork!

MUSIG2 was added to the secp256k1 library (the reference bitcoin cryptography library) earlier this year.

This is a huge endorsement in having the worlds leading cryptographers who focus on bitcoin providing a production ready library.

https://github.com/bitcoin-core/secp256k1/tree/master

Additionally, @achow101 as updated the descriptor logic to add support for MUSIG2 into Bitcoin Core version 30. Allowing for direct interoperability with Bitcoin Core today, and other libraries such as @bitcoindevkit in the future.

https://github.com/bitcoin/bitcoin/pull/31244

For hardware wallet support, @salvatoshi at @Ledger has lead the way and as of version 2.4 of the bitcoin app now includes MUSIG support.

https://www.ledger.com/blog-musig2-ledger-bitcoin-app

Lets talk about FROST now. FROST stands for:

Flexible Round-Optimized Schnorr Threshold Signatures

Similar to MUSIG with the combining of keys & signatures with a critical difference, you don’t need ALL parties to sign the transaction!

An interesting property emerges from FROST. You can rotate keys managing funds without ever having to move funds on chain.

The mechanics are too complicated to get into in this thread, but in short, if you have the required amount of signers, you can generate new shares.

One of the main players working on advancing FROST is @jesseposner, our crypographic shaman putting in the challenging work to securely get this standard with wider use of adoption.

I’m sure the cool stuff he is cooking up at @voravault will be leveraging FROST.

The other team I know who has put a lot of work into FROST is the @FrostsnapTech team.

Made up of @sakak_musdom @LLFOURN and @utxoclub, they are bringing the first special purpose FROST signing to real life:

https://frostsnap.com/

The team just went on @citadeldispatch, check out the show here: https://fountain.fm/episode/sbQMbxEfWELrF95W1OqR

What prompted me to kick off this thread was the @FrostsnapTech pre order just went live and I ordered a kit check it out here!

frostsnap.com/buy.html

Both MUSIG and FROST are compatible with miniscript, specifically Tapminiscript (taproot miniscript).

We see this technology as having a strong potential of extending what we are building at @AnchorWatch for advancing bitcoin custody and security.

Shoot me a DM or go to anchorwatch.com if you’re interested in learning more about insured bitcoin custody!