Hello to all the community members of Monero.

I was contacted by Rucknium on queries regarding the paper "On the anonymity of peer-to-peer network anonymity schemes used by cryptocurrencies"

I could sense that there was some confusion regarding what the assumptions are with regards to learning the privacy subgraph.

I think this statement from the previous chat captures it well

"Their wording is "We send 50 transactions per honest node before analyzing the distribution of diffusions per node." I'm not sure if the adversary nodes or the honest nodes are sending these txs."

I will try to clarify this in the following point. If you still have doubts please feel free to ask.

(1) The assumption is that the adversary will send transactions to honest nodes (Appendix point 4 of the description of learning the subgraph).

Now, whether these transactions are generated by other nodes and forwarded to the adversary or the adversary itself generates them doesn't matter for the analysis.

If there are sufficient transactions being generated and forwarded to the adversary nodes in the network, there would not be any need for generating extra transactions by the adversary themselves.

However, if the transactions are low in the network, the adversary nodes would generate more transactions so that they can observe more diffusions per honest node.

(2) To analyze the diffusions, it is essential that the adversary keeps track of what transaction was forwarded to which honest node.

Thus, we analyze the diffusions of only the transactions that were forwarded by the adversary to some honest node for which it wants to learn its edges.

Hi. Can you idle in there today ? Might be a bit before people who know about this read what you wrote.

Sure, no problem!

p2p_anon: Thanks for coming to talk here :)

I see. The adversary could launch an active attack by flooding honest nodes with transactions. In Monero's case that could get expensive since the adversary would have to bid above the minimum transaction fee when the mempool starts to get full and nodes drop low-fee transactions.

The crux of my concern with the paper's results is that it assumes a ratio of 50 transaction broadcast per node (not necessarily broadcast by honest nodes) to learn the private subgraph. But the original Dandelion++ protocol instructed nodes to change their private subgraphs every ten minutes. (I'm not sure what Monero does. vtnerd may know).

We don't have a reliable number of how many Monero nodes there are today. Cao, T., Yu, J., Decouchant, J., Luo, X., & Verissimo, P. (2020) "Exploring the monero peer-to-peer network" counted about 3,000 Monero nodes at a time when the average transactions per day was 5,000.

