-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specify ambiguity in eth_getTransactionCount #188
Comments
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
The JSON-RPC method eth_getTransactionCount, according to the specification, returns the number of transactions sent from an account. All well and good. In the majority of situations, this is the same as returning the nonce.
However, if the nonce does not start at 0, this leads to inconsistent behavior across clients.
a) In geth and Parity, getTransactionCount returns the nonce.
b) In pyethapp, getTransactionCount actually calculates the number of transactions, and returns that.
While this is irrelevant for the mainnet, it does matter for a testnet with multiple clients, or if an alternate nonce scheme was implemented. As written, it seems it should be pyethapp's behavior that is correct, but de facto it works as geth and Parity implement it.
I see three options:
2a) And maybe change the name to getNonce, too.
References:
The pull request wherein I discovered this issue.
A short discussion in pyethapp's repo.
The text was updated successfully, but these errors were encountered: