Rucknium Statistical Research

What

I propose to carry out statistical research to improve Monero's privacy, guide protocol decisions, and respond to Monero developer requests for statistical analysis of code changes where needed. In the short term I will complete in-progress analysis of the suspected transaction spam attack to provide a comprehensive view of the options to defeat this attack and possible future ones. This involves producing a Monero Research Lab research bulletin from the draft of "March 2024 Suspected Black Marble Flooding Against Monero: Privacy, User Experience, and Countermeasures". I will work with ArticMine to evaluate changes to ring size, fees, and block size scaling parameters to balance privacy, usability, and decentralization. Some items to complete the draft research bulletin:

• Derive the tradeoff function between ring size and transaction fees, i.e. how does a marginal increase in each variable affect the cost to a potential attacker?
• Simulate the combined black marble attack and Dulmage-Mendelsohn decomposition from Vijayakumaran (2023) to evaluate vulnerability to chain reaction analysis.
• Estimate any changes in the real spend age distribution during the spam incident using OSPEAD techniques. Movement toward more recent outputs suggests more evidence for the spam hypothesis.
• 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).
• Finish the research literature review.

Once the black marble flood analysis is completed, I would move to other research priorities:

• PocketChange privacy evaluation
• Ring member binning
• Fee discretization and fee prediction
• Safety of adjusting the 10 block lock
• Preparation of a paper describing OSPEAD for peer review and research journal publication
• EAE/EABE attack and churning
• Network privacy through steganography

I will not be able to complete all of these projects during this work period. Research priorities can be modified at Monero Research Lab meetings due to new events or findings.

I am nearing completion of the OSPEAD improvement to Monero's decoy selection algorithm. OSPEAD probably can only be safely implemented at a hard fork boundary because multiple decoy selection algorithms being used at the same time is a potential threat to user privacy. In the short them, analysis of the suspected flood attack is a higher priority. After, I will put hours into finishing the OSPEAD CCS proposal. Then after OSPEAD I will return to putting hours into this CCS proposal.

Who

I am an empirical microeconomist. My recent contributions to Monero include:

• Discovery of a mining pool misconfiguration. Sped up average time to first transaction confirmation by 60 seconds.

• Privacy vulnerability report to Exodus Wallet about nonstandard fees. Successfully resolved.

• "Discussion Note: Formula for Accuracy of Guessing Monero Real Spends Using Fungibility Defects"

• Identification of privacy-reducing nonstandard transaction fees

• Analysis of the privacy impact of Mordinals (Monero NFTs)

• Monerotopia 2023 presentation: "A Statistical Research Agenda for Monero"

• Statistical privacy analysis of P2Pool coinbase outputs in ring signatures

• "Closed-form Expression of Monero's wallet2 Decoy Selection Algorithm"

Pull requests reviewed for statistical issues:

• wallet: mitigate statistical dependence for decoy selection within rings

• wallet2: prevent duplicate outs

• monero-serai: fix decoy selection algo and add test for latest spendable

Budget

I will work 20 hours/week for three months (13 weeks). My fiat-equivalent labour rate is the same as my previous proposal, adjusted for the lower purchasing power of the USD today: 110 USD/hour. The average daily opening USD/XMR exchange rate for the last 14 days (2024-03-15 to 2024-03-28) according to CoinGecko was 139.49.

The above numbers compute to 20 * 13 * (110/139.49) = 205.0326. Rounding down to get whole numbers for the three milestones sets the total budget for this proposal to 204 XMR paid in three milestones of 68 XMR each. This proposal expires on January 1, 2025.

References

Sharma, P. K., Gosain, D., & Diaz, C. (2023). "On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies." Proceedings 2023 Network and Distributed System Security Symposium.

Vijayakumaran, S. (2023). "Analysis of CryptoNote Transaction Graphs using the Dulmage-Mendelsohn Decomposition." 5th Conference on Advances in Financial Technologies (AFT 2023), volume 282 of Leibniz International Proceedings in Informatics (LIPIcs).

I would welcome this research, and agree it is a high priority.

However, i would really recommend finishing one CCS before starting another.

I support this research, as these are important open questions, and the recent surge in transaction volume motivates prioritization of analyzing its implications. Rucknium's previous work clearly demonstrates the technical skill and domain knowledge necessary to execute this agenda. I'm very much looking forward to the results and recommendations :)

The next community meeting will be March 30th https://github.com/monero-project/meta/issues/984

changed the description

added 1 commit

• 5a31628a - Fix typos

Compare with previous version

