16:56:09 <m-relay> <c​haser:monero.social> ironically, tob inspired it, they made a decryption delay function tool out of it, which is very clever
21:57:29 <m-relay> <r​ucknium:monero.social> I think the next-peer-connection selection is not even uniform over the 20 most recent peers. It's a "parabolic" distribution: https://github.com/monero-project/monero/blob/master/src/p2p/net_node.inl#L1302-L1312
21:57:30 <m-relay> <r​ucknium:monero.social> If my calculations are correct, the zeroth index has a 36% probability of being selected. That may suggest that `get_connections` wasn't misreporting the node's connections. Instead, the most recent connection may have been dropped into the top of the white_list and then re-selected with high probability.
21:59:08 <m-relay> <r​ucknium:monero.social> Why? I don't know. Besides a patch by mooo to make sure no integers were skipped, the code came with the "moved all stuff to github" commit from original Cryptonote.
21:59:32 <m-relay> <s​yntheticbird:monero.social> OOF
22:00:30 <m-relay> <r​ucknium:monero.social> It's not necessarily a good or bad behavior. But it definitely would explain why my theoretical probability wasn't matching the empirical probability.