-
Notifications
You must be signed in to change notification settings - Fork 378
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
Fix underpriced transaction #2943
Fix underpriced transaction #2943
Conversation
The eth_getTransactoinCount RPC method does not include the nonce for transactions in the mempool. Because of this Raiden was inadvertently reuse the same nonce, leading to errors with transaction overwrites.
raiden/network/rpc/client.py
Outdated
return max(pending.keys()) + 1 | ||
|
||
# The first valid nonce is 0, therefore the count is already the next | ||
# avaiable nonce |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/avaiable/available
raiden/network/rpc/client.py
Outdated
"""Returns the next available nonce for `address`.""" | ||
|
||
# The nonces of the mempool transactions are considered used, and it's | ||
# assumed these transactions are different from the ones currenlty pending |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/currenlty/currently
This has to be tested with parity (alternative nextNone) |
raiden/network/rpc/client.py
Outdated
|
||
# The first valid nonce is 0, therefore the count is already the next | ||
# available nonce | ||
return web3.eth.getTransactionCount(to_checksum_address(address), 'latest') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
address
is already being checksummed when calling this function so calling it here on the address again is redundant.
I am thinking about the side effects of this solution.... so if we have a close channel transaction that's already in the pool and we send another one for the same channel (upon restart) with a new nonce, this means that the latter will fail as the channel is already closed (which will raise a Recoverable error). While a RecoverableError might not be a direct issue as it is expected, would you think this might have any unexpected side effects? |
@hackaugusto I checked and it seems the |
11c130d
to
6edbc27
Compare
6edbc27
to
a29f50b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Well, it's possible, but the alternative would to match the pending transaction to the transaction in the pool, and that is way more work (I'm not saying we should not do it, but this fix allows fast restarts now) |
This broke infura: See #2951 and messages on gitter. |
Using the txpool api to get the used nonces because getTransactionCount does not include the transactions from the pool.