I think a thourough analysis of PocketChange and similar mechanisms is overdue, given that the 10 block wait is such a pain point in the view of many users. Also the 10 block wait might need a re-evaluation taking a possible arrival of FCMPs into account.

We need to keep our resident statistician :)

mentioned in commit 5b88ecc4

merged

• Derive the tradeoff function between ring size and transaction fees, i.e. how does a marginal increase in each variable affect the cost to a potential attacker?

Would it be possible to also analyze the impact of an added slight PoW to execute a tx?

Yes. @gingeropolous drafted a simulation of tx PoW as a spam countermeasure, but I can do an independent analysis: https://github.com/Gingeropolous/txsim

Thanks @Rucknium, I'll check it out. My curiosity was driven by the fact the cost in this case could not only be monetary since it also spends energy but in time as well, so even if the PoW is small enough for regular users to be unnoticeable, if for thousands of txs the "spammer" or "attacker" with possibly infinite resources can still be held back by minutes or even hours to finalize as their resources can't buy time, while it's still cheap and fast for regular users, but also there is the question if it is possible for this type of dynamic algorithm to take place without the loss of privacy

I sent 68 XMR to this proposal from the General Fund in tx 1d93e3d85916bc8d80d1f3293723631fd079f96a11bf39d38c38ab3f47d6c22b

I have completed Milestone 1.

I completed these items that were explicitly listed in my proposal:

Derive the tradeoff function between ring size and transaction fees, i.e. how does a marginal increase in each variable affect the cost to a potential attacker?

This was done in "Defeating a Black Marble Flood Against Monero: Best Options for Ring Size and Transaction Fee".

Simulate the combined black marble attack and Dulmage-Mendelsohn decomposition from Vijayakumaran (2023) to evaluate vulnerability to chain reaction analysis.

Code to perform this analysis is available here. The results were written up in version 0.3 of "March 2024 Suspected Black Marble Flooding Against Monero: Privacy, User Experience, and Countermeasures" in page 14, lines 183-203.

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).

Due to some privacy-improving changes to Monero's network code, actively seeking the source of spam was not possible. Instead, peer transaction relay logs from several nodes were collected and analyzed to build a statistical profile of the Monero network under normal conditions. I developed the xmrpeers R package to parse the logs and appealed to the Monero community to submit node logs. Analysis code is here. The results were written up in version 0.3 of "March 2024 Suspected Black Marble Flooding Against Monero: Privacy, User Experience, and Countermeasures" in pages 19-25, lines 310-434, figures 14-16, tables 1-2.

I made progress on this item that was explicitly listed in my proposal:

Safety of adjusting the 10 block lock

In a comment on "Investigate possibility of reducing 10-blocks lock", I produced tables of the success probability of a double-spend attack with minority hashpower share for two different attacker strategies.

I analyzed these issues that were not explicitly mentioned in my proposal, because they were salient and time-sensitive:

• In a comment to "Fix embargo timeout in dandelion++" I wrote a simulation that evaluated the possible RAM footprint of changing the random fluff-phase relay timers from the current Poisson distribution to an exponential distribution.

• In a comment to "[Proposal] Change how transactions are broadcasted to significantly reduce P2P bandwidth usage" I evaluated the possible privacy impact of allowing permissionless querying of nodes' fluff-phase transaction pools. Using techniques from the "topology inference from cascades" research literature, there are possible attacks that a high-resource adversary could execute to reduce user privacy and the integrity of the peer-to-peer network.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I, Rucknium, request the payout for Milestone 1 for
https://ccs.getmonero.org/proposals/Rucknium-Statistical-Research.html
to this Monero address:
8Bv4xnUFXVzcdsu9yfDfsRUfFqA3ciTMc7iQeQAzkoe8M6neSmXVFtF8YwpaJwQeMqh8JWLatjimQgyZyDafNFAGM5wrr1E
-----BEGIN PGP SIGNATURE-----

