This is a bit complicated, because smoldot simply calls libsecp256k1::recover, which verifies the signature and returns the public key both in the same function call.

Since the ext_crypto_secp256k1_ecdsa_recover_version_2 function returns that public key, if the signature is invalid it simply can't proceed.

libsecp256k1 doesn't seem to have a way to pass a dummy signature and still recover the public key. Looking at the implementation, recovering the public key involves some math, and some of that math might return InvalidSignature, so it seems to make sense to me that this is implemented as a single function, it's not just "security by restrictive public API" like some libraries do. But also maybe this just checks whether the signature has a valid format, rather than check the signature itself? I don't know enough about secp256k1 to know what makes sense to implement.

Does it make sense for you if, when you're trying to mock an ECDSA signature, smoldot asks you to provide the associated public key?

@xlc I don't think there's a need to change anything on smoldot. Chopsticks mock signature is creating signature with 64 bytes while ecdsa is 65. I think that might be the issue. Checking now

my bad, seems like RuntimeCall::SignatureVerification is called at all

Does it make sense for you if, when you're trying to mock an ECDSA signature, smoldot asks you to provide the associated public key?

yeah that’s fine. we can modify the mock signature format to include a public key