<p>Firstly, there is not only a single mempool, every node maintains its own mempool based on what transactions and blocks it has seen. Since these mempools will generally match pretty well, this fact is sometimes abbreviated by talking about "the mempool" and meaning the general body of unconfirmed transactions most nodes are aware of. If we were able to guarantee that everyone had the same mempool, we wouldn't need a blockchain. The main purpose of the blockchain is to give a decision between different versions of the mempool.</p>

<p>Secondly, from the perspective of each chain tip, the other chain tip is invalid and is treated as if it doesn't exist. Adding the observation that each node has its own mempool and assuming that the network is well-connected, you can find out the state of each node in regard to the chain tip they follow by acting as if the other chain doesn't exist.</p>

<p><a href="https://i.sstatic.net/qkaKL.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/qkaKL.png" alt="enter image description here"></a></p>

<p>Regarding your image: </p>

<ul>
<li>A node whose chain tip is C has TX10 in the mempool while TX3 and TX4 are confirmed.</li>
<li>A node whose chain tip is D considers TX4 and TX10 to be confirmed and has TX3 in the mempool.</li>
</ul>

<p>When block G is discovered, all nodes will reorganize to the lower chain tip DFG. At that point they will roll back to B, add TX14, TX15, TX3, and TX4 to their mempool, then apply block D, removing TX4 and TX10 from the mempool, apply block F, removing TX9 and TX15 from the mempool, and then applying block G, removing TX21 and TX20 from the mempool. TX3 remains in the mempool, because it is not confirmed in the lower chain yet.</p>

CC BY-SA 3.0
2017-09-18T08:08:01.700Z
Wow,that was one really great explanation! Thank you!
Sivich
CC BY-SA 3.0
2017-09-13T14:32:52.790Z
2017-09-13T14:32:52.790Z
Murch
<p>Tx message Rule# 8: <a href="https://en.bitcoin.it/wiki/Protocol_rules" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Protocol_rules</a>
Reject if we already have matching tx in the pool, or in a block in the main branch.</p>

CC BY-SA 3.0
2017-09-07T11:58:02.263Z
Thanks for the answer! So if I understand it correctly the rejected blocks(and all the transactions in that block) are going back to the mempool. Then, if someone trying to include the transaction that is already in the main branche(accepted branche) that transaction will be rejected? Is that correct? What is going to happend to rejected transaction(it will be just deleted from mempool)?
Sivich
CC BY-SA 3.0
2017-09-07T14:31:52.210Z
1)Yes, if someone tries to spend any transaction from main chain, it would be rejected. That's what double spending is.
If a block is rejected, (i am assuming it is rejected according to the block protocols attached above, and you are not referring to side chain), transactions will stay in mem pool, they would never get added to the blockchain.
2) If transaction was invalid acc. to protocols, it will never make to pool.
I hope you get that, everyone is maintaining their own chains and list of transactions. It is not shared and could be asynchronous wrt other nodes at a given period of time
Piyush Chittara
CC BY-SA 3.0
2017-09-07T11:46:16.240Z
2017-09-07T11:46:16.240Z
Piyush Chittara
<p>I have been reading about blockchain forks and the longest chain situations and I cannot really understand what is going to happend in the situation when the transacton were included in both accepted AND rejected blocks?
If transactions in rejected block are going back to the mempool, does it means that there will be blocks with duplicated transactions?
I have drawed something out for better understanding of this:
<a href="https://i.sstatic.net/7cAaM.jpg" rel="nofollow noreferrer">https://i.sstatic.net/7cAaM.jpg</a>
I guess I`m missing something fundamental here.
Thanks in advance!</p>

<blockchain-fork><mempool><chain-reorganization>
What going to happend with transactions that is in both rejectend AND accepted chains?
Sivich
# What going to happend with transactions that is in both rejectend AND accepted chains?

(Asked by: username_0 on 2017-09-07)

I have been reading about blockchain forks and the longest chain situations and I cannot really understand what is going to happend in the situation when the transacton were included in both accepted AND rejected blocks?
If transactions in rejected block are going back to the mempool, does it means that there will be blocks with duplicated transactions?
I have drawed something out for better understanding of this:
<https://i.sstatic.net/7cAaM.jpg>
I guess I`m missing something fundamental here.
Thanks in advance!

**Tags:** blockchain-fork, mempool, chain-reorganization


---

## 2 answers

### Answer by username_1 on 2017-09-13. Score: 0 | Accepted answer

Firstly, there is not only a single mempool, every node maintains its own mempool based on what transactions and blocks it has seen. Since these mempools will generally match pretty well, this fact is sometimes abbreviated by talking about "the mempool" and meaning the general body of unconfirmed transactions most nodes are aware of. If we were able to guarantee that everyone had the same mempool, we wouldn't need a blockchain. The main purpose of the blockchain is to give a decision between different versions of the mempool.

Secondly, from the perspective of each chain tip, the other chain tip is invalid and is treated as if it doesn't exist. Adding the observation that each node has its own mempool and assuming that the network is well-connected, you can find out the state of each node in regard to the chain tip they follow by acting as if the other chain doesn't exist.

[![enter image description here](https://i.sstatic.net/qkaKL.png)](https://i.sstatic.net/qkaKL.png)

Regarding your image:

* A node whose chain tip is C has TX10 in the mempool while TX3 and TX4 are confirmed.
* A node whose chain tip is D considers TX4 and TX10 to be confirmed and has TX3 in the mempool.

When block G is discovered, all nodes will reorganize to the lower chain tip DFG. At that point they will roll back to B, add TX14, TX15, TX3, and TX4 to their mempool, then apply block D, removing TX4 and TX10 from the mempool, apply block F, removing TX9 and TX15 from the mempool, and then applying block G, removing TX21 and TX20 from the mempool. TX3 remains in the mempool, because it is not confirmed in the lower chain yet.

> **Comments:**
> **username_0**: Wow,that was one really great explanation! Thank you!  

---

### Answer by username_2 on 2017-09-07. Score: 0

Tx message Rule# 8: <https://en.bitcoin.it/wiki/Protocol_rules>
Reject if we already have matching tx in the pool, or in a block in the main branch.

> **Comments:**
> **username_0**: Thanks for the answer! So if I understand it correctly the rejected blocks(and all the transactions in that block) are going back to the mempool. Then, if someone trying to include the transaction that is already in the main branche(accepted branche) that transaction will be rejected? Is that correct? What is going to happend to rejected transaction(it will be just deleted from mempool)?  
> **username_2**: 1)Yes, if someone tries to spend any transaction from main chain, it would be rejected. That's what double spending is. If a block is rejected, (i am assuming it is rejected according to the block protocols attached above, and you are not referring to side chain), transactions will stay in mem pool, they would never get added to the blockchain. 2) If transaction was invalid acc. to protocols, it will never make to pool. I hope you get that, everyone is maintaining their own chains and list of transactions. It is not shared and could be asynchronous wrt other nodes at a given period of time  

---

