That's a weird random index selection code there, but I can't arrive to that 36% probability. In my calculations, it still depends on max_index and 0th index probability reduces as max_index get larger. I ended up with "RND(0...M) <= M^(2/3)" formula for the 0th index

M^(2/3) gets smaller and smaller compared to M, as M grows

came across this paper, not sure if it has been shared here before: pb.univd.edu.ua/index.php/PB/article/view/746

it's in Ukranian

that's the Google translated version ^^

<b​asses:matrix.org> I recall sharing it here or in the feather room

<b​asses:matrix.org> but good to have a tranlsated version even if not that accurate.

<b​asses:matrix.org> arxiv.org/abs/2504.15986v1

<b​asses:matrix.org> Charting the Uncharted: The Landscape of Monero Peer-to-Peer Network

<b​asses:matrix.org> The Monero blockchain enables anonymous transactions through advanced cryptography in its peer-to-peer network, which underpins decentralization, security, and trustless interactions. However, privacy measures obscure peer connections, complicating network analysis. This study proposes a method to infer peer connections in Monero's latest protocol version, where timestamp data is <clipped message>

<b​asses:matrix.org> unavailable. We collect peerlist data from TCP flows, validate our inference algorithm, and map the network structure. Our results show high accuracy, improving with longer observation periods. This work is the first to reveal connectivity patterns in Monero's updated protocol, providing visualizations and insights into its topology. Our findings enhance the understanding of Moner<clipped message>

<b​asses:matrix.org> o's P2P network, including the role of supernodes, and highlight potential protocol and security improvements.

<b​asses:matrix.org> new paper

"This structural bias results in real neighbors appearing (in peer lists) three times more frequently than random nodes, making them distinguishable through cumulative frequency analysis"

Interesting

"In particular, the LCC collapses to nearly zero when around 9.4% and 12% of nodes are removed based on betweenness and degree centrality, respectively"

TLDR one needs to DDoS a carefully selected 9% of nodes to disrupt the network

9% is hundreds of nodes already

<s​yntheticbird:monero.social> Rucknium WE NEED YOU ASAP

<s​yntheticbird:monero.social> \* proceed to panic \*

<r​ucknium:monero.social> rando: In February I corresponded with Claudio Tessone about this. He didn't share all details at the time. I said:

<r​ucknium:monero.social> > If the P2P network issue is a vulnerability that an adversary could reasonably exploit, the best thing to do is report it via Monero's Vulnerability Response Process: github.com/monero-project/meta/blob…r/VULNERABILITY_RESPONSE_PROCESS.md

<r​ucknium:monero.social> I assume that Tessone didn't think it was feasible to exploit.

<b​asses:matrix.org> but they didn't, right?

<r​ucknium:monero.social> I don't think so. I told selsta that there may be a vulnerability report coming from that research team, but I didn't hear anything more until this paper was posted.

<b​asses:matrix.org> so it is similar to the hidden services deanon research paper situation?

<r​ucknium:monero.social> I think they planned to submit a talk to MoneroKon.

<r​ucknium:monero.social> rando: Similar in what way?

<b​asses:matrix.org> not reporting to Monero research team first, this paper dl.acm.org/doi/10.1145/3589335.3651487

<b​asses:matrix.org> Vulnerability Response program*

<r​ucknium:monero.social> If it's not a true vulnerability, they do not have a responsibility to report beforehand, AFAIK.

<r​ucknium:monero.social> Tessone had said to me that his team figured out a way to measure the network topology. Then he said that a network partition attack can be executed with this knowledge. I have been skeptical of the feasibility of network partition attacks in this setting. Like sech1 said, it looks like to need to kill 9% of nodes at least. Plus, the network is constantly re-arranging itself as no<clipped mess

<r​ucknium:monero.social> des disconnect and form new connections. The constant re-arranging would probably quickly repair even a powerful attack. IMHO.

<r​ucknium:monero.social> I didn't tell him i was skeptical. I said go to the Vulnerability Response Process.

<r​ucknium:monero.social> Tessone and I were in contact because Tessone's team had previously applied for a grant from the MAGIC Monero Fund to research the effectiveness of churning as a countermeasure to EAE-like attacks: MAGICGrants/Monero-Fund #26

<r​ucknium:monero.social> Unfortunately, the MMF committee thought that it would be hard to fundraise for that type of research so close in time to FCMP deployment, so it did not go ahead.

<r​ucknium:monero.social> For clarity, I was on the committee at that time.

<m​onerobull:matrix.org> kek

<m​onerobull:matrix.org> this is like saying "if you precisely sever the hydras biggest heads, you only need to cut 10% of them (ideally at once) to impact its cognitive functions"

<m​onerobull:matrix.org> >The network consists of 4,837 nodes

<m​onerobull:matrix.org> that doesnt feel right

<s​yntheticbird:monero.social> no it feels right

<r​ucknium:monero.social> sech1: With your formula, I still get around 36% when M = 20. I think M should usually be 20 when the peer `white_list` is of usual size: github.com/monero-project/monero/bl…b/master/src/p2p/net_node.inl#L1692

<r​ucknium:monero.social> Maybe I missed something.

<b​oog900:monero.social> I think that is correct when looking at just IPs

<b​oog900:monero.social> monero.fail counts nodes running on multiple ports from the same IP multiple times

<m​onerobull:matrix.org> damn ok

<r​ucknium:monero.social> IMHO, the bigger issue for Monero with network topology discovery is that an adversary can use the knowledge to try to more easily link txs to their true IP address origin. More info:

