Agreed, and taken. It was multiple lines once I found the seam, so it’s out of the proposal. I’ll clean the injector up and PR it to frost-tools this week. If you’d rather write it yourself, say so and I’ll stay out of your way, genuinely no ego about it.
This changed my thinking most. I’d assumed the key-generation gap was open and that I could help draft something; it isn’t, so I’d rather be the implementation that helps #895 and #1032 move than another author.
One question from reading ZIP-2005 and cocktail-dkg together. ZIP-2005 has the participants agree on sk and each retain qsk, and says losing qsk loses the funds once Orchard is disabled. The sk contributions look like they belong in COCKTAIL’s optional application payloads, with the extension derived from them so the transcript enforces agreement. But recovery’s output is only x_i, Y and the verification shares: step 6 decrypts the whole plaintext and keeps just the leading scalar, so the payload sits right there and gets dropped. Read literally, recovery hands back a signing share and quietly loses qsk.
And ZIP-2005’s answer for qsk backup is ZIP-32 re-derivation from the seed, then it says a deployment not using ZIP-32 is on its own. A DKG group is exactly that deployment, with no seed to fall back on, which is rather the point.
So: should recovery return the payloads, or is the application meant to dig them out itself? Happy to write it up on the C2SP issue if it’s real and I’m not misreading.
Agreed. It was only ever how I got a first signature out of the stack.
I hadn’t clocked that, which is a hole in my homework, so I read it before replying rather than after. Credit where it’s due: real DKG, no trusted dealer, a GUI, mainnet since last July. Further along than I’d assumed anyone was.
@hanh, a sanity check if you have a minute.
As far as I can tell the FROST signing path only walks the Orchard actions and calls sign_orchard_with, and DKG mints an Orchard-only UA; ironwood_indices turns up in the Ledger builder but not in frost/. So Zkool’s threshold accounts are Orchard accounts. Have I got that right, or is there an Ironwood path I’ve missed?
You’re right that it’s the hard part, though I’d argue about where it lives. “My savings need two of my three devices” belongs in a wallet, and Zkool is most of the way there. “Five people, a policy, an auditor, hardware, and a recovery drill” is a different animal, whose hard parts are the ceremony, the recovery and the audit trail, not send and receive.
What convinced me it isn’t just polish is your own recommendation. COCKTAIL says you MUST NOT use the group key for critical operations, naming long-lived asset custody, until every participant confirms they’ve stored their recovery material, and the round-1 ciphertexts must survive somewhere durable, coordinator included. Those are ceremony obligations no library discharges for you; for this use case the UI is the security work.
So I’d rather the core be an embeddable crate than a wallet feature. Then nobody writes a grant against anyone else’s roadmap, and if Zodl or Zkool wants it later it’s there. Zodl being mobile-only is a fit problem anyway: a treasury ceremony wants a desk, several people and a hardware signer on the table.
Agreed, and I can’t solve it in general. One narrowing for my case: with hardware signers the signing round can go over QR, which Keystone does anyway and devtool already has to-qr/from-qr for, so network privacy doesn’t arise for the round that authorizes money. The ceremony is the awkward one, three rounds across n participants being a lot of QR codes. My instinct is frostd behind an onion rather than inventing a transport. Would you take a Tor transport in frostd upstream, or does that belong client side?
@dismad, thanks, I looked. Found Steward in the PRs, close enough that I’m glad I read it. If the rest are visible once voting opens I’d like to go through them; I’d rather find out I’m duplicating someone this week than after I apply.