<p>Each of the blockchain forks assumes itself to be the only valid blockchain. They do not change their behavior due to a competing chain. They will require checks and confirm transactions completely independently from each other. It is likely that the same transactions are confirmed in both competing chains, just in different order and perhaps also at different heights. If a chain reorganization happens, and some transactions were not confirmed in the new best chain yet, they are still in the pool of unconfirmed transactions for that chain.</p>

<p>So, if you actually switch from [m4] to [new], and a transaction was not confirmed in the [new] chain that had been confirmed in the chain containing [m4], yes of course it would be in pool of unconfirmed transactions for that chain.</p>

<p><code>isStandard()</code> is performed by every node when it learns about a transaction. Each miner decides whether to confirm transactions that don't pass <code>isStandard()</code> by themselves. It is irrelevant whether a competitor would include it or not for this process. If the forkchain is extended by a miner that doesn't confirm non-standard transactions, it will only be confirmed later when someone else chooses to do so.</p>

CC BY-SA 3.0
2015-09-17T09:01:18.703Z
What about transactions that was in block and skip isStandart check?
bitaps.com
CC BY-SA 3.0
2015-09-17T09:11:59.083Z
I've extended my answer to address that part of your question more explicitly. I hope that it is clear now.
Murch
CC BY-SA 3.0
2015-09-17T09:18:10.170Z
miner add nonstandard transaction X to block A, we have reveived this block and add to mainchain. After we receive blocks B, C  block A no longer in mainchain. We should add all transaction that not exist in mainchain back to txmempool, should we add transaction X to mempool? or we need reject this transaction?
bitaps.com
CC BY-SA 3.0
2015-09-17T09:25:07.567Z
Essentially, nodes treat all unconfirmed transactions just like any unconfirmed transaction they just learned about for the first time. Those nodes that relay non-standard transactions will relay it, just like last time they saw it. Those that reject non-standard transactions will not. Why should it be treated any different, just because some orphaned chain had previously confirmed it?
Murch
CC BY-SA 3.0
2015-09-17T08:56:04.333Z
2015-09-17T09:10:40.453Z
2015-09-17T09:10:40.453Z
Murch
<p>Blockchain</p>

<pre><code>[m1]-&gt; [m2] -&gt; [m3] -&gt; [m4]

         |  -&gt; [f1] -&gt; [f2] -&gt; [new]
</code></pre>

<ul>
<li>m - mainchain blocks</li>
<li>f - fork blocks</li>
<li>new - tip of the fork that is at greater height than the previous mainchain</li>
</ul>

<p>In this case we must switch from the mainchain to the fork, due to the height of forkchain being greater than the mainchain.</p>

<p>My question is about transactions in blocks [m3], [m4]. In the case a transaction was in [m3] but not included in either the blocks [f1],[f2]. Since that transaction is not confirmed in the new mainchain (the forkchain) after the switch, would this tx be available for miners again to include for next block? Would this transactions be returned to the rawmempool?</p>

<p>And what if this transaction was added without isStandard check (in case adding in block), should we process isStandard check for this transaction?</p>

CC BY-SA 3.0
2015-09-17T07:19:07.007Z
This question appears to be based on a misunderstanding of what sidechains are. Possibly, the author confuses it with blockchain forks, but it is hard to tell, because the text of the question is hard to follow. Please improve the phrasing of your question, correct spelling, and then flag for reopening.
Murch
CC BY-SA 3.0
2015-09-17T08:51:55.240Z
Much better, but sidechains are not the product of a blockchain fork: Sidechains are separate blockchains that are pegged to the Bitcoin chain.
Murch
CC BY-SA 3.0
2015-09-17T08:58:37.350Z
related: [Transaction fees when a block chain is discarded](http://bitcoin.stackexchange.com/q/22149/5406)
Murch
CC BY-SA 3.0
2015-09-17T09:02:33.100Z
what is the correct name of bitcoin chain fork?
bitaps.com
<transactions><non-standard-transaction><chain-reorganization>
What happens to non-standard transactions in the case of a blockchain reorg?
bitaps.com
# What happens to non-standard transactions in the case of a blockchain reorg?

(Asked by: username_0 on 2015-09-16)

Blockchain

```
[m1]-> [m2] -> [m3] -> [m4]

         |  -> [f1] -> [f2] -> [new]

```

* m - mainchain blocks
* f - fork blocks
* new - tip of the fork that is at greater height than the previous mainchain

In this case we must switch from the mainchain to the fork, due to the height of forkchain being greater than the mainchain.

My question is about transactions in blocks [m3], [m4]. In the case a transaction was in [m3] but not included in either the blocks [f1],[f2]. Since that transaction is not confirmed in the new mainchain (the forkchain) after the switch, would this tx be available for miners again to include for next block? Would this transactions be returned to the rawmempool?

And what if this transaction was added without isStandard check (in case adding in block), should we process isStandard check for this transaction?

**Tags:** transactions, non-standard-transaction, chain-reorganization

> **Comments:**
> **username_1**: This question appears to be based on a misunderstanding of what sidechains are. Possibly, the author confuses it with blockchain forks, but it is hard to tell, because the text of the question is hard to follow. Please improve the phrasing of your question, correct spelling, and then flag for reopening.  
> **username_1**: Much better, but sidechains are not the product of a blockchain fork: Sidechains are separate blockchains that are pegged to the Bitcoin chain.  
> **username_1**: related: [Transaction fees when a block chain is discarded](http://bitcoin.stackexchange.com/q/22149/5406)  
> **username_0**: what is the correct name of bitcoin chain fork?  

---

## 1 answers

### Answer by username_1 on 2015-09-17. Score: 2

Each of the blockchain forks assumes itself to be the only valid blockchain. They do not change their behavior due to a competing chain. They will require checks and confirm transactions completely independently from each other. It is likely that the same transactions are confirmed in both competing chains, just in different order and perhaps also at different heights. If a chain reorganization happens, and some transactions were not confirmed in the new best chain yet, they are still in the pool of unconfirmed transactions for that chain.

So, if you actually switch from [m4] to [new], and a transaction was not confirmed in the [new] chain that had been confirmed in the chain containing [m4], yes of course it would be in pool of unconfirmed transactions for that chain.

`isStandard()` is performed by every node when it learns about a transaction. Each miner decides whether to confirm transactions that don't pass `isStandard()` by themselves. It is irrelevant whether a competitor would include it or not for this process. If the forkchain is extended by a miner that doesn't confirm non-standard transactions, it will only be confirmed later when someone else chooses to do so.

> **Comments:**
> **username_0**: What about transactions that was in block and skip isStandart check?  
> **username_1**: I've extended my answer to address that part of your question more explicitly. I hope that it is clear now.  
> **username_0**: miner add nonstandard transaction X to block A, we have reveived this block and add to mainchain. After we receive blocks B, C  block A no longer in mainchain. We should add all transaction that not exist in mainchain back to txmempool, should we add transaction X to mempool? or we need reject this transaction?  
> **username_1**: Essentially, nodes treat all unconfirmed transactions just like any unconfirmed transaction they just learned about for the first time. Those nodes that relay non-standard transactions will relay it, just like last time they saw it. Those that reject non-standard transactions will not. Why should it be treated any different, just because some orphaned chain had previously confirmed it?  

---

