I am afraid of a possible replay attack when paying to a smart contract. Given these 3 assumptions

  1. An action gas cost may change according to the state of the blockchain (even if its the same action).

  2. If I payed to some smart contract (that I didnt created myself), and it run out of gas, I need to retransmit the same funds in a new transaction, with a higher gas price and the next nonce.

  3. If an action runs out of gas, it may be re-added to the blockchain and run without running out of gas

Assuming all of those actions, a reply attack is possible! (I understand that waiting for many blocks to avoid forks is a possibility... but it just sounds like a very partials solution)

Any insights?


Pseudo code of the problem

  1. tx1={from=me, to=contract, nonce=10, gas limit=100'000,...}

  2. Send (tx1)

  3. tx1 run out of gas (needed 100'001 gas..)

  4. tx2={from=me, to=contract, nonce=11, gas limit=200'000,...}

  5. Send (tx2)

  6. Blockchain fork occurred, and tx1 revaluated and tx 1 now approved

  7. tx2 approved too

Doable spend occurred

  • Please consider illustrating your concerns in a coding example. Mar 4, 2019 at 19:45
  • It's not really a coding problem, but more a teortical problem. Mar 4, 2019 at 19:47
  • Well, a reply attack sounds to me like something that is based on coding in one way or another. You should by the least consider explaining what exactly reply attack means (and/or provide a link to an official document which does that). Mar 4, 2019 at 19:53
  • Added an edit in the question Mar 4, 2019 at 20:48

1 Answer 1


You might be underestimating the difficulty here:

If an action runs out of gas, it may be re-added to the blockchain and run without running out of gas

Transactions from the same account are guaranteed to be mined in nonce order. Appending another one after the failed txn can't be the same nonce. Changing the nonce or increasing the gasPrice in the previously failed transaction would be a different transaction so it would invalidate the signature.

So, no. It may not be re-added tot he chain as suggested.

If it were possible for an attacker to use a copy of a signed transaction to send them again it would happen all the time because full nodes have copies of every transaction.

You may be thinking about chain reorganization issues.

For example, it IS possible to recall a transaction, with some luck, if it's not already mined. You send another transaction with a higher gasPrice and the same nonce and you hope it gets mined first. A miner considering both candidates will probably select the one with the higher gasPrice. Logically, that's sort of like an overwrite that pre-empts the one you want to recall. Importantly, it only works if the original transaction was pending. Once the original transaction is included in the chain no one will accept its demotion/replacement even if it failed.

Hope it helps.

  • Hi Rob, thank you for your comment. I didn't mean to send the same transaction again. I meant that after I see the transaction failed, I will send the transaction again with DIFFERENT NONCE. I.e a new transaction transfering the same funds. And then after a local fork, both transactions might be added together and the funds will be re-transfered Mar 4, 2019 at 20:41
  • Then you are thinking about chain reorganization and you have discovered why it's important to wait for confirmations until you're satisfied that won't be a problem. If Txn A and B are independent, that's one thing. If B depends on the outcome of A, then you better wait until you're sure about what happened to A. There's no bad actor who is attacking. Mar 4, 2019 at 21:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.