Let's say I send 10BTC to Bob. I have 30 BTC. So after transferring, I should have 20.

Now, after I transfered 10, transaction can be copied and broadcasted to the network again by Bob(he might have somehow get it from pool or something). Which means that replay attack has just taken place on the same chain(I know that replay attacks happen mostly when there's a hard fork, but in this case, I am talking about the same chain replay attacks).

Ethereum solves it by having nonce field in each account.

Question 1) How does bitcoin solve this case without SegWit ?

Question 2) how does bitcoin solve this case with SegWit ?

Question 3) If the replay attack happens for hard fork case, did bitcoin implement the solution or not ? I know that it was BTC cash that created a solution and btc said they wouldn't do it, but i am curious what's the state on this now ?

1 Answer 1


In all cases what you are describing is a double-spend. Bitcoin uses a UTXO model (not an account based model) which means that there is a set of coins also known as the UTXO set or Unspent Transaction Output set.

Transactions destroy coins and create new coins.

A new transaction attempting to spend a coin that has been destroyed is simply invalid.

Your concept of you and Bob "having x BTC" as a balance is incorrect for Bitcoin. What you have is a set of coins (a subset of the network-wide UTXO set) that you can destroy with a transaction by solving an output script. When you send 10 BTC to Bob what's really happening is you are taking one of your coins (lets say a coin with a 20 BTC value) and destroying it. Your transaction replaces it with two new coins, both for 10 BTC -- one secured by Bob's public key and the other secured by your own public key (this is your "change").

Once that transaction is confirmed the original 20 BTC coin no longer exists. Sending the same transaction a second time would be invalid because it attempts to destroy coins that don't exist.

  • 2
    Yup. You could even create 2 TXs that double spend and send them to different peers. Different nodes would have conflicting TXs but only one would be mined. When nodes with the "wrong" TX see the block that confirms the "right" TX they evict the "wrong" TX from their mempools.
    – pinhead
    Commented Oct 12, 2020 at 15:44
  • 2
    This is a deeper implementation detail that I'm not entirely sure about. I think the UTXO set is technically what is confirmed in blocks. Coins that are spent in the mempool only (unconfirmed) are tracked in memory in a different data structure, but either way the node considers a coin destroyed as part of the mempool-insertion process.
    – pinhead
    Commented Oct 12, 2020 at 15:51
  • 2
    Well confirmed TXs don't go to the mempool because confirmed means it is in a block so if anything it is removed from the mempool. But absolutely only valid transactions are inserted into the mempool. Like I said, the node assumes that every TX in the mempool can be confirmed in the next block (this includes rules about relative locktime etc)
    – pinhead
    Commented Oct 12, 2020 at 15:54
  • 2
    The on-disk UTXO set only contains the effect of confirmed transactions. However, new individual transactions in the mempool are verified against the UTXO set + the changes to it by other mempool transactions. The result is that always, all mempoll transactions are consistent with the blockchain and eachother. Transaction validity does not depend on any state other than the UTXO set, so once validated they are known to be forever valid (unless double spent). I don't know the details about Ethereum, but I believe it has much weaker guarantees about mempool tx validity. Commented Oct 12, 2020 at 16:43
  • 3
    Ethereum is off-topic for this forum and I can't help you.
    – pinhead
    Commented Oct 12, 2020 at 17:44

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.