I have read about Race attack, Finney attack where Merchants are expected to take precautions to wait for few block confirmations before delivering the goods. I was going through the validation sequence followed by nodes that update its copy of ledger such as following (from Ethereum white paper : https://github.com/ethereum/wiki/wiki/White-Paper)


  1. Check if the previous block referenced exists and is valid.

  2. Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future

  3. Check that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid.
  4. Check that the proof of work on the block is valid.
  5. Let S[0] be the state at the end of the previous block.
  6. Let TX be the block's transaction list, with n transactions. For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]). If any application returns an error, or if the total gas consumed in the block up until this point exceeds the GASLIMIT, return an error.
  7. Let S_FINAL be S[n], but adding the block reward paid to the miner. 8.Check if the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid.


I wonder how does above sequence protect from following attack:

  1. Miner creates a block with transaction 100, say block is 27000
  2. After few blocks are created, when miner gets chance to create a new block (elected), it reintroduces transaction 100 again, say block 27100

Say, there is good amount of Ether in the sender account. Would above attack allow receiver getting twice the amount from the sender.

Does validation include checking for duplicate transactions IDs across blocks from the root block? That seems like lot of work as time progresses.

I am sure I am missing something. How does blockchain and which validation point in above sequence protect from this.


1 Answer 1


Each account has a number known as the nonce. It starts at zero, and after every processed transaction, it is incremented.

Each transaction also has a nonce. For a transaction to be processed, the account must have exactly the same nonce of the transaction. Not only does this force all transactions to occur in the order sent, but it also prevents a duplicate transaction. If a miner tried to run a transaction again, the block would be invalid, because the nonces would not match.

However, if there are multiple blockchains in play, this protection isn't as strong. An attacker could replay a transaction that occurred on one blockchain on another, since the nonce on the other blockchain would not have been incremented. This was eventually fixed by EIP 155.

  • Thank you so much for the answer. Does it mean that one can't have multiple transactions pending at a time? That is, if T1, T2 are issued almost at the same time, nonce in EOA would be updated beyond to represent T2. When the block with T1 is being committed, the nonce in the EOA does not match. So, is it fair to say that new transaction can't be issued by EOAs until previous transaction is confirmed? Or is it that there is storage for multiple nonces in the account to allow confirmation of multiple transactions?
    – Srini
    Commented Mar 6, 2017 at 16:27
  • Nodes can, and will, receive and relay transactions out of order. However, a node can only mine transactions in order. The others will remain in the transaction pool until the nonce is correct. Commented Mar 6, 2017 at 21:57

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.