1

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.

Improve this question

2 Answers 2

Reset to default
1

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.

Improve this answer
5
  • 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
    Dec 19, 2018 at 12:48
  • 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.
    – Andrew Chow ♦
    Dec 19, 2018 at 16:38
  • 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).
    – Pieter Wuille
    Dec 19, 2018 at 21:20
  • 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
    Oct 17, 2022 at 20:06
  • 1
    @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.
    – Andrew Chow ♦
    Oct 17, 2022 at 23:04
-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

Improve this answer
2
  • 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
    Dec 18, 2018 at 21:08
  • 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
    – Pieter Wuille
    Dec 18, 2018 at 21:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.