Closed nickfarrow closed 2 years ago
Thanks for looking at this. Looking forward to the PR.
Would this be BIP 340 compatible?
Can this support BIP 32 derivations?
- Would this be BIP 340 compatible?
We're making sure joint public keys have even Y coordinates, and are using FROST specific key-prefixing by tending to hash all public information where available. As well as tagged hashes. So i believe so!
- Can this support BIP 32 derivations?
Currently this code produces a single joint public key for the multisignature (which can be tweaked). I'm actually not too sure how exactly address derivation will work, i think same as MuSig. But my naive understanding would be that the joint public key could somehow be used for the BIP32 parent public key, maybe @LLFourn has some ideas here
Edit: We've implemented both FrostKey
and XOnlyFrostKey
allowing for plain tweaking (bip32) and xonly tweaking (taproot commitments)
doc test now seems to be failing because of some unrelated file
Documenting ecdsa_fun v0.7.1 (/home/runner/work/secp256kfun/secp256kfun/ecdsa_fun)
warning: unresolved link to `derive_nonce`
--> secp256kfun/src/nonce.rs:148:41
|
148 | /// In general it's better to use the [`derive_nonce`] macro than to call
| ^^^^^^^^^^^^ no item named `derive_nonce` in scope
Paper of interest: Threshold Signatures with Private Accountability (no eprint yet but there is a presentation and upcoming seminar (AEDT - 11 Oct 2022 11:00 AM)
FROST (Flexible Round-Optimized Schnorr Threshold) implementation
t-of-n
keygen and signing proptest with random parties, threshold, and signers. Proptest carries out keygen and then uses a random mask to create a set of signers who create a combined signature.This implementation has not yet been made compatible with other FROST implementations or forthcoming specifications. https://github.com/ElementsProject/secp256k1-zkp/pull/138 https://github.com/isislovecruft/frost-dalek https://github.com/cfrg/draft-irtf-cfrg-frost