<r​ucknium:monero.social> monero-project/monero #9334#issuecomment-2307824031

<r​ucknium:monero.social> monero-project/monero #9218#issuecomment-2260917643

<r​ucknium:monero.social> Now I've actually read the paper. The results on network topology are scientifically interesting, but I doubt they could be used by an adversary for active or passive attacks. It looks like they need a week or more of data to perform the estimates. By that time, each node has cycled through a large number of peers. AFAIK, the results just reflect an average over the week and are n<clipped mess

<r​ucknium:monero.social> ot "actionable" by an adversary.

<e​longated:matrix.org> Maybe monero can have its own onion routing network to broadcast txs ? Like oxen has (don’t know if thy use it for txs though)

<s​yntheticbird:monero.social> no they don't

<e​longated:matrix.org> Xnet” playing off the “XMR” ticker and implying a separate anonymous network

<s​yntheticbird:monero.social> Lokinet is not used by Oxen nodes

<r​ucknium:monero.social> In Table 1, their "ground truth" nodes cycle through about 400 outbound connections in a week. That's about 8% of all nodes on the network.

<r​ucknium:monero.social> Plus, their estimate isn't completely correct. Their precision is 70-80%.

<r​ucknium:monero.social> It looks like their method doesn't work on inbound connections, so it is not possible to infer connections to nodes with closed ports.

<r​ucknium:monero.social> elongated: AFAIK, that is what Kovri was supposed to be, but it was never finished: getmonero.org/resources/moneropedia/kovri.html

<r​ucknium:monero.social> A Kovri-like design might just enable severe Sybil attacks.

<r​ucknium:monero.social> More info: Biryukov & Pustogarov (2015) "Bitcoin over Tor isn't a good idea" arxiv.org/abs/1410.6079 dl.acm.org/doi/10.1109/SP.2015.15

"The constant re-arranging would probably quickly repair even a powerful attack" Yes, if the attack is assumed to be successful already when existing connections are cut. But nodes have huge peer lists (1000 white, 5000 gray list) and they can re-establish connections through other nodes which are not part of the attacked 9%

So removing 9% nodes can split the network, but it will quickly reconnect through entirely new connections

<b​asses:matrix.org> Rucknium have you seen what zcash is doing with nym network?

<r​ucknium:monero.social> rando: Yes. Why do you ask?

<b​asses:matrix.org> can it replace kovir i2p instead?

<s​yntheticbird:monero.social> no

<b​asses:matrix.org> kovri*

<s​yntheticbird:monero.social> Nym is routing/obfuscating the entire Internet Protocol, it's a VPN, unlike i2p and Tor which just support Tcp. Also Nym have no "hidden service" equivalent

<b​asses:matrix.org> thanks.

<r​ucknium:monero.social> This is something I have been confused about. I don't know if you can route between two Monero nodes (or other p2p software) entirely within the Nym mixnet.

<r​ucknium:monero.social> SyntheticBird: "Nym is a VPN" is oversimplifying IMHO. The "Nym VPN" is one of the services available on the mixnet, but not the only one. The white paper suggested that there would be many type of services available over the mixnet. Maybe that model didn't work too well and instead they focused their work and marketing on the familiar VPN model. See Fig. 2 on page 12: nym<clipped mess

<r​ucknium:monero.social> .com/nym-whitepaper.pdf

<b​asses:matrix.org> im pretty sure they would be interested if you shoot them an email. nym.com/blog/new-mixnet-integration-nym-for-monero , old.reddit.com/r/Monero/comments/17…m_the_privacy_layer_of_the_internet

<r​ucknium:monero.social> I was about to post that. Here is the bounty, but unclaimed since the service stopped working: bounties.monero.social/posts/6/1-21…-nym-monero-transaction-broadcaster

<r​ucknium:monero.social> This is wallet-to-node communication by the way, not node-to-node communication.

<r​ucknium:monero.social> Some potential issues:

<r​ucknium:monero.social> 1) You are supposed to pay for service access. Use of the mixnet has been free for a while, but they are phasing in the payment requirement.

<r​ucknium:monero.social> 2) Nym mixnet node operators must agree to a terms of service that requires binding arbitration if disputes arise. I think this is just a precaution to prevent the Nym organization from being sued, but doesn't exactly amount to a permissionless network when it comes to operating the mixnet nodes themselves.

<r​ucknium:monero.social> nym.com/operators-validators-terms#…i-dispute-resolution-by-arbitration

<s​yntheticbird:monero.social> i stand corrected

<r​ucknium:monero.social> Ah, here we are: nym.com/blog/tech-deepdive-network-requesters#service-providers

<r​ucknium:monero.social> > The design space for Service Providers (SPs) is very open: some will allow access to external services on the internet, shielding the user from the prying eyes of data scraping and machine-learning-enabled observers; other SPs will allow access to shielded services that can only be accessed via the mixnet.

<r​ucknium:monero.social> Maybe an intra-mixnet p2p network is possible.

<s​yntheticbird:monero.social> Intra mixnet service provider aren't anonymized afaiu. It only enforce anonymity of its user

<s​yntheticbird:monero.social> So an intra-mixnet p2p network would still require nodes to communicate a true, non-anonymized address to communicate to. Only the initiator of the connection would be private

<s​yntheticbird:monero.social> I see more of a sybil concern than an actual improvements in privacy

<s​yntheticbird:monero.social> in p2p at least

<r​ucknium:monero.social> Right. Same sybil issue as Kovri, probably.

<g​ingeropolous:monero.social> PoW for cnxns wen