Skip to content

Conversation

mzumsande
Copy link
Contributor

PoissonNextSend and PoissonNextSendInbound are used in the p2p code to obfuscate various regularly occurring processes, in order to make it harder for others to get timing-based information deterministically.

The naming of these functions has been confusing to several people (including myself, see also #23347) because the resulting random timestamps don't follow a Poisson distribution but an exponential distribution (related to events in a Poisson process, hence the name). This PR

  • moves PoissonNextSend() out of net to random and renames it to GetExponentialRand()
  • moves PoissonNextSendInbound() out of CConnman to PeerManager and renames it to NextInvToInbounds()
  • adds documentation for these functions

This is work by jnewbery - due to him being less active currently, I opened the PR and will address feedback.

src/random.cpp Outdated

std::chrono::microseconds GetExponentialRand(std::chrono::microseconds now, std::chrono::seconds average_interval)
{
double unscaled = -std::log1p(GetRand(1ULL << 48) * -0.0000000000000035527136788 /* -1/2^48 */);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is 1ULL guaranteed to be of the same width as uint64_t{1}? Even if they are, maybe still replace it while touching this line?

Also, the function could be moved closer to GetRand*Duration, to bundle related calls?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't able to find systems where it wouldn't be the same width, but I don't think there is a guarantee. Changed it to uint64_t{1}.
Also moved the function up in random.h as suggested.

@DrahtBot DrahtBot added the P2P label Jan 10, 2022
@jnewbery
Copy link
Contributor

Concept ACK. Thanks for taking this over, @mzumsande!

@hebasto
Copy link
Member

hebasto commented Jan 10, 2022

the resulting random timestamps don't follow a Poisson distribution but an exponential distribution

True.

Concept ACK.

Copy link
Contributor

@jnewbery jnewbery left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 35cf6e4

@mzumsande mzumsande force-pushed the 202201_jnewbery_poisson_rename branch from 35cf6e4 to d74acdd Compare January 13, 2022 14:51
jnewbery and others added 5 commits January 13, 2022 15:54
PoissonNextSend is used by net and net_processing and is stateless, so
place it in the utility random.cpp translation unit.
Co-authored-by: Martin Zumsande <mzumsande@gmail.com>
This distribution is used for more than just the next inv send, so make
the name more generic.

Also rename to "exponential" to avoid the confusion that this is a
poisson distribution.

-BEGIN VERIFY SCRIPT-
ren() { sed -i "s/\<$1\>/$2/g" $(git grep -l "$1" ./src) ; }

ren  PoissonNextSend   GetExponentialRand
ren  "a poisson timer" "an exponential timer"
-END VERIFY SCRIPT-
@mzumsande mzumsande force-pushed the 202201_jnewbery_poisson_rename branch from d74acdd to 4ab9913 Compare January 13, 2022 14:55
@jnewbery
Copy link
Contributor

utACK 4ab9913

Copy link
Member

@hebasto hebasto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approach ACK 4ab9913.

I verified "move" commits with git diff ... --color-moved=dimmed-zebra.

My only concerns are about the last commit 4ab9913 "[net processing] Guard NextInvToInbounds and m_next_inv_to_inbounds with cs_main":

  • "No need for an atomic, since cs_main is held anyway when accessing this data" -- does not look like a decent justification
  • it seems suboptimal to increase involvement of the ::cs_main, i.e., the "validation" lock, into P2P code
  • it makes a scope of the PR wider (other commits do not touch multithreading stuff)

@mzumsande mzumsande force-pushed the 202201_jnewbery_poisson_rename branch from 4ab9913 to 9b8dcb2 Compare January 19, 2022 16:29
@mzumsande
Copy link
Contributor Author

My only concerns are about the last commit 4ab9913 "[net processing] Guard NextInvToInbounds and m_next_inv_to_inbounds with cs_main":

I pushed an update, dropping the last commit (which changed the locking from std::atomic to using cs_main).

While I think that if this had been new code (instead of being moved from net), we likely wouldn't have used an atomic, I agree that it's better if the focus of this PR is smaller and does not include locking changes.

Copy link
Contributor

@theStack theStack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK

tiny nit: now that the call to (std::)log1p has moved to src/random.cpp, I think including math.h in src/net.cpp should not be needed anymore and can be removed (though I may have overlooked something).

Copy link
Member

@hebasto hebasto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 9b8dcb2, I have reviewed the code and it looks OK, I agree it can be merged.

@jnewbery
Copy link
Contributor

ACK 9b8dcb2

Only difference from previous iteration is that the final commit has been dropped.

Copy link
Contributor

@theStack theStack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 9b8dcb2 📊

@fanquake fanquake merged commit 6d859cb into bitcoin:master Jan 23, 2022
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jan 23, 2022
@bitcoin bitcoin locked and limited conversation to collaborators Jan 23, 2023
@mzumsande mzumsande deleted the 202201_jnewbery_poisson_rename branch June 23, 2023 18:03
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants