<p>Yes, there is what is called transaction trickling. This is a mechanism to select a random peer for immediate forwarding of all transactions, while others receive the transaction after a random timeout. This is done in order to reduce the chances of fingerprinting the origin of a transaction. Similar to the proposed dandelion paper, it forwards a transaction through a conduit of peers before spreading it widely in the network, and observers cannot identify the origin by simply timing the time peers announce the transaction's availability.</p>

CC BY-SA 3.0
2017-09-07T23:48:11.110Z
Trickling was removed in 0.13.0. All transactions are now delayed until their next broadcast events, which happen at Poisson-distributed times.
Pieter Wuille
CC BY-SA 3.0
2017-09-08T17:34:12.527Z
@PieterWuille can you point me to the implementation of this? Is it the PoissonNextSend() ?
Albert S
CC BY-SA 3.0
2017-10-08T00:39:46.730Z
Indeed, that's the function to compute Poisson-distributed intervals between send events.
Pieter Wuille
CC BY-SA 3.0
2017-11-06T14:01:37.613Z
@PieterWuille Could you elaborate further? The function returns `nNow + (int64_t)(log1p(GetRand(1ULL << 48) * -0.0000000000000035527136788 ) * average_interval_seconds * -1000000.0 + 0.5)`. I decipher the step over `nNow` as `-log (1 - u) * lambda + 0.5`, given that `u` is a uniform variable in `[0,1]` and the interval is accounted in seconds. This is close to `-log(1-u) / lambda` which can be used to [simulate a poisson process](http://www.math.uchicago.edu/~may/VIGRE/VIGRE2010/REUPapers/Mcquighan.pdf). However, I wonder where the product (instead of division) and the `+0.5` come from?
tnull
CC BY-SA 3.0
2017-11-06T15:31:53.280Z
It's a product with the precomputed inverse, because that is faster. And with u uniform in [0..1], log(u) and log(1-u) are equivalent. +0.5 is for rounding before converting to an integer.
Pieter Wuille
CC BY-SA 3.0
2017-11-07T15:40:49.997Z
@PieterWuille Thank you for clarification. I get that the `log1p(...)` part is actually log(1-u) for a u in [0,1]. And, as the `average_interval_seconds` is in seconds and the calculation is done in microseconds, `-1000000.0` is a conversion factor, also correcting the negative outcomes of the `log`. Okay, the `+0.5` is for rounding. But I still struggle to see how `average_interval_seconds` aka lambda is equivalent with 1 / lambda?! What am I missing?
tnull
CC BY-SA 3.0
2017-11-07T18:00:18.123Z
lambda is the rate. rate is the inverse of the time between events.
Pieter Wuille
CC BY-SA 3.0
2017-11-08T08:01:17.533Z
Ah, lol. You're totally right, how did I not get that... Sorry for the inconvenience, and thank you very much for clearing this up!
tnull
CC BY-SA 3.0
2017-09-07T23:18:24.147Z
2017-09-07T23:18:24.147Z
cdecker
<p>When a node receives a transaction it verifies it and then sends it to its neighbors.<br>
My question is: does the node broadcast the transaction right away or is there a delay built in (privacy concerns) and if there is a delay built in can anyone point me to the code where that happens?  </p>

<transactions><privacy><transaction-propagation>
Is there a transaction propagation delay built in?
Albert S
# Is there a transaction propagation delay built in?

(Asked by: username_0 on 2017-09-07)

When a node receives a transaction it verifies it and then sends it to its neighbors.  
My question is: does the node broadcast the transaction right away or is there a delay built in (privacy concerns) and if there is a delay built in can anyone point me to the code where that happens?

**Tags:** transactions, privacy, transaction-propagation


---

## 1 answers

### Answer by username_1 on 2017-09-07. Score: 2

Yes, there is what is called transaction trickling. This is a mechanism to select a random peer for immediate forwarding of all transactions, while others receive the transaction after a random timeout. This is done in order to reduce the chances of fingerprinting the origin of a transaction. Similar to the proposed dandelion paper, it forwards a transaction through a conduit of peers before spreading it widely in the network, and observers cannot identify the origin by simply timing the time peers announce the transaction's availability.

> **Comments:**
> **username_2**: Trickling was removed in 0.13.0. All transactions are now delayed until their next broadcast events, which happen at Poisson-distributed times.  
> **username_0**: @username_2 can you point me to the implementation of this? Is it the PoissonNextSend() ?  
> **username_2**: Indeed, that's the function to compute Poisson-distributed intervals between send events.  
> **username_3**: @username_2 Could you elaborate further? The function returns `nNow + (int64_t)(log1p(GetRand(1ULL << 48) * -0.0000000000000035527136788 ) * average_interval_seconds * -1000000.0 + 0.5)`. I decipher the step over `nNow` as `-log (1 - u) * lambda + 0.5`, given that `u` is a uniform variable in `[0,1]` and the interval is accounted in seconds. This is close to `-log(1-u) / lambda` which can be used to [simulate a poisson process](http://www.math.uchicago.edu/~may/VIGRE/VIGRE2010/REUPapers/Mcquighan.pdf). However, I wonder where the product (instead of division) and the `+0.5` come from?  
> **username_2**: It's a product with the precomputed inverse, because that is faster. And with u uniform in [0..1], log(u) and log(1-u) are equivalent. +0.5 is for rounding before converting to an integer.  
> **username_3**: @username_2 Thank you for clarification. I get that the `log1p(...)` part is actually log(1-u) for a u in [0,1]. And, as the `average_interval_seconds` is in seconds and the calculation is done in microseconds, `-1000000.0` is a conversion factor, also correcting the negative outcomes of the `log`. Okay, the `+0.5` is for rounding. But I still struggle to see how `average_interval_seconds` aka lambda is equivalent with 1 / lambda?! What am I missing?  
> **username_2**: lambda is the rate. rate is the inverse of the time between events.  
> **username_3**: Ah, lol. You're totally right, how did I not get that... Sorry for the inconvenience, and thank you very much for clearing this up!  

---

