Better error for failed signature verification

[jackzampolin]

This error can normally arises from an incorrect sequence number (trying to send another transaction too quickly) or chain_id

[faboweb]

Push

[alexanderbez]

What do we want here? Just to update the error message?

How about: signature verification failed; verify correct account sequence and chain-id.

[faboweb]

It would be cool if it would say if this is an error based on the wrong sequence or the wrong chain-id

[alexanderbez]

@faboweb this is not possible afaik. We construct bytes over which we expect the signer to sign and then call pubKey.VerifyBytes(signBytes, sig.Signature). We have no idea what the user/client provided.

[faboweb]

But you receive the whole message which holds not only the signature but the chain-id and the sequence number. Can't those be evaluated beforehand?

[alexanderbez]

But you receive the whole message which holds not only the signature but the chain-id and the sequence number. Can't those be evaluated beforehand?

Transactions do not contain the chain-id or anything related to the account. This was removed some time ago. It's not going to be added back as it's redundant and would bloat state too much.

[faboweb]

Ahh you're right, I still had the old format in my memory.
Then signature verification failed; verify correct account sequence and chain-id sounds good.

Who is evaluating the tx? The full node which is on a certain chain-id? So if I know the full nodes chain-id I could probably exclude the chain-id as a source of error.

Spinning this further: How about sending the chain-id and sequence together with the tx (even though they are not included in the tx that ends up in the state) in the broadcast request. The full node could then evaluate these optional arguments and return a proper error.

[alexanderbez]

Who is evaluating the tx? The full node which is on a certain chain-id? So if I know the full nodes chain-id I could probably exclude the chain-id as a source of error.

You'd be surprised haha. But with the advent of more mature wallets, I agree this should be less of a common problem.

Spinning this further: How about sending the chain-id and sequence together with the tx (even though they are not included in the tx that ends up in the state) in the broadcast request. The full node could then evaluate these optional arguments and return a proper error.

Hmmm, I suppose this would be nice, but I don't know of anyway of doing this because the ante-handler receives a StdTx. There is no notion of optional arguments per say...at least that are not persisted.

The best I think we can do here is improve the error message.

[faboweb]

I thought about a check in the handler of the broadcast endpoint. Would that be a possibility?

[valuead]

still persist
Run 2 commands one after another in bash file script and this is what you get. Will try to include wait for a sec. ))

[alexanderbez]

Yes, indeed @valuead. What are you stating?

[valuead]

By adding 10 seconds between commands in my bash script error was gone or was occurring rarely so next command was bonding my tokens. (C) Maestro

[alexanderbez]

Yes, that is due to the fact of the CheckTx state not having the correct sequence. By waiting for the next block, you'll have the correct value.

[yzhanginwa]

Yes, that is due to the fact of the CheckTx state not having the correct sequence. By waiting for the next block, you'll have the correct value.

So each account/address can send 1 transaction the most in a block, or the 2nd transaction will get a duplicate sequence number. Is that what you mean?

[alexanderbez]

You should send 1 tx with multiple messages.