Transaction Relay and trickling in Bitcoin

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.

Herofire

Posted 2018-12-18T18:39:15.023

Reputation: 73

Answers

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.

Andrew Chow

Posted 2018-12-18T18:39:15.023

Reputation: 40 910

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 – 2018-12-19T12:48:37.233

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 – 2018-12-19T16:38:06.020

2It 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 – 2018-12-19T21:20:40.393

-2

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

amaclin

Posted 2018-12-18T18:39:15.023

Reputation: 5 763

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 – 2018-12-18T21:08:45.230

2This 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 – 2018-12-18T21:20:12.157