Add: if only 1 key is available it will simply sign the transaction without talking to the blockchain
Existing behavior will be kept when the user provides more than one private key to eosjs:
The default sign provider is designed to interact with the available public keys (maybe just one), the transaction and blockchain to figure out the minimum set of signing keys. Providing a custom signProvider skips that process.
Skipping this process when eosjs has 1 key changes the error message if the wrong key is used to sign a transaction. It will of course reject, just a bit later from eos. This overall improves efficiency and removes complexity, most transactions will pass.
Add: if only 1 key is available it will simply sign the transaction without talking to the blockchain
Existing behavior will be kept when the user provides more than one private key to eosjs:
Skipping this process when eosjs has 1 key changes the error message if the wrong key is used to sign a transaction. It will of course reject, just a bit later from eos. This overall improves efficiency and removes complexity, most transactions will pass.
I propose this as a patch..