Erick λ
Erick λ
This is open, again.
Nice work! It's looking good. I'm not sure if we should use the same Secp256k1 library that is inside in the Bitcoin module. Having a Git submodule would make it...
> Reason for opening in draft is that the functions `private_to_public` and `ecdh` are working correctly, but the functions `sign_compact` and `sign_der` have mismatched signatures between modules. I’m not sure...
> Thanks for looking into this. Yes, we could do that and match the implementation of decred secp256k1 with libsecp256k1. However, the reason I did not add this in the...
> Here it loops until it finds a low R and not low S. From what I found, this is done for size optimization, so that the tx size is...
> > As you said, if the signatures are different, it's a bug, so we don't need to call `secp256k1_ecdsa_signature_normalize`. > > Okay, I’m not sure about the details or...
> I don’t think this is required, since we are already doing this: > > ```c > if (!secp256k1_ec_seckey_verify(secp256k1_ctx, privkey)) > { > return std::nullopt; > } > ``` >...
> I think we could remove all the unnecessary stuff from secp256k1 (e.g. .github, CHANGELOG, CONTRIBUTING, etc) I have removed those now!
> Needs rebase. What's the status of it? Edited: I actually think it's ready to go. Since this is already a significant PR, it would be better to make the...
> Was thinking of doing differential fuzzing between libsecp256k1 and Decred’s secp256k1. If this hasn’t been started yet, can I pick it up? Yes, feel free to take this on.