Open tbraun96 opened 5 months ago
Using frost_taproot instead of frost_secp256k1 works, since wsts and frsot_secp256k1 does use different challenge strings
Using frost_taproot instead of frost_secp256k1 works, since wsts and frsot_secp256k1 does use different challenge strings
Yeah we use taproot compatible challenge strings in many (maybe all) contexts.
I always planned on offering a nostd
build feature, would you like me to do that sooner rather than later? I actually did that for the dalek crates years ago, it was my first PRs for them.
We are using the
frost-secp256k1
crate for verification of WSTS-generated signatures:frost-secp256k1 { git = "https://github.com/LIT-Protocol/frost" }
.In theory, the math should be identical to this repo's use of Schnorr. Signatures in both crates use
R
andz
values. This is how we convert from a WSTS signature to a ZCash FROST signature:And, this is how we convert from a WSTS group public key to a ZCash FROST group public key:
Note: We are using
wsts=3.0.0
.The
to_bytes()
function returns in big-endian. All functions that receive these big-endian bytes also expect a big-endian input. I have verified that the sizes are all correct, and, that none of this code panics.However, when we attempt to verify using ZCash FROST, we get an invalid signature. I know this question may be outside of the scope of this repo, however, we do need to use
wsts
for our DKG and later use ano-std
friendly crate for Schnorr signature verifications (specifically over secp256k1). Are there any ideas as to what we're doing wrong, or, if this is even possible? Thanks!