Search on TFTC
Issue #1379: Using FROST to Increase Privacy in Collaborative Bitcoin Custody Models

Issue #1379: Using FROST to Increase Privacy in Collaborative Bitcoin Custody Models

Aug 30, 2023
Marty's Ƀent

Issue #1379: Using FROST to Increase Privacy in Collaborative Bitcoin Custody Models

via Nick Farrow

Here's an incredibly cypherpunk application of FROST to improve the privacy of collaborative custody models leveraged by bitcoiners. Nick Farrow took to the bitcoin-dev mailing list earlier this week to lay out his idea for a private collaborative custody solution using FROST.

For those who are unaware, FROST stands for Flexible Round-Optimized Schnorr Threshold Signatures and it leverages Schnorr signatures and Taproot addresses to allows individuals to create multi-sig quorums that look like a single sig output on-chain. FROST achieves this by enabling each quorum to produce a joint FROST key that is used to sign a transaction after a threshold of members sign their key shares. This is a massive privacy benefit as it makes it impossible to tell whether or not an input was produced by a multi-sig spend or a single-sig spend. If implemented into popular wallet softwares individuals and businesses would be able to have peace of mind knowing that it is impossible for people to determine the type of key set up they are using.

Nick's mailing list post from earlier this week is exploring the possibility of creating a collaborative custody service that enables third parties who are participating in a FROST multi-sig quorum to sign without knowing exactly what transaction they're signing. Adding a solid layer of privacy to those using FROST multi-sig quorums while engaging with a third party signing service. Again, an incredibly cypherpunk application that is made possible via bitcoin.

It should be noted that FROST isn't exactly the same as the on-chain multisig mechanics that you are probably familiar with. FROST is a multiparty computation (MPC) multisig, which means the multisig quorum is coordinated off chain. Once the necessary threshold signers coordindate and sign off chain, an on chain key can then be signed. There are tradeoffs that come with MPC, mainly revolving around nonce generation that, if not done properly, can erode the security of a private key. However, the team at BitGo recently came up with a unique solution to the nonce generation tradeoff by leveraging the data field space in PSBTs to ensure randomness before signing. It will be interesting to see if MPC becomes more popular across the industry. From what I understand, the ability to leverage Schnorr signatures allows for the creation of more secure MPC set ups.

In an environment in which many are fighting to push more soft forks into bitcoin it's awesome to see developers pushing to the edges of what's possible yet little explored. I am of the persuasion that exploring everything currently at our fingertips that has been enabled because of upgrades like SegWit and Taproot before having discussions about contentious soft forks is the best course of action. Shoutout to Nick Farrow and others who are working to help us realize what is possible now.

Final thought...

Writing with cheesy spy movies on in the background ain't that bad.

You have your place to buy Bitcoin, but have you tried River? It’s where all the Bitcoiners are now going. See why at
Sleep soundly at night knowing your bitcoin are secured by multisig.


Current Block Height

Current Mempool Size

Current Difficulty