<p>The client will import all the lost transactions into its pool of transactions it's trying to commit. Miners will include those transactions into blocks mined for the new chain, if they're not already in it.</p>

<p>Since a miner won't keep a conflicting transaction in memory anyway, it's not possible for the client to cause a conflict by accepting the transactions in the blocks that are undone. Miners should immediately accept all transactions that meet its transaction fee policy and fit as many of them as they can, in priority/dependency order, into blocks they mine.</p>

<p>Of course, coinbase transactions (the payment for mining a block) are forever lost. This is the primary reason that many more confirmations are typically required before coins from these transactions can be spent.</p>

CC BY-SA 3.0
2013-10-16T23:48:30.760Z
Does this mean that after the March 2013 fork was resolved, 31 blocks of orphaned transactions got sucked over into the newly validated highest chain? Is there a block that contains some huge number of transactions that got swept up from the orphaned chain?
pinhead
CC BY-SA 3.0
2011-09-15T06:15:42.657Z
2011-09-15T06:22:21.553Z
2011-09-15T06:22:21.553Z
David Schwartz
<p>It sounds like transactions in discarded blocks are propagated back to the network to be included in the next block to be generated, is that the case?  If so, is that triggered in the client when it discards a fork and accepts the longer chain?</p>

<p>I see some info and <a href="https://bitcointalk.org/index.php?topic=1994.0" rel="noreferrer">discussion</a> on this in the protocol and forums, but it's not entirely clear, and sounds like the heuristic is somewhat complex and non-deterministic (eg, some transactions can just be lost).</p>

<transactions><blockchain><protocol><script><blockchain-fork>
How are transactions in discarded forks merged back into the blockchain?
bgibson
# How are transactions in discarded forks merged back into the blockchain?

(Asked by: username_0 on 2011-09-15)

It sounds like transactions in discarded blocks are propagated back to the network to be included in the next block to be generated, is that the case? If so, is that triggered in the client when it discards a fork and accepts the longer chain?

I see some info and [discussion](https://bitcointalk.org/index.php?topic=1994.0) on this in the protocol and forums, but it's not entirely clear, and sounds like the heuristic is somewhat complex and non-deterministic (eg, some transactions can just be lost).

**Tags:** transactions, blockchain, protocol, script, blockchain-fork


---

## 1 answers

### Answer by username_1 on 2011-09-15. Score: 4 | Accepted answer

The client will import all the lost transactions into its pool of transactions it's trying to commit. Miners will include those transactions into blocks mined for the new chain, if they're not already in it.

Since a miner won't keep a conflicting transaction in memory anyway, it's not possible for the client to cause a conflict by accepting the transactions in the blocks that are undone. Miners should immediately accept all transactions that meet its transaction fee policy and fit as many of them as they can, in priority/dependency order, into blocks they mine.

Of course, coinbase transactions (the payment for mining a block) are forever lost. This is the primary reason that many more confirmations are typically required before coins from these transactions can be spent.

> **Comments:**
> **username_2**: Does this mean that after the March 2013 fork was resolved, 31 blocks of orphaned transactions got sucked over into the newly validated highest chain? Is there a block that contains some huge number of transactions that got swept up from the orphaned chain?  

---

