<blockquote>
  <p>If a node has 100 connections to other nodes and receives a new transaction using a getData request, it sends an inv message to it's 100 connecting peers correct?</p>
</blockquote>

<p>No. It depends on what nodes have sent an <code>inv</code> stating that they have that transaction. When an <code>inv</code> is received, the node will remember what has been <code>inv</code>'d to them by that node so that it does not attempt to send it something it already has. At most, there will be 99 <code>inv</code> messages sent. Since we already know that the peer that sent us the transaction already has it, we don't send them an <code>inv</code>. At minimum, there will be no <code>inv</code> messages sent because all nodes could have already sent us an <code>inv</code> for the same transaction.</p>

<blockquote>
  <p>Does it also send the inv message to the peer that it just received the transaction from as it is still one of it's connecting peers? </p>
</blockquote>

<p>As stated above, it does not. While there is no rule the explicitly prevents this, it is sensible to not send an <code>inv</code> to someone who has already sent an <code>inv</code> to you for the same thing. This saves bandwidth costs.</p>

<blockquote>
  <p>I'm having a bit of difficulty understanding how trickling works in terms of transactions.</p>
</blockquote>

<p>For each peer, the node keeps a list of transactions that it is going to <code>inv</code> to it. It sends <code>inv</code>'s for transactions periodically with a random delay between each <code>inv</code>. Transactions are selected to go into the <code>inv</code> message somewhat randomly and according to some metrics involving fee rate. It selects a limited number of transactions to <code>inv</code>.</p>

<blockquote>
  <p>I believed that the process was when a transaction occurs, the node responsible for the transaction would send INV messages to its peers and send the tx if the peers respond with getData.</p>
</blockquote>

<p>The node the creates a transaction treats that transaction like any other it received over the network. For every peer that node is connected to, it adds that transaction to the list of transactions that it will send to that node eventually. Then everything else is as usual. At the next time it is to send an <code>inv</code> message for a particular peer, it chooses transactions to <code>inv</code>, and the transaction it created may or may not be one of those. Once the <code>inv</code> is sent, the other node will respond with a <code>getdata</code> for the things it wants, which may or may not include the transaction it created. Then your node responds to the <code>getdata</code> with the transactions themselves.</p>

CC BY-SA 4.0
2018-12-19T12:48:37.233Z
Thanks a lot for your detailed answer. So if I understand this correctly, nodes will not sent an INV message to peers that it knows already has the transaction (i.e the peers that have already sent this node an INV to the same transaction). And when a node wants to send an tx INV to it's peers, it adds it to an already existing list of transactions that it wants to send to that specific peer. When it does send eventually, does this INV message contain multiple txID hashes or is it an INV per txid hash?
Herofire
CC BY-SA 4.0
2018-12-19T16:38:06.020Z
When it does send, the `inv` should contain multiple txids. However, it is possible (and perhaps likely), that by the time it does send an `inv`, there are only one or two txids for it to send.
Ava Chow
CC BY-SA 4.0
2018-12-19T21:20:40.393Z
It may be worth pointing out that the quotes in OP's question are outdated (they refer to the old trickling mechanism which was replaced with poisson-distributed batches a few major releases ago in Bitcoin Core).
Pieter Wuille
CC BY-SA 4.0
2022-10-17T20:06:49.223Z
What happens to txs that don't fit local mempool, everyone keeps them circulating (receiving and transmitting again because they are not seen)?
Vincent Alex
CC BY-SA 4.0
2022-10-17T23:04:21.433Z
@VincentAlex Transactions that are not added to a node's mempool are not relayed by that node. Transactions that are added to a node's mempool are not relayed more than once. So transactions that cannot get into mempools just do not get relayed. They do not keep circulating unless someone intentionally rebroadcasts it.
Ava Chow
CC BY-SA 4.0
2018-12-19T01:45:40.587Z
2018-12-19T01:45:40.587Z
Ava Chow
<blockquote>
  <p>it sends an inv message to it's 100 connecting peers correct?</p>
</blockquote>

<p>to 99</p>

<blockquote>
  <p>Does it also send the inv message to the peer that it just received the transaction from</p>
</blockquote>

<p>it is allowed, but there is no reason to do it</p>

<blockquote>
  <p>the node responsible for the transaction would send INV messages </p>
</blockquote>

<p>no one is responsible for anything</p>

CC BY-SA 4.0
2018-12-18T21:08:45.230Z
Why does it send only to 99 instead of the 100 peers? If I'm a node who just retrieved a transaction, I send an INV to all my peers about it don't I - even the one who just sent me the data unless there was a way I kept track of who sent it to me so I won't send the INV to that node
Herofire
CC BY-SA 4.0
2018-12-18T21:20:12.157Z
This does not answer the question, which is about the practical implementation of the tx relay protocol, not about what modification nodes are allowed to make to it
Pieter Wuille
CC BY-SA 4.0
2018-12-18T21:06:12.173Z
2018-12-18T21:06:12.173Z
amaclin
<p>If a node has 100 connections to other nodes and receives a new transaction using a getData request, it sends an inv message to it's 100 connecting peers correct?</p>

<p>Does it also send the inv message to the peer that it just received the transaction from as it is still one of it's connecting peers? </p>

<p>'Messages, in general, are flushed periodically about every
100 ms. However, transaction relaying takes place by “trickling” messages out. Bitcoin randomly selects with a probability
of 1/4 the transactions for an inv message and stalls the remaining transactions. Every neighbor gets a different set of randomly
chosen transactions, each about 1/4 of the currently available
set. Only the randomly selected “trickling node” (cf. addr
message relaying) gets all transactions immediately. The other
neighbors either get it later or already got it from another neighbor. Trickling reduces the overhead and at the same time makes
traffic analysis more difficult, in a similar manner as mixes do
in mix networks.'</p>

