<p>Bitcoin Core includes <a href="https://github.com/bitcoin/bitcoin/search?utf8=%E2%9C%93&amp;q=undo" rel="nofollow">code</a> which rolls back a block from the chain when it is orphaned.  All transactions from that block are checked against the new best block chain to see if they've already been added to a block or if they spend the same input as a transaction already added to a block; if they aren't---meaning they're valid transactions on the new best block chain---they're re-added to the memory pool.</p>

<p>The re-added transactions will not be automatically rebroadcast like a newly-received transaction, but if a remote peer sends the <a href="https://en.bitcoin.it/wiki/Protocol_specification#mempool" rel="nofollow">mempool message</a> to the local peer, the local peer will tell the remote peer about the transaction (using a standard inventory).</p>

CC BY-SA 3.0
2014-11-14T06:14:42.320Z
2014-11-14T06:14:42.320Z
David A. Harding
<p>The sender and the receiver carry the burden of rebroadcasting the transaction: <a href="https://en.bitcoin.it/wiki/Network#Standard_relaying" rel="nofollow">https://en.bitcoin.it/wiki/Network#Standard_relaying</a></p>

<p>Usually, if a transaction is included in an orphan, it also was included in the sibling block of that orphan. This is because most miners have the same transaction selection policies and would also want to collect on the transaction fee(s).</p>

<p>If there are any issues, you can also MANUALLY rebroadcast via JSON-RPC or bitcoind or Bitcoin-qt debug console: <a href="https://en.bitcoin.it/wiki/Raw_Transactions#Re-broadcast_a_transaction" rel="nofollow">https://en.bitcoin.it/wiki/Raw_Transactions#Re-broadcast_a_transaction</a></p>

CC BY-SA 3.0
2014-08-15T18:07:10.593Z
2014-08-15T18:07:10.593Z
Mark
<p>Scenario:  </p>

<p>You are running a bitcoind node and listening to the incoming blocks/transactions.  You receive TX 1 which is put into your mempool.  Block A is mined, and includes TX 1, which is subsequently removed from your mempool.  Blocks B and C are mined, orphaning Block A.  Neither Block B, nor C include TX 1, so it is put back into the mempool to be included in a new Block</p>

<p>Question: </p>

<p>How exactly does the node find out that it needs to include TX1 in the mempool again?  Is TX 1 broadcast and received in the same way as when it was first broadcast to the node?  Or in other words, if I'm listening for receiving incoming blocks/transactions, will it be relayed to me a second time or does the client "know" just to put it back in the mempool?</p>

<p>Let me know if any of my understanding is incorrect or if you need any more clarification!</p>

<transactions><bitcoind><chain-reorganization><stale-block>
Transactions within orphaned blocks
HOWTOBITCOIN
# Transactions within orphaned blocks

(Asked by: username_0 on 2014-08-15)

Scenario:

You are running a bitcoind node and listening to the incoming blocks/transactions. You receive TX 1 which is put into your mempool. Block A is mined, and includes TX 1, which is subsequently removed from your mempool. Blocks B and C are mined, orphaning Block A. Neither Block B, nor C include TX 1, so it is put back into the mempool to be included in a new Block

Question:

How exactly does the node find out that it needs to include TX1 in the mempool again? Is TX 1 broadcast and received in the same way as when it was first broadcast to the node? Or in other words, if I'm listening for receiving incoming blocks/transactions, will it be relayed to me a second time or does the client "know" just to put it back in the mempool?

Let me know if any of my understanding is incorrect or if you need any more clarification!

**Tags:** transactions, bitcoind, chain-reorganization, stale-block


---

## 2 answers

### Answer by username_1 on 2014-11-14. Score: 3 | Accepted answer

Bitcoin Core includes [code](https://github.com/bitcoin/bitcoin/search?utf8=%E2%9C%93&q=undo) which rolls back a block from the chain when it is orphaned. All transactions from that block are checked against the new best block chain to see if they've already been added to a block or if they spend the same input as a transaction already added to a block; if they aren't---meaning they're valid transactions on the new best block chain---they're re-added to the memory pool.

The re-added transactions will not be automatically rebroadcast like a newly-received transaction, but if a remote peer sends the [mempool message](https://en.bitcoin.it/wiki/Protocol_specification#mempool) to the local peer, the local peer will tell the remote peer about the transaction (using a standard inventory).


---

### Answer by username_2 on 2014-08-15. Score: 0

The sender and the receiver carry the burden of rebroadcasting the transaction: <https://en.bitcoin.it/wiki/Network#Standard_relaying>

Usually, if a transaction is included in an orphan, it also was included in the sibling block of that orphan. This is because most miners have the same transaction selection policies and would also want to collect on the transaction fee(s).

If there are any issues, you can also MANUALLY rebroadcast via JSON-RPC or bitcoind or Bitcoin-qt debug console: <https://en.bitcoin.it/wiki/Raw_Transactions#Re-broadcast_a_transaction>


---

