<p>Transactions you've sent will be resent forever (every 30 minutes or so), even if they have no chance of getting in the chain because they are now invalid. The same transactions are sent -- new ones aren't created.</p>

CC BY-SA 3.0
2012-03-10T21:29:22.137Z
This conflict's with sipa's answer.  You wrote "even if they have no chance of getting in the chain because they are now invalid" and he wrote "under the condition that they are valid in the new chain".  Who's right?
Chris Moore
CC BY-SA 3.0
2012-03-11T00:43:56.593Z
We were talking about different things:
* the owner of the transaction will retransmit under the condition his transaction is not accepted (anymore), even if it has no chance.
* other nodes will, in the case of a reorganization, move transactions back to the memory pool, if they are valid in the new chain. This is unrelated to rebroadcasting.
Pieter Wuille
CC BY-SA 3.0
2012-03-09T16:23:22.450Z
2012-03-09T16:23:22.450Z
theymos
<p>In the case of a reorganization, the transactions that were 'lost' in the previous longer chain are moved back to the memory pool, under the condition that they are valid in the new chain. This means that if the inputs do not exist anymore in the new chain, they are lost. This is precisely how a "double spend attack" works: try to fork the chain, and spend the coins in both branches.</p>

<p>The effect of moving transactions back to the memory pool is only that the client does not forget them (it will not reannounce, or download them from peers when told about them), and if the node is a miner, they will be candidates for inclusion in the next block created.</p>

<p>In general, this means that there are no retransmits: miners and the rest of the network try their best to not forget about these lost transactions. If that fails however, and for some reason (too little fee, for example) the transaction does not survive, it is the responsibility of the node that originally sent the transaction out to rebroadcast. So yes, there are retransmits as well, but only by the original owner, and only when it detects the transaction is not or no longer in the block chain.</p>

<p>It's always a byte-for-byte identical transaction, not an equivalent using different inputs.</p>

CC BY-SA 3.0
2013-03-15T04:44:44.180Z
> "it will not reannounce"
So it isn't in the sender's best interest to re-announce if planning to double spend.  Sounds like an attack vector to address.
Stephen Gornick
CC BY-SA 3.0
2012-03-10T21:35:55.997Z
"under the condition that they are valid in the new chain" - where's this condition in the code?  I just scanned for it but didn't see it.
Chris Moore
CC BY-SA 3.0
2012-03-11T00:42:20.370Z
::Reorganize in main.cpp resurrects the lost transactions by feeding them to AcceptToMemory pool, which calls the same checks that are done as on transactions that arrive as a tx message.
Pieter Wuille
CC BY-SA 3.0
2012-03-11T06:28:01.570Z
It does, but it does it before RemoveFromMemoryPool is called for the transactions which were on the previous best fork, and so isn't it the case that the checks could pass due to transactions which only existed on the old branch, and will soon no longer exist?
Chris Moore
CC BY-SA 3.0
2012-03-11T15:13:09.513Z
vConnect is the list of transactions in the newly connected branch.
Pieter Wuille
CC BY-SA 3.0
2012-03-09T15:57:16.487Z
2016-07-23T08:48:50.900Z
2016-07-23T08:48:50.900Z
Pieter Wuille
<p>What happens when a forked chain becomes longer than the main block chain?</p>

<p>Let's assume the forked chain that just became longer has no transactions in it, so it is as if every transaction in the last n blocks never happened.</p>

<p>As I understand it, the official Bitcoin client will recognize that any recent transactions it sent no longer exist and will re-broadcast them. By question is,</p>

<ul>
<li>What age transactions will be re-issued? Will a transaction that is years old still be reissued? What's the cutoff?</li>
<li>Does the exact transaction get reissued or does an equivalent transaction get created? i.e. will it attempt to send the exact same Bitcoins (which, due to the fork, might no longer actually be owned) or will it create an equivalent transaction based on Bitcoins that it still owns? What if the client doesn't have enough Bitcoins?</li>
</ul>

<p>Edit: Since I can't find where I first saw it anymore, I guess I should also ask: does the official client, in fact, reissue transactions in the event of a block chain fork?</p>

<client><blockchain><blockchain-fork>
Bitcoin client behavior in event of a fork
Computerish
# Bitcoin client behavior in event of a fork

(Asked by: username_0 on 2012-03-09)

What happens when a forked chain becomes longer than the main block chain?

Let's assume the forked chain that just became longer has no transactions in it, so it is as if every transaction in the last n blocks never happened.

As I understand it, the official Bitcoin client will recognize that any recent transactions it sent no longer exist and will re-broadcast them. By question is,

* What age transactions will be re-issued? Will a transaction that is years old still be reissued? What's the cutoff?
* Does the exact transaction get reissued or does an equivalent transaction get created? i.e. will it attempt to send the exact same Bitcoins (which, due to the fork, might no longer actually be owned) or will it create an equivalent transaction based on Bitcoins that it still owns? What if the client doesn't have enough Bitcoins?

Edit: Since I can't find where I first saw it anymore, I guess I should also ask: does the official client, in fact, reissue transactions in the event of a block chain fork?

**Tags:** client, blockchain, blockchain-fork


---

## 2 answers

### Answer by username_1 on 2012-03-09. Score: 3 | Accepted answer

Transactions you've sent will be resent forever (every 30 minutes or so), even if they have no chance of getting in the chain because they are now invalid. The same transactions are sent -- new ones aren't created.

> **Comments:**
> **username_2**: This conflict's with sipa's answer.  You wrote "even if they have no chance of getting in the chain because they are now invalid" and he wrote "under the condition that they are valid in the new chain".  Who's right?  
> **username_3**: We were talking about different things: * the owner of the transaction will retransmit under the condition his transaction is not accepted (anymore), even if it has no chance. * other nodes will, in the case of a reorganization, move transactions back to the memory pool, if they are valid in the new chain. This is unrelated to rebroadcasting.  

---

### Answer by username_3 on 2012-03-09. Score: 6

In the case of a reorganization, the transactions that were 'lost' in the previous longer chain are moved back to the memory pool, under the condition that they are valid in the new chain. This means that if the inputs do not exist anymore in the new chain, they are lost. This is precisely how a "double spend attack" works: try to fork the chain, and spend the coins in both branches.

The effect of moving transactions back to the memory pool is only that the client does not forget them (it will not reannounce, or download them from peers when told about them), and if the node is a miner, they will be candidates for inclusion in the next block created.

In general, this means that there are no retransmits: miners and the rest of the network try their best to not forget about these lost transactions. If that fails however, and for some reason (too little fee, for example) the transaction does not survive, it is the responsibility of the node that originally sent the transaction out to rebroadcast. So yes, there are retransmits as well, but only by the original owner, and only when it detects the transaction is not or no longer in the block chain.

It's always a byte-for-byte identical transaction, not an equivalent using different inputs.

> **Comments:**
> **username_2**: "under the condition that they are valid in the new chain" - where's this condition in the code?  I just scanned for it but didn't see it.  
> **username_3**: ::Reorganize in main.cpp resurrects the lost transactions by feeding them to AcceptToMemory pool, which calls the same checks that are done as on transactions that arrive as a tx message.  
> **username_2**: It does, but it does it before RemoveFromMemoryPool is called for the transactions which were on the previous best fork, and so isn't it the case that the checks could pass due to transactions which only existed on the old branch, and will soon no longer exist?  
> **username_3**: vConnect is the list of transactions in the newly connected branch.  
> **username_4**: > "it will not reannounce" So it isn't in the sender's best interest to re-announce if planning to double spend.  Sounds like an attack vector to address.  

---