<p>I'm having a bit of difficulty understanding how trickling works in terms of transactions. I believed that the process was when a transaction occurs, the node responsible for the transaction would send INV messages to its peers and send the tx if the peers respond with getData.</p>

<transactions><network><relay>
Transaction Relay and trickling in Bitcoin
Herofire
# Transaction Relay and trickling in Bitcoin

(Asked by: username_0 on 2018-12-18)

If a node has 100 connections to other nodes and receives a new transaction using a getData request, it sends an inv message to it's 100 connecting peers correct?

Does it also send the inv message to the peer that it just received the transaction from as it is still one of it's connecting peers?

'Messages, in general, are flushed periodically about every
100 ms. However, transaction relaying takes place by “trickling” messages out. Bitcoin randomly selects with a probability
of 1/4 the transactions for an inv message and stalls the remaining transactions. Every neighbor gets a different set of randomly
chosen transactions, each about 1/4 of the currently available
set. Only the randomly selected “trickling node” (cf. addr
message relaying) gets all transactions immediately. The other
neighbors either get it later or already got it from another neighbor. Trickling reduces the overhead and at the same time makes
traffic analysis more difficult, in a similar manner as mixes do
in mix networks.'

I'm having a bit of difficulty understanding how trickling works in terms of transactions. I believed that the process was when a transaction occurs, the node responsible for the transaction would send INV messages to its peers and send the tx if the peers respond with getData.

**Tags:** transactions, network, relay


---

## 2 answers

### Answer by username_1 on 2018-12-19. Score: 1 | Accepted answer

> If a node has 100 connections to other nodes and receives a new transaction using a getData request, it sends an inv message to it's 100 connecting peers correct?

No. It depends on what nodes have sent an `inv` stating that they have that transaction. When an `inv` is received, the node will remember what has been `inv`'d to them by that node so that it does not attempt to send it something it already has. At most, there will be 99 `inv` messages sent. Since we already know that the peer that sent us the transaction already has it, we don't send them an `inv`. At minimum, there will be no `inv` messages sent because all nodes could have already sent us an `inv` for the same transaction.

> Does it also send the inv message to the peer that it just received the transaction from as it is still one of it's connecting peers?

As stated above, it does not. While there is no rule the explicitly prevents this, it is sensible to not send an `inv` to someone who has already sent an `inv` to you for the same thing. This saves bandwidth costs.

> I'm having a bit of difficulty understanding how trickling works in terms of transactions.

For each peer, the node keeps a list of transactions that it is going to `inv` to it. It sends `inv`'s for transactions periodically with a random delay between each `inv`. Transactions are selected to go into the `inv` message somewhat randomly and according to some metrics involving fee rate. It selects a limited number of transactions to `inv`.

> I believed that the process was when a transaction occurs, the node responsible for the transaction would send INV messages to its peers and send the tx if the peers respond with getData.

The node the creates a transaction treats that transaction like any other it received over the network. For every peer that node is connected to, it adds that transaction to the list of transactions that it will send to that node eventually. Then everything else is as usual. At the next time it is to send an `inv` message for a particular peer, it chooses transactions to `inv`, and the transaction it created may or may not be one of those. Once the `inv` is sent, the other node will respond with a `getdata` for the things it wants, which may or may not include the transaction it created. Then your node responds to the `getdata` with the transactions themselves.

> **Comments:**
> **username_0**: Thanks a lot for your detailed answer. So if I understand this correctly, nodes will not sent an INV message to peers that it knows already has the transaction (i.e the peers that have already sent this node an INV to the same transaction). And when a node wants to send an tx INV to it's peers, it adds it to an already existing list of transactions that it wants to send to that specific peer. When it does send eventually, does this INV message contain multiple txID hashes or is it an INV per txid hash?  
> **username_1**: When it does send, the `inv` should contain multiple txids. However, it is possible (and perhaps likely), that by the time it does send an `inv`, there are only one or two txids for it to send.  
> **username_2**: It may be worth pointing out that the quotes in OP's question are outdated (they refer to the old trickling mechanism which was replaced with poisson-distributed batches a few major releases ago in Bitcoin Core).  
> **username_3**: What happens to txs that don't fit local mempool, everyone keeps them circulating (receiving and transmitting again because they are not seen)?  
> **username_1**: @username_3 Transactions that are not added to a node's mempool are not relayed by that node. Transactions that are added to a node's mempool are not relayed more than once. So transactions that cannot get into mempools just do not get relayed. They do not keep circulating unless someone intentionally rebroadcasts it.  

---

### Answer by username_4 on 2018-12-18. Score: -3

> it sends an inv message to it's 100 connecting peers correct?

to 99

> Does it also send the inv message to the peer that it just received the transaction from

it is allowed, but there is no reason to do it

> the node responsible for the transaction would send INV messages

no one is responsible for anything

> **Comments:**
> **username_0**: Why does it send only to 99 instead of the 100 peers? If I'm a node who just retrieved a transaction, I send an INV to all my peers about it don't I - even the one who just sent me the data unless there was a way I kept track of who sent it to me so I won't send the INV to that node  
> **username_2**: This does not answer the question, which is about the practical implementation of the tx relay protocol, not about what modification nodes are allowed to make to it  

---

