7

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?

cdecker
  • 9,319
  • 1
  • 38
  • 61
Albert S
  • 1,600
  • 10
  • 21

1 Answers1

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.

cdecker
  • 9,319
  • 1
  • 38
  • 61
  • 8
    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 Sep 07 '17 at 23:48
  • @PieterWuille can you point me to the implementation of this? Is it the PoissonNextSend() ? – Albert S Sep 08 '17 at 17:34
  • 1
    Indeed, that's the function to compute Poisson-distributed intervals between send events. – Pieter Wuille Oct 08 '17 at 00:39
  • @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 Nov 06 '17 at 14:01
  • 1
    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 Nov 06 '17 at 15:31
  • @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 Nov 07 '17 at 15:40
  • 1
    lambda is the rate. rate is the inverse of the time between events. – Pieter Wuille Nov 07 '17 at 18:00
  • 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 Nov 08 '17 at 08:01