You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, when I click approve on the ledger, I get the console output below. It appears that the account sequence being sent is incorrect. It's always 88 and the account number is always 5. I've tested with different rpc endpoints so I think this is related to the upgrade of go-ledger. So now, I am able to sign, but the signature verification fails.
Conclusion: The chain-id is correct so account number and sequence must be incorrect. These appear to be generated by the ledger.
palomad tx bank send [from_key_or_address] [to_address] [amount] [flags] takes the following flags for account and sequence. -a, --account-number uint The account number of the signing account (offline mode only) -s, --sequence uint The sequence number of the signing account (offline mode only)
but these are offline mode only.
I was able to reproduce this error on both mac and linux laptops so it appears that MacOS is not the issue.
Found more details on the error: The node uses the public key of the sender account to verify the signature. When verification failed, the node responds to this error. So you can decode the signature to verify that signerInfos (X Y Z) and signedDoc in the signature must match with the info when you sign.
So now I suspect that the account number or the account sequence is not matching the public key information in the keys. I will try to reload the keys.
The text was updated successfully, but these errors were encountered:
# Background
This adds mutable BytesToSign to the skyway module, they get refreshed
after gas estimate is attached to the batch.
# Testing completed
- [x] test coverage exists or has been added/updated
- [ ] tested in a private testnet
# Breaking changes
- [x] I have checked my code for breaking changes
- [x] If there are breaking changes, there is a supporting migration.
# Background
This adds mutable BytesToSign to the skyway module, they get refreshed
after gas estimate is attached to the batch.
# Testing completed
- [x] test coverage exists or has been added/updated
- [ ] tested in a private testnet
# Breaking changes
- [x] I have checked my code for breaking changes
- [x] If there are breaking changes, there is a supporting migration.
Local build commands
Step 1:
$git tag v1.12.1
Step 2:
LEDGER_ENABLED=true make build
Step 3:
mv palomad /usr/local
Step 4:
palomad version
returns 1.12.1Step 5: command used:
palomad tx bank send paloma18xrvj2ffxygkmtqwf3tr6fjqk3w0dgg7m6ucwx paloma1dlwec08s93gykwflpsssuqj0ds03yfmahcjs4x 1000000ugrain --chain-id messenger --gas 3500000 --node https://paloma-rpc.acloud.pp.ua:443 --sign-mode "amino-json" --fees 1000ugrain -b sync
The ledger responds to sign the tx and review the details.
However, when I click approve on the ledger, I get the console output below. It appears that the account sequence being sent is incorrect. It's always 88 and the account number is always 5. I've tested with different rpc endpoints so I think this is related to the upgrade of go-ledger. So now, I am able to sign, but the signature verification fails.
Output of the error.
Conclusion: The chain-id is correct so account number and sequence must be incorrect. These appear to be generated by the ledger.
palomad tx bank send [from_key_or_address] [to_address] [amount] [flags]
takes the following flags for account and sequence.-a, --account-number uint The account number of the signing account (offline mode only)
-s, --sequence uint The sequence number of the signing account (offline mode only)
but these are offline mode only.
I was able to reproduce this error on both mac and linux laptops so it appears that MacOS is not the issue.
Found more details on the error:
The node uses the public key of the sender account to verify the signature. When verification failed, the node responds to this error. So you can decode the signature to verify that signerInfos (X Y Z) and signedDoc in the signature must match with the info when you sign.
So now I suspect that the account number or the account sequence is not matching the public key information in the keys. I will try to reload the keys.
The text was updated successfully, but these errors were encountered: