<p>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.</p>
<p>Transactions destroy coins and create new coins.</p>
<p>A new transaction attempting to spend a coin that has been destroyed is simply invalid.</p>
<p>Your concept of you and Bob &quot;having x BTC&quot; 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 &quot;change&quot;).</p>
<p>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.</p>

CC BY-SA 4.0
2020-10-12T15:40:54.380Z
So by your answer, we can sum up the following.  i sent 2 transactiosn(they are the same), node takes one of them from pool, updates UTXO database(removes inputs from utxo), then takes the second transaction from pool, but since it can't find its inputs in UTXo, it's invalid.  correct ? and when does node check all this - before it puts a transaction into pool or after it grabs a transaction from pool to put it in a new block ?
Nika Kurashvili
CC BY-SA 4.0
2020-10-12T15:42:31.537Z
When a TX is received from a peer it is checked against all consensus rules and policy settings. If it fails any of those, the TX is not added to the mempool. The mining code assumes that all TXs in the mempool are valid and can be confirmed in the next block.
pinhead
CC BY-SA 4.0
2020-10-12T15:43:25.127Z
so, If I make 2 same transactions at the same time, only one of them would end up in mempool ?
Nika Kurashvili
CC BY-SA 4.0
2020-10-12T15:44:40.157Z
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
CC BY-SA 4.0
2020-10-12T15:46:33.663Z
Got it. one more question. when do nodes update UTXO database ? (removing outputs from it) - before a transaction is added to mempool or after node grabs it from mempool? from your previous answer, i think the answer is before it's added to mempool, but in this case what might happen is utxo might be updated, but mempool's transaction might never reach to blockchain for some reason(hypothetically).
Nika Kurashvili
CC BY-SA 4.0
2020-10-12T15:51:42.540Z
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
CC BY-SA 4.0
2020-10-12T15:53:26.853Z
But we are sure that only validated transactions go to mempool, right ?
Nika Kurashvili
CC BY-SA 4.0
2020-10-12T15:54:54.810Z
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
CC BY-SA 4.0
2020-10-12T16:14:29.060Z
Does the ethereum do the same ? meaning that it only puts validated transactions in mempool ? if yes, I've read the following: 1) The transaction is then broadcast to the network and included in a pool with lots of other transactions. 2) A miner must pick your transaction and include it in a block in order to verify the transaction and consider it "successful".
Nika Kurashvili
CC BY-SA 4.0
2020-10-12T16:19:48.237Z
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/114021/discussion-between-nika-kurashvili-and-pinhead).
Nika Kurashvili
CC BY-SA 4.0
2020-10-12T16:43:33.323Z
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.
Pieter Wuille
CC BY-SA 4.0
2020-10-12T16:59:07.160Z
Thanks Pieter, I have to ask this one more time. If I make a transaction, does node validate it(if signature is correct, if i have a balance) before putting it in mempool or after it grabs it from mempool ?
Nika Kurashvili
CC BY-SA 4.0
2020-10-12T17:23:04.363Z
Nika, only valid transactions are inserted into the mempool. The function AcceptToMemoryPool() will either succeed or fail. Remember though there are no "balances" in bitcoin.
pinhead
CC BY-SA 4.0
2020-10-12T17:33:25.483Z
@pinhead as far as i can. see in that function, only validated(by the signature) transactions will end up in mempool. i think balance validation starts after grabbing transactions from mempool and not before putting them in mempool. agree ?
Nika Kurashvili
CC BY-SA 4.0
2020-10-12T17:36:41.110Z
THERE IS NO BALANCE IN BITCOIN. Just coins. Transactions destroy coins and create coins. A TX comes in from a peer and it is tested for validity (do the input coins exist, are the signatures valid, etc) and if TRUE the TX is added to the mempool. What do you mean by "grabbing transactions from the mempool" ?
pinhead
CC BY-SA 4.0
2020-10-12T17:40:47.477Z
i make a transaction,my node validates the signature,if true, adds it to mempool.now it's time to create a new block.node grabs all transactions from mempool and checks if each transaction is valid(if their inputs are really in UTXO set)and all that match this criteria,end up in blockchain. This is one way to do it.Another is,before a transaction is put into mempool, node also checks if the transaction's inputs are valid from utxo set and if so, adds it to mempool after that.I am asking which one is right?because in ethereum, as I copied,all transactions without validation are added to mempool
Nika Kurashvili
CC BY-SA 4.0
2020-10-12T17:42:09.883Z
As I have mentioned several times, the mempool only contains valid transactions. The miner can assume everything in the mempool can be added to a block without having to re-check anything.
pinhead
CC BY-SA 4.0
2020-10-12T17:43:35.487Z
@pinhead got it. Do you have any information about ethereum on this matter ? from the official docs, it looks like all the transactions are added first into mempool without validating
Nika Kurashvili
CC BY-SA 4.0
2020-10-12T17:44:10.770Z
Ethereum is off-topic for this forum and I can't help you.
pinhead
CC BY-SA 4.0
2020-10-12T15:27:32.490Z
2020-10-12T15:27:32.490Z
pinhead
<p>Let's say I send 10BTC to Bob. I have 30 BTC. So after transferring, I should have 20.</p>
<p>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).</p>
<p>Ethereum solves it by having <code>nonce</code> field in each account.</p>
<p><strong>Question 1)</strong> How does bitcoin solve this case without SegWit ?</p>
<p><strong>Question 2)</strong> how does bitcoin solve this case with SegWit ?</p>
<p><strong>Question 3)</strong> 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 ?</p>

<doublespend><transaction-verification><utxo><replay-attack>
how does bitcoin solve the same chain replay attack?
Nika Kurashvili
# how does bitcoin solve the same chain replay attack?

(Asked by: username_0 on 2020-10-12)

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 ?

**Tags:** doublespend, transaction-verification, utxo, replay-attack


---

## 1 answers

### Answer by username_1 on 2020-10-12. Score: 5 | Accepted answer

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.

> **Comments:**
> **username_0**: So by your answer, we can sum up the following.  i sent 2 transactiosn(they are the same), node takes one of them from pool, updates UTXO database(removes inputs from utxo), then takes the second transaction from pool, but since it can't find its inputs in UTXo, it's invalid.  correct ? and when does node check all this - before it puts a transaction into pool or after it grabs a transaction from pool to put it in a new block ?  
> **username_1**: When a TX is received from a peer it is checked against all consensus rules and policy settings. If it fails any of those, the TX is not added to the mempool. The mining code assumes that all TXs in the mempool are valid and can be confirmed in the next block.  
> **username_0**: so, If I make 2 same transactions at the same time, only one of them would end up in mempool ?  
> **username_1**: 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.  
> **username_0**: Got it. one more question. when do nodes update UTXO database ? (removing outputs from it) - before a transaction is added to mempool or after node grabs it from mempool? from your previous answer, i think the answer is before it's added to mempool, but in this case what might happen is utxo might be updated, but mempool's transaction might never reach to blockchain for some reason(hypothetically).  
> **username_1**: 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.  
> **username_0**: But we are sure that only validated transactions go to mempool, right ?  
> **username_1**: 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)  
> **username_0**: Does the ethereum do the same ? meaning that it only puts validated transactions in mempool ? if yes, I've read the following: 1) The transaction is then broadcast to the network and included in a pool with lots of other transactions. 2) A miner must pick your transaction and include it in a block in order to verify the transaction and consider it "successful".  
> **username_0**: Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/114021/discussion-between-username_0-and-username_1).  
> **username_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.  
> **username_0**: Thanks username_2, I have to ask this one more time. If I make a transaction, does node validate it(if signature is correct, if i have a balance) before putting it in mempool or after it grabs it from mempool ?  
> **username_1**: username_0, only valid transactions are inserted into the mempool. The function AcceptToMemoryPool() will either succeed or fail. Remember though there are no "balances" in bitcoin.  
> **username_0**: @username_1 as far as i can. see in that function, only validated(by the signature) transactions will end up in mempool. i think balance validation starts after grabbing transactions from mempool and not before putting them in mempool. agree ?  
> **username_1**: THERE IS NO BALANCE IN BITCOIN. Just coins. Transactions destroy coins and create coins. A TX comes in from a peer and it is tested for validity (do the input coins exist, are the signatures valid, etc) and if TRUE the TX is added to the mempool. What do you mean by "grabbing transactions from the mempool" ?  
> **username_0**: i make a transaction,my node validates the signature,if true, adds it to mempool.now it's time to create a new block.node grabs all transactions from mempool and checks if each transaction is valid(if their inputs are really in UTXO set)and all that match this criteria,end up in blockchain. This is one way to do it.Another is,before a transaction is put into mempool, node also checks if the transaction's inputs are valid from utxo set and if so, adds it to mempool after that.I am asking which one is right?because in ethereum, as I copied,all transactions without validation are added to mempool  
> **username_1**: As I have mentioned several times, the mempool only contains valid transactions. The miner can assume everything in the mempool can be added to a block without having to re-check anything.  
> **username_0**: @username_1 got it. Do you have any information about ethereum on this matter ? from the official docs, it looks like all the transactions are added first into mempool without validating  
> **username_1**: Ethereum is off-topic for this forum and I can't help you.  

---

