|
| 1 | +--- |
| 2 | +cover: false |
| 3 | +header: |
| 4 | + overlay_color: "#000" |
| 5 | + overlay_filter: "0.25" |
| 6 | + overlay_image: /assets/images/dev-arch-background.jpg |
| 7 | + og_image: /assets/images/bc-card.jpg |
| 8 | +title: "Gordian FROST-CLI Meeting (08/25): Summary" |
| 9 | +hide_description: true |
| 10 | +classes: |
| 11 | + - wide |
| 12 | +sidebar: |
| 13 | + nav: meetings |
| 14 | +--- |
| 15 | + |
| 16 | +_The following is a **rough summary** of the FROST-CLI demo meeting on August 6, 2025._ |
| 17 | + |
| 18 | +## Intro |
| 19 | + |
| 20 | +There are two great tools for FROST and for Bitcoin: |
| 21 | + |
| 22 | +* [ZF FROST](https://frost.zfnd.org) |
| 23 | +* [Bitcoin Dev Kit (BDK)](https://bitcoindevkit.org/) |
| 24 | + |
| 25 | +But how do we combine ZF FROST with BDK for PSBT signing on Bitcoin? |
| 26 | + |
| 27 | +* ZF FROST needed secp256k1 fully enabled |
| 28 | +* Then BDK needed to apply signature with a tweak |
| 29 | + * And some of what was needed wasn't available in CLI |
| 30 | + |
| 31 | +## Demo |
| 32 | + |
| 33 | +The demo spends a taproot Bitcoin |
| 34 | +- with a 2-of-3 FROST Signature |
| 35 | + |
| 36 | +Description & outline of demo is available at: |
| 37 | +* https://hackmd.io/@bc-community/H1MfEMdvel |
| 38 | + |
| 39 | +Step-by-step demo is at: |
| 40 | +* https://hackmd.io/@bc-community/BJ2VtYKUxl |
| 41 | + |
| 42 | +The demo sends money to a FROST wallet, then sends it back. |
| 43 | + |
| 44 | +### Generating a FROST Wallet |
| 45 | + |
| 46 | +Done with `trusted-dealer` from ZF FROST tools with our `secp256k1-tr` patch. |
| 47 | +* Can then generate verifying key and descriptors from package |
| 48 | + |
| 49 | +BDK-CLI can then be used to generate wallet from descriptors. |
| 50 | +- but it's watch-only! |
| 51 | + |
| 52 | +We can now send money to FROST wallet. |
| 53 | + |
| 54 | +### Sending the Money Back |
| 55 | + |
| 56 | +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 |
| 57 | + |
| 58 | +### Extracting Transaction sighash |
| 59 | + |
| 60 | +We generate an unsigned PSBT from the FROST wallet. |
| 61 | + |
| 62 | +We did not hack the BDK-CLI, but instead created Rust helpers (with full code in the [step-by-step](https://hackmd.io/@bc-community/BJ2VtYKUxl)). |
| 63 | + |
| 64 | +The first tool is the `sighash-helper` tool, which reads the PSBT and extracts sighash from it. |
| 65 | + |
| 66 | +(In a production demo, each signer would extract the sighash themself because they have to know what they're signing!) |
| 67 | + |
| 68 | +### Running the FROST Ceremony |
| 69 | + |
| 70 | +For this, we run the FROST-tools `coordinator`, which waits for participants to offer shares. |
| 71 | + |
| 72 | + We then run `participant` and send the key packages we created. We do this twice, using the two different key packages. |
| 73 | + |
| 74 | +`coordinator` then creates signing package for Taproot and waits for participants to send signing shares, which participants do with `participant`. |
| 75 | + |
| 76 | +Raw signature is generated! |
| 77 | + |
| 78 | +### Signing PSBT |
| 79 | + |
| 80 | +We have a second tool, `psbt-sig-attach`, that inserts FROST signature into PSBT. |
| 81 | + |
| 82 | +Creates signed PSBT. |
| 83 | + |
| 84 | +The PSBT can then be finalized using `bdk-cli`. |
| 85 | + |
| 86 | +We then broadcast and the transaction goes out! Voila! |
| 87 | + |
| 88 | +## Open Questions on ZF FROST |
| 89 | + |
| 90 | +* **What is Status of PRs?** |
| 91 | + |
| 92 | +ZF FROST is considered to be in a complete state right now, but PRs will be reviewed. |
| 93 | + |
| 94 | +* **What has been security reviewed?** |
| 95 | + |
| 96 | +Did not include Schnorr BIP340 review. |
| 97 | + |
| 98 | +But more security reviews might be possible! There might be a grant for them already! |
| 99 | + |
| 100 | +## Other Open Questions |
| 101 | + |
| 102 | +* **What is right place to do tweak?** |
| 103 | + |
| 104 | +- Probably have the coordinator do it! |
| 105 | + |
| 106 | +* **Are there privacy implications for servers when using tweaks?** |
| 107 | + |
| 108 | +There are generally security issues for collaborative custody, esp. where one collaborator might be a third-party server |
| 109 | +- Third-party can always spy even if it's not signing |
| 110 | + |
| 111 | +But the chain code can be an additional security measure |
| 112 | +- There's only one chain code for FROST! |
| 113 | +- You don't have to tell it to everyone |
| 114 | +- Not telling it to the server secure things from that third-party |
| 115 | +- Because of the tweak, they won't recognize children keys |
| 116 | +- And if you require them to sign, they can do a blind-signature |
| 117 | +- Possibly with a zero-knowledge proof |
| 118 | + |
| 119 | +* **Are there ways to use FROST quorum for encryption?*8 |
| 120 | + |
| 121 | +There's a paper setting out possibilities. |
| 122 | + |
| 123 | +* **What are best practices of storing DKG and VSS values?** |
| 124 | + |
| 125 | +(Definitely an open question!) |
0 commit comments