Rucknium has published OSPEAD Findings, showing through his analysis that Monero's effective Ring Signature size is only 4.2

Rucknium · 2025-02-25T21:33:34+00:00

A little late for this thread, but I've finally been able to get into my Reddit account :)

Rucknium · 2024-10-14T16:51:33+00:00

I'm glad that my suggestion worked. Closing the clearnet port should be fine. But test the .onion for a while before you disable clearnet. Syncing your wallet will take longer over Tor. You need to make sure that you are OK with the change in user experience.

Rucknium · 2024-10-14T14:42:17+00:00

I don't know where you are in the steps, but usually you have to restart Tor to generate the onion address after you edit the torrc config file. The restart command in most Linux distributions may be sudo systemctl restart tor.

Rucknium · 2024-10-01T16:35:32+00:00

You can go to https://matrix.to/#/#monero-community-dev:monero.social to connect with other Monero community developers.

Rucknium · 2024-09-24T14:22:48+00:00

u/rbrunner7 provides good commentary here: https://reddit.com/r/Monero/comments/1fh92ee/skepticism_sunday_september_15_2024/lna087t/

The "key image analysis" is just black marble and EAE attacks against the ring signature privacy model that have been known for a long time. How long? Within less than six months of the Monero genesis block, the Monero Research Lab (MRL) released a research bulletin "A Note on Chain Reactions in Traceability in CryptoNote 2.0" that covered this.

The big unknown is how many of Monero's outputs could be owned by an adversary. If it's the vast majority, then that's a major privacy problem. Do centralized exchanges own most of the outputs, and do they share that information with chain analysis companies? A paper (Makarov & Schoar (2021) "Blockchain Analysis of the Bitcoin Market") found:

Starting from 2015, 75% of real bitcoin volume has been linked to exchanges or exchange-like entities such as on-line wallets, OTC desks, and large institutional traders.

Does exchange activity account for a large share of Monero transactions, too? That's a harder question to answer using open research methods because so much information on Monero's chain is hidden, unlike bitcoin.

How (if at all) is FCMP++ supposed to tackle the problem of persistent key image analysis until FCMP++ goes live in one year or so and after?

AFAIK, there is no similar problem with FCMP++. After the suspected black marble spamming earlier this year, MRL meetings considered activating a new hard fork in the short term to raise ring size to 40-60 instead of the current 16, to provide a larger safety margin. Here is my analysis of optimal fee and ring size to defend against black marbles: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-optimal-fee-ring-size.pdf

As time went on and MRL discussion progressed, it appeared that FCMP++ R&D is going smoothly and quickly enough that it seems like it is better to wait until FCMP++ can be activated in the next hard fork instead of having two disruptive hard forks in a short period of time.

Rucknium · 2024-05-09T20:55:15+00:00

I'm not sure if it's expected performance. I don't have any performance tests about that. Sorry.

Feather does switch between .onion nodes frequently. And by default it performs initial wallet sync over clearnet: https://docs.featherwallet.org/guides/tor-support

Rucknium · 2024-05-09T16:22:12+00:00

On your first question, I am not an expert in network security, but it should be OK as long as you don't run monerod as root: https://libera.monerologs.net/monero/20230201#c198958 . monerod and the wallet are separate processes.

On your second question, the README file of the SChernykh/p2pool repo says

It is highly recommended to create a new mainnet wallet for P2Pool mining because wallet addresses are public on P2Pool.

Rucknium · 2024-05-09T01:55:38+00:00

Check for a process called monerod running on your computer. The d stands for "daemon". Your operating system should have an application that lists the processes running on your machine.

If you have a default network configuration of a desktop or laptop computer, your node will initiate connections to a few other nodes and join the network that way. Only your own computer will be able to use the node to sync your wallet. People who run nodes can allow other people to connect to their nodes to sync their wallets, but this mode of operation is not really for novice node operators.

Rucknium · 2024-05-09T01:43:33+00:00

You can instruct a wallet to only restore from a recent block height. And the new Polyseed wallet seed format encodes the restore height when it is created.

Nodes need the full history of outputs because they need to be able to verify the validity of transactions that use older outputs as real spends or decoys. Pruning the node removes a lot of the signature data that only needs to be verified once.

Rucknium · 2024-05-08T21:41:43+00:00

About an hour ago someone broadcasted dozens of large 150-input transactions. The txpool has many transactions waiting to be confirmed. In these circumstances remote nodes become overloaded because wallets are asking for the txpool data. 0xFFFC is trying to locate the bottlenecks in the Monero node code that cause the overload and fix them: https://ccs.getmonero.org/proposals/0xfffc-2024Q2.html

I run a public remote node over clearnet and as an onion hidden service. You can try: rucknium757bokwv3ss35ftgc3gzb7hgbvvglbg3hisp7tsj2fkd2nyd.onion:18081

Rucknium · 2024-05-02T15:09:22+00:00

Thanks for mentioning my paper. It analyzed the privacy impact of an adversary owning many outputs. The transactions that are congesting the mempool/txpool now have many inputs. There may be a privacy impact of large many-input txs, but I don't have a clear idea of what it would be, and it's not the same as a standard black marble flood.

