Timeline for What are the ways in which a transaction can fail and what happens when it fails?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 20, 2018 at 17:22 | comment | added | Kannan Ravindran | The bytecode is only processed once. When miner A executes the code and mines the transaction, subsequent miners verify and signs the transaction rather than executing again and again. Also, the transaction can end up with revert or assert. Revert uses gas until the error occurs and returns the remaining gas. Assert consumes the remaining gas. | |
| May 16, 2018 at 12:06 | vote | accept | rosul | ||
| Nov 28, 2017 at 8:12 | comment | added | rosul | Lets say I emitted a function call/message transaction to the network and lets say that the call will throw; after a while most of the network knows about it, it becomes part of the pending tx pool and soon miner A mines it. But when A was executing the bytecode the call throws and the state is reversed. How does the network know that the transaction was processed so that it doesnt get stuck in the the pend tx pool and the other nodes dont process it again and again? Is it just that the transaction will only transfer the gas cost to the miner and thats it? | |
| Nov 28, 2017 at 8:01 | comment | added | rosul | I am interested more specifically in what happens with the transaction once it fails, especially for external calls to contrats. | |
| Nov 27, 2017 at 17:16 | history | edited | Kannan Ravindran | CC BY-SA 3.0 |
adding links for reference
|
| Nov 27, 2017 at 17:09 | history | answered | Kannan Ravindran | CC BY-SA 3.0 |