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
Sometimes a user has a series of transactions pending that they want to invalidate urgently and atomically.
Currently the best solution is to submit a replacement "zero value" tx for each of the pending txs, with an increase of gas, and hope that miners mine the cancellation transactions first.
This creates a lot of on-chain traffic just for batch cancellation, and can result in inconsistent results, where some dependent transactions are processed when earlier ones were successfully "cancelled".
One way this could be alleviated would be if transactions could have "nonce spans" that included a range of nonces from the current valid nonce to a future nonce, incrementing the account nonce by a user-specified amount, and invalidating any transactions with a nonce below the resulting nonce.
Thoughts? Other approaches?
The text was updated successfully, but these errors were encountered:
Approaching the issue in a very naive way. Can we enable the sender to submit a "cancellation" tx, where when broadcasted nodes would drop the previous transaction(s) when their first or last transaction bytes match.
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.
Sometimes a user has a series of transactions pending that they want to invalidate urgently and atomically.
Currently the best solution is to submit a replacement "zero value" tx for each of the pending txs, with an increase of gas, and hope that miners mine the cancellation transactions first.
This creates a lot of on-chain traffic just for batch cancellation, and can result in inconsistent results, where some dependent transactions are processed when earlier ones were successfully "cancelled".
One way this could be alleviated would be if transactions could have "nonce spans" that included a range of nonces from the current valid nonce to a future nonce, incrementing the account nonce by a user-specified amount, and invalidating any transactions with a nonce below the resulting nonce.
Thoughts? Other approaches?
The text was updated successfully, but these errors were encountered: