<p>Each full-node will send an <code>INV</code> message to all active peer channels when a new transaction is organised into the local mempool, except from the channel the transaction was received from.</p>

<p>In a given channel, the node is internally subscribing to following events related to receiving new inbound transactions:</p>

<ul>
<li>1) <code>INV</code> message from peer</li>
<li>2) <code>TX</code> message from peer</li>
<li>3) Local Mempool organisation event (new TX accepted)</li>
</ul>

<p>If it receives an INV with a new TXID from a peer, it will request the full transaction with GETDATA(INV). If it receives a TX message this will be either accepted or rejected in the mempool. Upon acceptance (local mem-pool organisation event [3]), a handler will send an INV(TX) message to all channels (save the one where the TX was first seen).</p>

<p>I know of no individual channel transaction queues in any Bitcoin implementation.</p>

CC BY-SA 4.0
2019-01-27T16:57:30.040Z
2019-01-27T16:57:30.040Z
James C.
<blockquote>
  <p>I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.</p>
</blockquote>

<p>Note that this is specific to Bitcoin Core. Other full node software may not exhibit this behavior.</p>

<p>When Bitcoin Core receives a transaction, it adds the transaction to lists that it maintains for every other node it is connected to. Each node has its own list and that list contains all of the transactions that your node has received but may not have been received by the other node. After a certain random time delay, your node will then send messages to the other node. Among the messages it sends is an INV for transactions in the list for that node.</p>

<p>However not all transactions in the list are sent. Only some of them are sent. To select which transactions are sent, your node will sort the transaction list by the number of ancestors it has (so that parent transactions are relayed before child transactions) and by its feerate. Those transactions with the fewest ancestors and highest feerate will be at the top. Transactions are selected from this sorted list until either the INV message reaches its limit (which happens rarely) or there are no transactions remaining. Once transactions are selected, the INV is sent.</p>

<blockquote>
  <p>Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?</p>
</blockquote>

<p>The random delay between sends is done for privacy reasons. The sorting of transactions is done to prioritize the transactions that will be selected first by miners. It also helps with privacy.</p>

<p>The reason these help with privacy is because a spy node that has connected to your node will not be able to always know what transactions your node has received and what your mempool looks like. It won't be able to know which transactions you have received first. Furthermore, due to the random delays, if a transaction originates from your node, it is possible that a node connected directly to yours receives your transaction from someone else first, thereby reducing the certainty of such analyses.</p>

CC BY-SA 4.0
2019-01-27T18:13:23.647Z
There is indeed a limit to how much is sent out at once, but this limit is relatively high and rarely hit. In most cases, the entire buffer is sent. The sorting is primarily done to guarantee that parents are sent before children, so as to avoid orphans.
Pieter Wuille
CC BY-SA 4.0
2019-01-27T21:53:00.537Z
"sort the transaction list by the number of ancestors" might want to mention that this is just an computationally cheap way to make sure parents are relayed before children.
G. Maxwell
CC BY-SA 4.0
2019-01-27T17:35:52.727Z
2019-01-27T22:57:04.760Z
2019-01-27T22:57:04.760Z
Ava Chow
<p>I know the general gossip protocol that occurs i.e transactions are sent to neighboring nodes who then send it to their peers etc. but I was trying to find a more in-depth answer on how transactions are sent across the bitcoin network.</p>

<p>I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.</p>

<p>Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?</p>

<p>Any help would be great, thanks!</p>

<transactions><network>
How are transactions propagated through the bitcoin network? (In-depth)
DonalDraper
# How are transactions propagated through the bitcoin network? (In-depth)

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

I know the general gossip protocol that occurs i.e transactions are sent to neighboring nodes who then send it to their peers etc. but I was trying to find a more in-depth answer on how transactions are sent across the bitcoin network.

I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.

Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?

Any help would be great, thanks!

**Tags:** transactions, network


---

## 2 answers

### Answer by username_2 on 2019-01-27. Score: 9 | Accepted answer

> I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.

Note that this is specific to Bitcoin Core. Other full node software may not exhibit this behavior.

When Bitcoin Core receives a transaction, it adds the transaction to lists that it maintains for every other node it is connected to. Each node has its own list and that list contains all of the transactions that your node has received but may not have been received by the other node. After a certain random time delay, your node will then send messages to the other node. Among the messages it sends is an INV for transactions in the list for that node.

However not all transactions in the list are sent. Only some of them are sent. To select which transactions are sent, your node will sort the transaction list by the number of ancestors it has (so that parent transactions are relayed before child transactions) and by its feerate. Those transactions with the fewest ancestors and highest feerate will be at the top. Transactions are selected from this sorted list until either the INV message reaches its limit (which happens rarely) or there are no transactions remaining. Once transactions are selected, the INV is sent.

> Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?

The random delay between sends is done for privacy reasons. The sorting of transactions is done to prioritize the transactions that will be selected first by miners. It also helps with privacy.

The reason these help with privacy is because a spy node that has connected to your node will not be able to always know what transactions your node has received and what your mempool looks like. It won't be able to know which transactions you have received first. Furthermore, due to the random delays, if a transaction originates from your node, it is possible that a node connected directly to yours receives your transaction from someone else first, thereby reducing the certainty of such analyses.

> **Comments:**
> **username_3**: There is indeed a limit to how much is sent out at once, but this limit is relatively high and rarely hit. In most cases, the entire buffer is sent. The sorting is primarily done to guarantee that parents are sent before children, so as to avoid orphans.  
> **username_4**: "sort the transaction list by the number of ancestors" might want to mention that this is just an computationally cheap way to make sure parents are relayed before children.  

---

### Answer by username_1 on 2019-01-27. Score: 2

Each full-node will send an `INV` message to all active peer channels when a new transaction is organised into the local mempool, except from the channel the transaction was received from.

In a given channel, the node is internally subscribing to following events related to receiving new inbound transactions:

* 1) `INV` message from peer
* 2) `TX` message from peer
* 3) Local Mempool organisation event (new TX accepted)

If it receives an INV with a new TXID from a peer, it will request the full transaction with GETDATA(INV). If it receives a TX message this will be either accepted or rejected in the mempool. Upon acceptance (local mem-pool organisation event [3]), a handler will send an INV(TX) message to all channels (save the one where the TX was first seen).

I know of no individual channel transaction queues in any Bitcoin implementation.


---