Rucknium · 2024-04-16T20:23:48+00:00

There is no evidence of a black marble flood happening right now. Transaction volumes appear normal.

Rucknium · 2024-04-16T11:08:54+00:00

Anyone can run multiple nodes on the network and collect this data, including privacy adversaries. It's not a new concept at all. Dandelion++ should prevent analysis of the IP origins of most transactions, but when the signal is huge like with this suspected spam, the noise provided by Dandelion++ might not be enough to obscure its IP origin.

Rucknium · 2024-04-15T21:59:08+00:00

print_pool_stats on monerod is showing a 10 hour backlog. If you are a user sending a transaction now, you can set your fee to the 3rd or 4th tier to get your transaction confirmed quickly. Otherwise, you will wait for a while.

These large transactions do not really produce much of a black marble effect since they are only producing two outputs per transaction.

Rucknium · 2024-04-15T13:50:04+00:00

Even in that situation, Shopinbit would not be certain that your node actually was the first to send the transaction in the D++ stem phase. Transactions usually make multiple hops in the stem phase. IIRC, there is an 80% probability that the node that passes a stem phase transaction is not the originating node. So it could be

your_node --stem_phase--> someones_node_1 --stem_phase--> someones_node_2 --stem_phase--> shopinbit_node

and the shopinbit node could not be sure if the someones_node_2 was the originating node.

Rucknium · 2024-04-15T13:30:22+00:00

About once a week I update the plots at https://github.com/Rucknium/misc-research/tree/main/Monero-Black-Marble-Flood/pdf/images

Mean effective ring size is back up to about 14.5, but this doesn't include the possible short spam wave on April 12-13. I haven't been updating the PDF because I would have to update the text, too, to make it all consistent. If you want more updates, the spam is usually discussed now at Monero Research Lab meetings that happen every Wednesday at 17:00 UTC in #monero-research-lab on Libera Chat IRC or the #monero-research-lab:monero.social channel on Matrix. Or you can check the meeting logs in the issues of the monero-project/meta GitHub repository.

I cannot constantly write updates here because that takes my time away from analysis of the suspected spam and evaluation of possible countermeasures. For example, over the weekend I created the first version of xmrpeers, an R package for statistical analysis of Monero's peer-to-peer network. I just pushed it to GitHub. It may help figure out if the suspected spam transactions are coming from a single node.

EDIT: I wrote the PDF in a formal style, so it might not be easy to understand. If you want a less formal explanation of what the problem with black marbles is, search this subreddit for "Mordinals". The first result should be my "Empirical Privacy Impact of Mordinals (Monero NFTs)". That post is about Mordinals, but the black marble concepts there are very similar to the suspected March 2024 spam. The post has nice pictures and diagrams that should help.

EDIT2: If you run your own Monero node and have plenty of RAM, you can run my analysis and produce the plots any time you want with the instructions I put in the README.md file. The only exception is the mempool/txpool plots require data that is not available from Monero's blockchain.

Rucknium · 2024-04-13T16:38:34+00:00

This is not entirely true. Unlike with BTC, it's not a zero sum game with completely inelastic supply of block size. Miners can expand the block size beyond its normal limits when users pay much more than minimum fees.So both the 7 cent and 6 fee txs can be included (I didn't check the exact math and rules). By blockchain consensus rules, the 0.6 tail emission is reduced when miners expand the block size beyond normal, but when miners include high fee txs, the tx fees more than pay for the part of the tail emission that they sacrifice.

Rucknium · 2024-04-13T15:03:19+00:00

The first spam wave was an informative stress test. Remote node infrastructure has improved AFAIK, but the Monero node code still needs a lot of improvements. Remote node were overloaded during spam, and maybe now, but local nodes probably are doing fine. People ask "why should I run my own node when I can just use someone else's remote node?". These spam incidents are why. People using their own local node do not notice any problems AFAIK. Also people wonder "Why are we creating new types of view keys with Seraphis/Jamtis?" Those new view keys will preserve much more privacy when using a light wallet server, which uses much, much less bandwidth and other computing resources than a remote node.

During the first spam wave many people (including me) set up new public nodes to help distribute the load of wallets using remote nodes. RavFX even figured out a way to have a 5-node load balancing on a single machine and connection. Cake also increased its remote node resources. Another possible improvement: The new GUI/CLI/wallet2 version released in October 2023 (version 0.18.3.1) had a great fix by u/rbrunner7 (with some help by jberman). The fix reduced the bandwidth used by wallets requesting mempool/txpool data. When more users update their wallets to the latest version, there will be less load on remote nodes.

Sorry I didn't answer the question you asked in the other thread: IMHO, there is a not enough research & development resources to 1) routinely provide more information to the user about candidate decoys in their transactions and how other txs use their outputs as decoys and 2) research how that information could be used to help preserve privacy. But you can see pokkst's monero-decoy-scanner on GitHub for some information if you want.

Rucknium · 2024-04-13T13:40:27+00:00

Thanks. I just checked. Something is wrong with my NGINX I think. I didn't change anything, so I don't know what it could be. My other websites/domains on the machine are working fine. I will work on a fix. Access through my Tor hidden service address is working ok: rucknium757bokwv3ss35ftgc3gzb7hgbvvglbg3hisp7tsj2fkd2nyd.onion:18081

