why do we accept AnySignature if we only verify for Secp256k1Account? why is Secp256k1Signature is not part of AnySignature? Also, why do we accept HexInput as a signature? dont we want to make sure the function accepts a valid signature?

I agree, public key recovery should be in the signature to return. I don't think it belongs at the account level given you can't recover the private key

Because Secp256k1Account does not exist. SingleKeyAccount exists which returns AnySignature when it signs something. You can get the inner Secp256k1Signature via signature.signature, but you would still have to type check it into Secp256k1Signature. Having the function handle it seems better DevX

@gregnazario not sure what you are suggesting

Oh and HexInput is again for convenience. The function will check signature validity.

I also would expect this function to be in a different place than Account.

I think Secp256k1PublicKey.fromMessageAndSignature makes total sense (fromSignedMessage could be even more concise).

Ideally that's all the devs would need, and they could do the following:

const innerPublicKey = new Secp256k1PublicKey.fromSignedMessage({ message, signature });
const publicKey = new AnyPublicKey({ publicKey: innerPublicKey });
const derivedAddress = publicKey.authKey().derivedAddress.toString();

// Simple case
const isValid = derivedAddress === accountAddress;

// Handle rotated auth keys
const { authentication_key } = await aptos.getAccountInfo({ accountAddress });
const isValid = derivedAddress === authentication_key;

now.. how can we make this even easier / more concise?

1. Going from Secp256k1PublicKey to AnyPublicKey is a bit annoying, maybe we can have the constructor there instead: AnyPublicKey.fromSecp256k1SignedMessage({ message, signature })
2. The action of verifying the publicKey is associated to an account from its address is agnostic to the signature scheme, so we could have verifyAuthenticationKey({ authKey, accountAddress }) which could live in the api to avoid dependency cycles

I really hate the AnyPublicKey name ugh

So the problem is you need to look up the auth key with the address, and only via the auth key can you figure out which public key is correct. If a recovery is provided 2 public keys would be returned.

I'm down for AnyPublicKey.fromSecp256k1SignedMessage({ message, signature }) though

Yeah I re-evaluated it and did similar here aptos-labs/aptos-go-sdk#108

So the problem is you need to look up the auth key with the address, and only via the auth key can you figure out which public key is correct. If a recovery is provided 2 public keys would be returned.

Oh I see, gotcha makes sense

I also would expect this function to be in a different place than Account.

I think Secp256k1PublicKey.fromMessageAndSignature makes total sense (fromSignedMessage could be even more concise).

Ideally that's all the devs would need, and they could do the following:

const innerPublicKey = new Secp256k1PublicKey.fromSignedMessage({ message, signature });
const publicKey = new AnyPublicKey({ publicKey: innerPublicKey });
const derivedAddress = publicKey.authKey().derivedAddress.toString();

// Simple case
const isValid = derivedAddress === accountAddress;

// Handle rotated auth keys
const { authentication_key } = await aptos.getAccountInfo({ accountAddress });
const isValid = derivedAddress === authentication_key;

now.. how can we make this even easier / more concise?

1. Going from Secp256k1PublicKey to AnyPublicKey is a bit annoying, maybe we can have the constructor there instead: AnyPublicKey.fromSecp256k1SignedMessage({ message, signature })
2. The action of verifying the publicKey is associated to an account from its address is agnostic to the signature scheme, so we could have verifyAuthenticationKey({ authKey, accountAddress }) which could live in the api to avoid dependency cycles