The following is a rough summary of the FROST-CLI demo meeting on August 6, 2025.
Intro
There are two great tools for FROST and for Bitcoin:
But how do we combine ZF FROST with BDK for PSBT signing on Bitcoin?
- ZF FROST needed secp256k1 fully enabled
- Then BDK needed to apply signature with a tweak
- And some of what was needed wasn’t available in CLI
Demo
The demo spends a taproot Bitcoin
- with a 2-of-3 FROST Signature
Description & outline of demo is available at:
- https://hackmd.io/@bc-community/H1MfEMdvel
Step-by-step demo is at:
- https://hackmd.io/@bc-community/BJ2VtYKUxl
The demo sends money to a FROST wallet, then sends it back.
Generating a FROST Wallet
Done with trusted-dealer from ZF FROST tools with our secp256k1-tr patch.
- Can then generate verifying key and descriptors from package
The demo is done with the Trusted Dealer mode of ZF FROST
- That means all shares are generated one one device, for distribution.
- This isn’t the ideal security methodology
- But we had troubles getting Distributed Key Generation (DKG), where keys are never on the same device, to work.
BDK-CLI can then be used to generate wallet from descriptors.
- but it’s watch-only!
We can now send money to FROST wallet.
Sending the Money Back
We can’t send the money straight back from the wallet using BDK, because we set the wallet up as watch only. Instead, the FROST quorum has to sign to spend the money from the new FROST wallet
Extracting Transaction sighash
We generate an unsigned PSBT from the FROST wallet.
We did not hack the BDK-CLI, but instead created Rust helpers (with full code in the step-by-step).
The first tool is the sighash-helper tool, which reads the PSBT and extracts sighash from it.
(In a production demo, each signer would extract the sighash themself because they have to know what they’re signing!)
Running the FROST Ceremony
For this, we run the FROST-tools coordinator, which waits for participants to offer shares.
We then run participant and send the key packages we created. We do this twice, using the two different key packages.
coordinator then creates signing package for Taproot and waits for participants to send signing shares, which participants do with participant.
Raw signature is generated!
Signing PSBT
We have a second tool, psbt-sig-attach, that inserts FROST signature into PSBT.
Creates signed PSBT.
The PSBT can then be finalized using bdk-cli.
We then broadcast and the transaction goes out! Voila!
Open Questions on ZF FROST
- What is Status of PRs?
ZF FROST is considered to be in a complete state right now, but PRs will be reviewed.
- What has been security reviewed?
Did not include Schnorr BIP340 review.
But more security reviews might be possible! There might be a grant for them already!
Other Open Questions
- What is right place to do tweak?
The demo raised some interested architectural questions, unresolved, about who/when tweaking is done. Some hardware wallets might not be robust enough to do the tweak, and different assets (e.g., Bitcoin vs Lightning) might have different understandings about how permanent/ephemeral the tweak is.
One answer is to have the coordinator do it, which is essentially what our demo does, but there’s enough complexity that more discussion is needed.
- Are there privacy implications for servers when using tweaks?
There are generally security issues for collaborative custody, esp. where one collaborator might be a third-party server
- Third-party can always spy even if it’s not signing
But the chain code can be an additional security measure
- There’s only one chain code for FROST!
- You don’t have to tell it to everyone
- Not telling it to the server secure things from that third-party
- Because of the tweak, they won’t recognize children keys
- And if you require them to sign, they can do a blind-signature
-
Possibly with a zero-knowledge proof
- *Are there ways to use FROST quorum for encryption?8
There’s a paper setting out possibilities.
- What are best practices of storing DKG and VSS values?
(Definitely an open question!)
What’s Next
We’ve got more to come on FROST this year. More meetings are planned for this fall. If you’re an implementer, we’d love to hear about your tech; if you’re a developer, we’d love to hear about your needs. <a href=”mailto:team@blockchaincommons.com>email us</a> if you’d like to give a short presentation!
Thanks to HRF for their support of our FROST work both last year and this year!