<p>While implementation specific, transactions are only re-broadcasted by the bitcoin-qt client after every x minutes (30?) and only if it's not in the main chain yet. Once a block comes in that has the transaction, it'll stop transmitting. If a new chain is accepted later that doesn't have the transaction, it will start broadcasting again.</p>
<p>About transactions getting lost, <a href="https://bitcoin.stackexchange.com/a/9737/4358">I already wrote an answer about that once</a> :</p>
<blockquote>
<p>Most clients on the network have a transaction pool in their memory. The same basically applies to miners: they just dump the top 500KB (or some other value) transactions into a block, sorted by transaction fee (descending, of course). When there aren't many transactions, maybe because of a series of block in a short amount of time, it will be confirmed anyway.</p>
<p>But to answer your actual question: yes, transactions (sort of) expire. When you send a transaction, it sends a <code>tx</code> frame to all connected peers. These peers store the transaction in their memory pools and tell all their connections that they have a new transaction. When those connections don't have it yet, they ask for it, and that's how a transaction spreads over the network.</p>
<p>At some point every node in the network will have the transaction in their memory pool, and at that point it will no longer be sent over the network. Now when a user restarts their client, the memory pool is wiped, and the transaction is deleted from that computer. (Plus a few other ways to delete transactions from the pool)</p>
<p>Because of that it's very unlikely for the transaction to be gone from the entire network, but in case it does happen: the reference client will automatically re-send the transaction every x hours(/minutes?) when it's still not confirmed.</p>
<p>Oh, and I forgot the most important part: transactions on Bitcoin (<code>tx</code> frames in the protocol) don't have a 'time' field, which means that transaction expiration can't be a feature of Bitcoin.</p>
<p>To summarize: yes, the transaction <em>can</em> expire, but that is really unlikely.</p>
</blockquote>

CC BY-SA 3.0
2013-04-22T12:04:21.457Z
blockchain.info has some interesting information regarding [unconfirmed transactions](http://blockchain.info/unconfirmed-transactions) (Transactions waiting to be included in a block), and [orphaned blocks](http://blockchain.info/orphaned-blocks) (Valid blocks not part of the main bitcoin chain).
Hugh Pearse
CC BY-SA 3.0
2013-04-22T10:48:02.180Z
2013-04-22T10:48:02.180Z
2020-06-16T11:10:03.350Z
Tom van der Woerdt
<p>In the original publication about bitcoin, in section 5 it states that</p>

<blockquote>
  <p>If two nodes broadcast different versions of the next block
  simultaneously , some nodes may receive one or the other first. In
  that case, they work on the first one they received but save the other
  branch in case it becomes longer. The tie will be broken when the next
  proof-of-work is found and one branch becomes longer;</p>
</blockquote>

<p>the author then states</p>

<blockquote>
  <p>New transaction broadcasts do not necessarily need to reach all nodes.
  As long as they reach many nodes, they will get into a block before
  long.</p>
</blockquote>

<p>My question is: How do lost transactions "get into a block before long"? Are they constantly re-transmitted until they are 6 blocks deep and the proof of work has been completed? Is it possible that a transaction could be re-transmitted indefinitely, and it might never be put into a block that is fully synchronized?</p>

<transactions><block><synchronization>
Transaction broadcasts and block synchronization
Hugh Pearse
# Transaction broadcasts and block synchronization

(Asked by: username_0 on 2013-04-22)

In the original publication about bitcoin, in section 5 it states that

> If two nodes broadcast different versions of the next block
> simultaneously , some nodes may receive one or the other first. In
> that case, they work on the first one they received but save the other
> branch in case it becomes longer. The tie will be broken when the next
> proof-of-work is found and one branch becomes longer;

the author then states

> New transaction broadcasts do not necessarily need to reach all nodes.
> As long as they reach many nodes, they will get into a block before
> long.

My question is: How do lost transactions "get into a block before long"? Are they constantly re-transmitted until they are 6 blocks deep and the proof of work has been completed? Is it possible that a transaction could be re-transmitted indefinitely, and it might never be put into a block that is fully synchronized?

**Tags:** transactions, block, synchronization


---

## 1 answers

### Answer by username_1 on 2013-04-22. Score: 3 | Accepted answer

While implementation specific, transactions are only re-broadcasted by the bitcoin-qt client after every x minutes (30?) and only if it's not in the main chain yet. Once a block comes in that has the transaction, it'll stop transmitting. If a new chain is accepted later that doesn't have the transaction, it will start broadcasting again.

About transactions getting lost, [I already wrote an answer about that once](https://bitcoin.stackexchange.com/a/9737/4358) :

> Most clients on the network have a transaction pool in their memory. The same basically applies to miners: they just dump the top 500KB (or some other value) transactions into a block, sorted by transaction fee (descending, of course). When there aren't many transactions, maybe because of a series of block in a short amount of time, it will be confirmed anyway.
>
> But to answer your actual question: yes, transactions (sort of) expire. When you send a transaction, it sends a `tx` frame to all connected peers. These peers store the transaction in their memory pools and tell all their connections that they have a new transaction. When those connections don't have it yet, they ask for it, and that's how a transaction spreads over the network.
>
> At some point every node in the network will have the transaction in their memory pool, and at that point it will no longer be sent over the network. Now when a user restarts their client, the memory pool is wiped, and the transaction is deleted from that computer. (Plus a few other ways to delete transactions from the pool)
>
> Because of that it's very unlikely for the transaction to be gone from the entire network, but in case it does happen: the reference client will automatically re-send the transaction every x hours(/minutes?) when it's still not confirmed.
>
> Oh, and I forgot the most important part: transactions on Bitcoin (`tx` frames in the protocol) don't have a 'time' field, which means that transaction expiration can't be a feature of Bitcoin.
>
> To summarize: yes, the transaction *can* expire, but that is really unlikely.

> **Comments:**
> **username_0**: blockchain.info has some interesting information regarding [unconfirmed transactions](http://blockchain.info/unconfirmed-transactions) (Transactions waiting to be included in a block), and [orphaned blocks](http://blockchain.info/orphaned-blocks) (Valid blocks not part of the main bitcoin chain).  

---

