How to log broadcast path of tx?

[takuma sato]

I want to make a study of latency in transaction relay and I would like to know a way to see where the transaction jumps exactly from node to node step by step since you send it and get a ms of how much time it takes on each step until it becomes inserted into a block. Is there a way to monitor this?

[DannyHamilton]

I want to make a study of latency in transaction relay and I would like to know a way to see where the transaction jumps exactly from node to node step by step since you send it and get a ms of how much time it takes on each step until it becomes inserted into a block. Is there a way to monitor this?

Only if you control the nodes.

If you create an isolated LAN, and run your own copy of testnet on your LAN, then you can trace the transaction throughout your LAN.

There is no way to know what path or how much time a transaction takes to traverse the nodes that you have no control over.

[HCP]

Is there a way to monitor this?

In a word, No.

Danny's idea of monitoring it on a number of nodes on an isolated LAN would yield "lab quality" data, but won't give you an idea of "real world" performance. Theoretically you could try and setup 2 nodes that in geographically different locations to try and ensure they are not directly connected and then measure the time between one node broadcasting a transaction and the other node receiving it... but, as Danny pointed out, there will be no way to know exactly how many steps/nodes are between your 2 nodes. It could be 0, it could be 100.

There is also the likelihood that the traversal path could change as nodes drop out and/or come on line. It's a dynamic network.

Additionally, you'd only really be monitoring what the latency is between those 2 specific nodes. It won't necessarily be indicative of the "average" latency experienced for any given transaction/node.

[Quickseller]

Theoretically you could try and setup 2 nodes that in geographically different locations to try and ensure they are not directly connected and then measure the time between one node broadcasting a transaction and the other node receiving it... but, as Danny pointed out, there will be no way to know exactly how many steps/nodes are between your 2 nodes. It could be 0, it could be 100.

If Bob has two nodes (Node "A" and Node "C") that are both connected to node "B" run by someone else, broadcasts the transaction from Node "A", and receives the transaction to Node "C" from Node "B", he will know the path of his transaction.

Bob could potentially expand his network of nodes to be larger than two nodes. If Bob has many nodes, he could follow the path of propagation as long as there is exactly one hop between each node not controlled by him to another node controlled by him. He can also measure the exact time each of his nodes receive his transaction to get an idea as to how quickly his transaction is propagating.  

I would also point out two things:
1- Nodes typically connect to a geographically diverse set of nodes. If I have a node in North Carolina connected to nodes in California, France, Illinois, New York, and Mexico City, if I broadcast a transaction, it may take longer to get to South Carolina than to California, even though South Carolina is geographically much closer.

2 - The time it takes a transaction to propagate throughout the network is very small compared to the time it takes for a transaction to get one confirmation. There is an approximately 0.1664% chance a block will be found at any given second, and I don't think it typically takes more than a second or two for most transactions to fully propagate. So in general, a transaction will have been fully propagated for a long time before it is confirmed.  

[pooya87]

There are 2 parts in your question. Knowing the path and knowing the propagation time.
The former is impossible as others pointed out since you'd need to control all nodes or see what they receive (like being their ISP).

The later on the other hand is possible but harder. You could increase the number of nodes you connect to to a large number and send one your transaction. Then wait to see how long it takes for the other nodes to start giving you INV messages containing your transaction hash. That way you could come up with an approximate amount of time it takes to propagate the transaction in bitcoin network.
The problem however is that nodes don't immediately send out INV messages to other nodes, they add certain delays and also I believe they send INV to a random node from their total connected nodes in small intervals. In other words the time you come up with has some intentional added delays in it.
Here is a paper from 2016: https://www.researchgate.net/publication/303183824_Bitcoin_Network_Measurements_for_Simulation_Validation_and_Parameterisation

Bob could potentially expand his network of nodes to be larger than two nodes. If Bob has many nodes, he could follow the path of propagation as long as there is exactly one hop between each node not controlled by him to another node controlled by him.

Not possible. Imagine if A sends to B then B sends to C then C sends to D and so on, and Bob is connected to all and initiates things by sending the tx to node A.
Node C (even though it received 3rd) could send Bob the transaction sooner than node B due to the delays I mentioned. Bob can not conclude that the hop was from A to C then to B.