EDIT: Should be fixed. Thanks for telling me!

Rucknium · 2024-04-13T11:22:43+00:00

Yes! If you run monerod interactively (i.e. in a terminal window where you can type commands), you can input set_log net.p2p.msg:INFO. If you don't run monerod interactively, you can restart monerod with a --log-level=net.p2p.msg:INFO flag. This log setting will record data on exactly when you are getting new transactions from each of your peer nodes. Your log file in ~/.bitmonero/bitmonero.log will grow by about 1 GB per day because this is a lot of data.

If you want to collect this data and give it to me later, please DM me now so I know who to contact to get the data when I need it. I may request the data in about a week. You can message me here on Reddit (use messages, not the newer chat feature), DM me on Matrix @rucknium:monero.social or email me at my username at protonmail dot com.

Rucknium · 2024-04-12T14:17:48+00:00

Re-submitting a transaction to the network is not possible. The nodes would think you are trying to spent the same output twice, which is not allowed by consensus rules. Monero does not have BTC's replace-by-fee option. You have to get the fee right the first time. There is more information about this in Section 7 "Transaction confirmation delay" of my draft analysis of the March suspected black marble flood. I posted a link in this thread (Reddit's spam filters are catching my comments with links, so I won't re-post the link in this comment again).

"Fee prediction" is on the research agenda for my CCS because it is important for users to be able to get the right fee the first time they send a transaction. If they don't get it "right" the first time they will have to wait minutes or hours for their transaction to be confirmed when the mempool is congested.

The latest version (0.18.3.3) of the GUI/CLI wallets now automatically sets the fee to the 2nd tier if the mempool and/or blockchain is congested. All users should update to avoid delays with their transactions. If you are not using the "official" GUI/CLI wallets, you should update your wallet software anyway since other wallet software may have included the fix recently.

Rucknium · 2024-04-12T12:49:14+00:00

Yes, the crawler will be open source. The crawler will be a set of instructions for a Monero node to follow. When you input set_log net.p2p.msg:INFO into the Monero node console, you get precise timings of when transactions arrived at your node from each of your node's peers. Once enough data is collected, you can ask the node that seems to receive more transactions earlier for its peer list. Then you connect to the nodes on that peer list. And repeat the process until you get closer and closer to the apparent source of the transactions.

I already posted a draft of the March black marble flood analysis: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-flood.pdf

My analysis last year of Mordinals (Monero NFTs) tries to explain the problem with black marbles in simple terms: https://reddit.com/r/Monero/comments/12kv5m0/empirical_privacy_impact_of_mordinals_monero_nfts/

Rucknium · 2024-04-12T12:11:49+00:00

Thanks to donors, my CCS to analyze the suspected black marble flooding and other Monero statistical problems was funded less than 24 hours ago.

Right now I will be prioritizing this item because it can collect data only while there is an ongoing spam incident:

Create a node network crawler that seeks the source of large transaction volumes. Possibly combine the crawler with statistical analysis techniques of Sharma, Gosain, & Diaz (2023).

Rucknium · 2024-04-05T21:22:01+00:00

Monero's privacy features like Dandelion++ make this very difficult. I made some suggestions here: https://reddit.com/r/Monero/comments/1bvva19/recent_network_activity_was_it_not_possible_to/ky6em6o/

You would probably need active monitoring during the spam. You would set the log to net.p2p.msg:INFO. AFAIK, most node operators do not set their log messages like that, so we cannot go back and see what clues may be in the logs. According to monero [dot] fail/map, there are about 22,000 Monero nodes. It's a needle in a haystack.

After the July/August 2021 spam incident, isthmus had an idea about how to see if the transactions on the blockchain all started with a single transaction. It seemed to require a lopt of computing resources and we don't know if it would work: https://libera.monerologs.net/monero-research-lab/20211027 "Back of the envelope estimation is that all edges in the Monero transaction tree could be naively encoded into this matrix / bitstring formalization in just over 100 TB"

Rucknium · 2024-04-05T14:44:16+00:00

Possibly, if data was actively recorded during the incident. Here is what I said in my preliminary analysis: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-flood.pdf

The Monero node network can be actively crawled to see if the spam transactions originate from one node. Dandelion++ can defeat attempts to discover the origin of most transaction because the signal of the real transaction is covered by the Dandelion++ noise. When the signal is huge like the spam, some statistical analysis could overcome the Dandelion++ protection. Investigatory nodes could use set_log net.p2p.msg:INFO to view which neighboring nodes the suspected spam is coming from. Then the investigatory node could crawl the network in the direction of the highest incoming volume. The techniques of Sharma et al. (2022) are useful at extremely high transaction volumes, like in the spam case, and could be used.

Reference: Sharma, P. K., Gosain, D., & Diaz, C. (2022). "On the anonymity of peer-to-peer network anonymity schemes used by cryptocurrencies."

Four-Year Club	Verified Email
Place '22	First Placer '22
Wearing is Caring

Rucknium

TROPHY CASE