<p>On nodes that had accepted block100: when they disconnect it to reorg they will remember the transactions in it and attempt to reinsert into the mempool any that fell out once they finish the reorg. If they're still valid, they'll be added and queued for mining in a future block.</p>

<p>On nodes that initially accepted block110: the transactions that were still valid after accepting the block will remain in the mempool queued for mining in a future block.</p>

<p>Transactions which were invalidated by other transactions included in block110 are forgotten by nodes.</p>

CC BY-SA 4.0
2019-01-09T21:08:42.400Z
2019-01-09T21:08:42.400Z
G. Maxwell
<p>I assume you mean <code>t100i</code> is confirmed in <code>block100</code>, and not in <code>block110</code>.</p>

<p><code>t100i</code> remains in the branch which has <code>block100</code> as it's tip. However, since the branch which includes <code>block110</code> has a tip with more accumulated POW, it is the one that represents the current valid ordering of transactions (strong chain).</p>

<p>For the node following/validating the strong chain, <code>t100i</code> may or may not be an valid transaction:</p>

<ul>
<li>If <code>t100i</code> is not mined in block <code>block110</code>, and there was no other confirmed transaction in the strong chain which spent the UTXO's of <code>t100i</code>, <code>t100i</code> is still a valid transaction, and can
be accepted to the mempool.</li>
<li>If another confirmed transaction in the strong chain spends the same UTXO's as <code>t100i</code> first, <code>t100i</code> becomes invalid, as it double-spends the same previous outputs.</li>
</ul>

CC BY-SA 4.0
2019-01-09T14:44:08.730Z
2019-01-09T14:44:08.730Z
James C.
<p>Let:</p>

<p>a) the vector triplet <strong>&lt;x,y,z></strong> refer <strong>&lt;height, index, parent_index></strong></p>

<p>b) blocks, <strong>block100</strong>, <strong>block110</strong> (of height 1) are mined together and they both refer previous block <strong>block00[null]</strong> (of height 0).</p>

<p>Block, <strong>block110</strong> (of height 1) gets a child block and its branch grows but </p>

<p>block <strong>block100</strong> doesn't get any child block till then and became leaf/fork.</p>

<p>Please advise what happens to the ith transaction <strong>t100i</strong> of block, <strong>block100</strong> that is not included in the branching block, <strong>block110</strong>.</p>

<bitcoin-core><blockchain><blockchain-fork>
What happens to the transactions included in the forks?
AVA
# What happens to the transactions included in the forks?

(Asked by: username_0 on 2019-01-09)

Let:

a) the vector triplet **<x,y,z>** refer **<height, index, parent\_index>**

b) blocks, **block100**, **block110** (of height 1) are mined together and they both refer previous block **block00[null]** (of height 0).

Block, **block110** (of height 1) gets a child block and its branch grows but

block **block100** doesn't get any child block till then and became leaf/fork.

Please advise what happens to the ith transaction **t100i** of block, **block100** that is not included in the branching block, **block110**.

**Tags:** bitcoin-core, blockchain, blockchain-fork


---

## 2 answers

### Answer by username_1 on 2019-01-09. Score: 1

On nodes that had accepted block100: when they disconnect it to reorg they will remember the transactions in it and attempt to reinsert into the mempool any that fell out once they finish the reorg. If they're still valid, they'll be added and queued for mining in a future block.

On nodes that initially accepted block110: the transactions that were still valid after accepting the block will remain in the mempool queued for mining in a future block.

Transactions which were invalidated by other transactions included in block110 are forgotten by nodes.


---

### Answer by username_2 on 2019-01-09. Score: 0

I assume you mean `t100i` is confirmed in `block100`, and not in `block110`.

`t100i` remains in the branch which has `block100` as it's tip. However, since the branch which includes `block110` has a tip with more accumulated POW, it is the one that represents the current valid ordering of transactions (strong chain).

For the node following/validating the strong chain, `t100i` may or may not be an valid transaction:

* If `t100i` is not mined in block `block110`, and there was no other confirmed transaction in the strong chain which spent the UTXO's of `t100i`, `t100i` is still a valid transaction, and can
  be accepted to the mempool.
* If another confirmed transaction in the strong chain spends the same UTXO's as `t100i` first, `t100i` becomes invalid, as it double-spends the same previous outputs.


---

