[Feature]: Remove public keys from AuthInfo

[trevormil]

Summary

Currently, every transaction, including personal message signatures (ADR36), require the public key of the Cosmos address to be specified in the AuthInfo. This is bad developer experience and can be eliminated by calculating it from the message + signature pair itself.

Problem Definition

No response

Proposed Feature

Developers should never need to know the public keys of the addresses for submitting transactions, signatures, etc. It should be auto calculated / recovered from the (signature, message) itself.

While recovering a public key from a (message, signature) pair is possible with secp256k1, it is impossible if you do not know the public key to begin with. This is because you sign the public key (via AuthInfo).

To generate the message, you need the public key to calculate the AuthInfo.
And this means if you just have the signature + address, you cannot recover it from that because the message includes the public key (which you do not know).

If it was not in the message itself, you could recover it from the (message, signature) pair.

[lucaslopezf]

Hi @trevormil ! Thanks for open an issue, but It is actually possible to send transactions without explicitly specifying the public key. Just an example:

You can do

- make install
- make init-simapp
- make build

Then

cosmos-sdk git:(main) ./build/simd query bank balances cosmos1xcnxmkl8ds8k3prv4vmvurt4a82yt6mg0ypf08
balances:
- amount: "5000000100"
  denom: stake
pagination:
  total: "1"
➜  cosmos-sdk git:(main) ./build/simd tx bank send cosmos15dw62yhml0lln2h5596gvjns4re3jer7j74r6s cosmos1xcnxmkl8ds8k3prv4vmvurt4a82yt6mg0ypf08 9stake  
auth_info:
  fee:
    amount: []
    gas_limit: "200000"
    granter: ""
    payer: ""
  signer_infos: []
  tip: null
body:
  extension_options: []
  memo: ""
  messages:
  - '@type': /cosmos.bank.v1beta1.MsgSend
    amount:
    - amount: "9"
      denom: stake
    from_address: cosmos15dw62yhml0lln2h5596gvjns4re3jer7j74r6s
    to_address: cosmos1xcnxmkl8ds8k3prv4vmvurt4a82yt6mg0ypf08
  non_critical_extension_options: []
  timeout_height: "0"
  timeout_timestamp: "1970-01-01T00:00:00Z"
  unordered: false
signatures: []
confirm transaction before signing and broadcasting [y/N]: y
code: 0
codespace: ""
data: ""
events: []
gas_used: "0"
gas_wanted: "0"
height: "0"
info: ""
logs: []
raw_log: ""
timestamp: ""
tx: null
txhash: EE1DA8978C1A027BB62A5E417FE5CCB9D68047F978E265AB4FEDF681CDB59A15
➜  cosmos-sdk git:(main) ./build/simd query bank balances cosmos1xcnxmkl8ds8k3prv4vmvurt4a82yt6mg0ypf08 
balances:
- amount: "5000000109"
  denom: stake
pagination:
  total: "1"

it’s true that in some specific cases, public keys may be required, this is not a general rule. Transactions can be completed without explicitly specifying the public key, as shown above. Could you clarify whether your issue refers to a specific use case, or if I misunderstood something? Providing a concrete example of the scenario you're referring to would help us address the problem more accurately. Thanks!!

[trevormil]

Hello, thanks for replying.

The problem that I was running into was that with personal message signatures (via ADR-36), the public key is required in the message and actually signed. Same thing applies to Cosmos transactions. This is a redundant step because it is recoverable after the fact.

https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-036-arbitrary-signature.md

This means that for all signature verifications, you need to always know the public key BEFORE the message is signed (in order to generate the message / transaction itself), whereas ideally, this should just be directly recovered from the signature itself AFTER the fact.

This results in development headaches that add up. For example, I have to always present a public key when verifying a signature. I cannot just have a consistent message that is signed by everyone (each one is uniquely generated and requires additional storage because it includes the public key which I have to store alongside it).

Again, just a suggestion, but little stuff that adds up.

[tac0turtle]

this makes the assumption that secp256k1 is being used, correct? We dont have that assumption in the sdk, the idea is to allow people to use any curve they would like, secp256k1 is only the default. The public key is usually present when signing anyways what is the overhead of including it? this is the first time we have received this feedback

[webmaster128]

Could you describe your very specific problem and use case here?

Using pubkey recovery is certainly not better / nicer / easier in general. It only works for ECDSA (secp256k1, secp256r1) signatures, the recoverey algo gives you two different pubkey options etc. Some things get easier, others get harder. In the signing process you have a private key neaby, so it should not be too hard to get the public key. Transaction have sequence numbers in the signing message, so they are signer specific anyways. That being said, I wonder if there are issues with the current system that prevent you from doing something you want to do.

[trevormil]

this makes the assumption that secp256k1 is being used, correct? We dont have that assumption in the sdk, the idea is to allow people to use any curve they would like, secp256k1 is only the default. The public key is usually present when signing anyways what is the overhead of including it? this is the first time we have received this feedback

Yea, you are right (or another algorithm that supports such recovery). I didn't think about this assumption.

Some things get easier, others get harder. In the signing process you have a private key neaby, so it should not be too hard to get the public key.

Correct, there are some tradeoffs. I was more interested like I said in personal message signatures (ADR 36), rather than transactions. The message signatures do not have sequences. Maybe this is more a problem with ADR 36.

I store (message, signature) pairs for other chains for my app for multiple features (sign ins, attestations, etc). On all other chains (EVM, Solana), I can simply store the message once (since it is constant) + all signatures. For Cosmos, I always have to store ((message + pubkey), signature) which adds storage and resources. Or, the alternative is that it requires an extra request every time I want to verify to actually fetch the public key.

Its not a big problem. It does not prevent me from doing anything, but it has made developing and supporting Cosmos a little more difficult. Again, it was just a suggestion. I do see the reasoning for it, but I just wanted to share my feedback with developing.

[webmaster128]

Okay great. So to rephrase for the record: the issue arises with off-chain signing (through ADR-36 as well as CIP-X)

1. for single signer, because the signing pubkey needs to be known in advance (address or undefined signer is not enough);
2. for multiple signers, because you cannot reuse a single sign message but need a separate one for each potential signer

None of those issues come up in transaction signing really, because for 1. a transaction inherently has a list of required signers and 2. there is a separate sign doc generated on demand anyways.

To solve those, I don't think we should touch how transaction signing works. Instead, better give up the idea of using an cosmos-sdk/StdTx wrapper around arbitrary message signing and heavily simplify things as it is done in Ethereum or Solana.