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)
Check if the previous block referenced exists and is valid.
Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future
- Check that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid.
- Check that the proof of work on the block is valid.
- Let S be the state at the end of the previous block.
- 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.
- 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:
- Miner creates a block with transaction 100, say block is 27000
- 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.