iQJMBAEBCgA2FiEEXV4Iojid8iWr0HgbKR4MIp1jFpcFAmcHwcAYHHJ1Y2tuaXVt
QHByb3Rvbm1haWwuY29tAAoJECkeDCKdYxaXX30P/iDJpAN6EQ7NVFqMo3Z3ChsS
Sjlfwyh5LfVNAu+gdfymZtKPMflnL6MxdmZXo8RojdZj/kwuVfPlmJvHxuXJl1xk
9rM1f7hE5V9gjM30SUNqoD1uHBqxB/wdss/Ztq/2HwQfm28UtG4QZnKdur78blul
usXJezGCl973+qdlVIF23YTAP1ApKb/PyNW86SoPdPsafTUQwlnEdhh9rOw+SpPl
SsD5fSrHWuH2a8MuOGdgPziLE2ijCbmpbl2xTjd5RjrYFMwl1onTRMbQECtPwS1M
bSPtLf2qBIwo5YQ+sLo5gVEHsXrXh2Z5+QZlqtl0duOJSQutVN2HijKcr9AWU3BU
KJnebyhEdcQ7CiI3VXowza2abILTFUnzHFaa4PCEu9JBPONLK7LxbQAWPD+x5YGB
k7EccoOvVT4Obv6Q3TEjdy5S0y1x6w9ZGfwbVUcfm70Ka0O+TFI9fbb93syP1mFC
D88OYJvKqsMBzca9omEq8rXOB3QYCG01/YBNE2oWNWoXuWdcQw0MDIBRXoRnlESU
tNv6DyzcHzkUaGrow05CBZmY2HxbhW6jMQuC0ePhZdyeNsGwSOlwRd4NUXm8WjOX
aaIImTa5wXPySDL8eWhwKx7GRR7Qogns/Ee5MFYrnIL4rzgihjPBC+0b58NsNn4T
8N1rCbJ1o3KQwNzWNZ7h
=f68+
-----END PGP SIGNATURE-----

I have completed Milestone 2. Work items:

• With @Boog900 , investigated the empirical privacy impact of suspected spy nodes and organized a public campaign to urge Monero node operators to ban suspected spy nodes from connecting to their nodes.

• Wrote draft of "Subnet Deduplication for Monero Node Peer Selection" research note as a longer-term solution to spy nodes.

• Researched response to HackerOne vulnerability report #2864144 (still undisclosed).

• Released a technical review of Goodell, Salazar, & Slaughter (2024). "Uniformly Most Powerful Tests for Ad Hoc Transactions in Monero"

• Created documentation website and new functionality for xmrpeers R package.

• Discovered nonzero unlock time transactions confirmed on the blockchain despite release of monerod version prohibiting relay of transactions with nonzero unlock time.

• Performed an empirical analysis of the likely impact of restricting the maximum number of transaction inputs after FCMP activation.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I, Rucknium, request the payout for Milestone 2 for
https://ccs.getmonero.org/proposals/Rucknium-Statistical-Research.html
to this Monero address:
8Bv4xnUFXVzcdsu9yfDfsRUfFqA3ciTMc7iQeQAzkoe8M6neSmXVFtF8YwpaJwQeMqh8JWLatjimQgyZyDafNFAGM5wrr1E
-----BEGIN PGP SIGNATURE-----

iQJMBAEBCgA2FiEEXV4Iojid8iWr0HgbKR4MIp1jFpcFAme0dkAYHHJ1Y2tuaXVt
QHByb3Rvbm1haWwuY29tAAoJECkeDCKdYxaXzfAP/RqClt7iBJ10d1dlXIyBT3gH
E0f+VpdieiksBCboy+Q+6q9FsrvtP+QtD7pHdVvLSccMVf/m18FFifGAhmiGtpo9
CALuaGm4yP7mv2XfX7ASrT/we/oBHmsPHr+6MIsmtasnAtMq3uZlXUYsFXHsz5LD
sWz4Q5MXYxDi57F48EAcDP3H0S8bHZcXrFON7JwgH6s24zlEBexXIpO0rPcbuebc
mHJyz0u2Qywf1EKRceo+0eXU5fyJnc8owC+Oje/IAV+XU77gqBymaPVMo9mJNZfT
6avzYnQ4eIGorHash101n6RxBVqtAjUXNDAA6p+ZrtMgFwAui2GWa5k2eegXUJG1
MLFIig6nR1BEphQ84oHHIxo5ecEL8AMkEPw10h6POe+EHEzz5KMM0XSRfbrDot+u
cMd5MXEzUngnqm3Keavu/gV5QXxgiQGEwg+mH73kGXCyP7fd3XNqBPgjxo5P9M8c
nZvUzlVlsz6v/8Lx/v0IP7JrHQtMgYz0vvAym3SqAD0GdCw+A9F91zVFdXSG8Wfk
tNqUr/4eeHfH1JuM7WSUpWic5itbQvYFBTcV9/1adAEwUAn/z5IQwXhYlSbyM3Ys
LJUT1KSDSLKvb21tptFkH6ek7vxt6GlhrnYbt1HUz6nlU6pKlsdy23xWbKEt3wSF
t2sEfgT7horlO6CNsz6o
=awu6
-----END PGP SIGNATURE-----