-!- p2p_anon [~pks⊙p1iatb] has quit [Ping timeout: 265 seconds

About... half an hour ago.

:( I think p2p_anon has the link to the IRC logs.

Taking 3,000 Monero nodes as a lower bound, using your paper's methods an adversary would have to broadcast 6 * 24 * 50 * 3000 = 21,600,000 transactions per day. (number of 10-minute epochs per hour) * (hours/day) * (required txs/node) * (lower bound of Monero nodes in network)

All of those transactions don't have to be confirmed in the blockchain, but they would have to manage the mempool tx eviction policies of nodes. And some of the adversary transactions would have to be confirmed, paying a high fee. This active attack would also be very evident to attentive users.

A more realistic scenario is a larger proportion of adversary surveillance nodes and a lower transaction count. What happens when 50% of nodes belong to the adversary and the average tx count per node is just 1? Since you provide the code on GitHub (thanks!), I suppose I could try out different assumptions.

No Wallet Left Behind Meeting today at 1800 UTC in Matrix room.

Yes, the calculations you have performed are in a sense correct, and portray that an adversary may eventually observing large transactions.

But as you could rightly recognize there is more to the learning that just the number of honest nodes

The number of adversary nodes in the network has an influence as well.

For example, if you have a network of 3000 nodes in total with 300 adversary nodes and 2700 honest ones, you will ideally not need to know the connections for all the 2700 honest nodes, because some of them will be connecting to adversary nodes and you will already learn something about the privacy subgraph without sending any transaction at all. For the remaining ones, the adversary would have to perform

the diffusion analysis, bu the number will be less than 2700, maybe 2550 or in the worst case 2400.

If you increase the adversary to 50%, then I believe most of the privacy subgraph will already be known to the adversary

Also keep in mind, that my assertion above is based on certain assumptions about how Dandelion++ is implemented. Specifically, I assume that the privacy subgraph is roughly 4-regular as described in the original paper

So, every node should have 2 outgoing connections in the monero p2p network.

Right. But knowledge of the private subgraph itself is not the target of the adversary. The IP origin of each transaction is the target. So it would still be useful to know how much an adversary could know if it controlled a very large share of the nodes. (The possibility that multiple adversaries are operating would put a limit on the share that each of them could control, of course.)

Thatś correct! adversaryś eventual goal is to now the IP of each transaction. But, for that analysis, the knowledge of the privacy subgraph is important.

*know

I personally am open to changing the Dandelion++ parameters as suggested by your section VII-E if it would improve Monero's privacy. At this point in time I think the attack in the paper is not very feasible to carry out against the Monero network.

Thanks for writing the paper! You're presenting it at a conference soon, right?

If you need funding for research that would improve Monero, you can apply for a grant at monerofund.org/apply_research

I will read more about monero p2p network and will let you know my views as well. From what I know of the p2p structure of monero, I think its much more flexible in terms of the outgoing connections which can be high (>250), in comparison to Bitcoin which limits it to 8 outgoing + 2 anchor. So the analysis and the conclusions can slightly change. Nevertheless, I will look into it in more detail and would

be happy to contribute in any constructive way I can.

And yes, the work will be presented at NDSS 2023. Would be great to chat in person if you are also planning to visit.

For listeners, the paper we are discussing is Sharma, P. K., Gosain, D., & Diaz, C. (2022). "On the anonymity of peer-to-peer network anonymity schemes used by cryptocurrencies. "

Regarding the changes suggested in Section VII-E, they were a bit Bitcoin specific, but as I said, I will relook into the monero p2p network in detail and get back to you.

To me, it makes sense to check applicability to Monero since it is the only major cryptocurrency that actually implements D++. Bitcoin doesn't implement it -- not in every node, at least.

I totally agree with you and it is one of the top priority todo I have.

:)

Unfortunately many things in Monero are not formally documented. They are "documented in the source code". You can ask in this room specific questions and the developers could answer.

I won't be at NDSS 2023, but I wish you luck!

*wonders how many nodes broadcast new TXs over i2p / tor*

@Rucknium[m], Yes, was planning to look at the source code to learn more about the p2p implementation. I also know about the paper ¨Exploring the Monero Peer-to-Peer Network¨ by Cao et al. Is this a good resource to look for some structured information and then following up in the code for details?

p2p_anon: I _think_ it's a good resource, but I cannot really read the C++ code to check if it's accurate. #monero-dev:libera.chat is another good room if Monero developers don't answer here.

Cao et al. (2020) said that they were going to release the node scanning tools "soon", but I wasn't able to find them. endor00 wrote a node scanner: github.com/endorxmr/monero-node-p2p-scanner It tends to fail with an error if you set the node search count too high.

There's this short paper that analyzes the feasibility of eclipse attacks against Monero nodes: moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=132

I believe that vtnerd was responsible for most of the Dandelion++ implementation in Monero: github.com/monero-project/monero/pulls?q=dandelion

endor forked a node scanner written by dsc_

(technically py-levin is supposed to be an implementation of the levin protocol, though only the basic handshake+peer retreival is fully implemented)

<Rucknium[m]> "Cao et al. (2020) said that they..." <- btw you can just set the limit to 500 or so and then run it multiple times in a row - all the results will be cumulatively saved in the same output file

I tried to run a full scan of the network and got ~40k peers in total (where a peer is an (ip:p2p_port) pair), though approximately ~10k of those are what I call "fake" nodes (i.e. I believe it's the same node, advertised under thousands of ip:port combinations); not sure if it's just someone doing some experiments, or something actually malicious though

<merope> "I tried to run a full scan of..." <- Are these 10k IPs under a few asn? Maybe you can give more details on it so these rouge networks can be blocked

Yep, they are all under a few /24 ranges. Three of these ranges (with the majority of these weird peers) belong to AS54098 cidr-report.org/cgi-bin/as-report?as=AS54098&view=2.0 , the other two-three were Hetzner's iirc

These are the most obvious ones that I found just by eyeballing the results. Some of these ranges have 3-4k nodes each. There is definitely a pattern: they always have p2p ports like 18080, 18180, ..., 18580, 19080, ... 19590

Some of them also list an rpc port as well (again, following a similar pattern as the p2p ports), and some of them are pruned (always the same pruning seed, 387)

And pretty every single one I've tried to contact via rpc (by hand) is unresponsive/dead

<merope> "Yep, they are all under a few /2..." <- Should report to herzner, they don’t allow crypto nodes ; if they don’t go offline anytime soon then it’s a state actor

Like I said, they all seem to be dead

Though I have not yet tried going through all of these "weird" peers yet, so there might be some live ones

I have no idea why they show up in peerlists so much. One of the next steps I'm considering is to create a visual network graph, to see if it's just a handful of nodes sharing these weird peers, or if they're more widespread

Though I'm not very well-versed in analyzing p2p networks, so if you have better ideas then go for it

I'm also not familiar with monerod's peer-sharing policy, so I don't know if it just sends every peer that it has ever known, or just the "white" peers, or a subset of these (like i2p), or whatever else

There are a number of different metrics for node/vertex connectivity in graph theory. Probably a better idea than trying to visualize the whole graph.

the dandelion++ epoch is indeed 10-10.5 minutes

the number of outgoing stems, fluff probability, and embargo timeout should all be tunable from that config file

so you could run a mini-experiment on some isolated testnet if you needed to see how different parms changed semi-real world results

unfortunately the simulations are probably always sub-optimal but far easier to analyze than whatever the crazy monero p2p network is really doing

because we know that there were definitely some kind of node variants connecting to the network in the past - perhaps a ground-up variant too (moo may have more details on those attacks)

someone did a test on a mimblewimble chain - grin? - and showed that the network was so small he could run 90% of the nodes and then ruin grin privacy pretty good

their situation was different though, because they were hoping to use d++ to merge txes into a larger tx to obscure the tx graph

this was their attempt to have ring-signature like effects but interactive (and more compact since it was merging only real spent coins)

basically it failed because even if he couldnt determine the source ip, it was enough to "see" the isolated tx before it got merged by an honest node

interesting research by just some random person

Thanks, vtnerd

evening sirs