<h3>Funded goal: 28,800 USD</h3>
<h3>Start: February 2024</h3>
<p>vtnerd (Lee Clagett) is the author of <a href="https://github.com/vtnerd/monero-lws">Monero-LWS</a>, and has been a <a href="https://github.com/monero-project/monero/pulls?page=7&#x26;q=is%3Apr+author%3Avtnerd+created%3A%3E2016-10-01">contributor to the Monero codebase since 2016</a>. He is a veteran of four CCS proposals; <a href="https://ccs.getmonero.org/proposals/vtnerd-tor-tx-broadcasting.html">[1]</a>, <a href="https://ccs.getmonero.org/proposals/vtnerd-2020-q4.html">[2]</a>, <a href="https://ccs.getmonero.org/proposals/vtnerd-2021-q1.html">[3]</a>, <a href="https://ccs.getmonero.org/proposals/vtnerd-2023-q3.html">[4]</a></p>
<p>This proposal funds 480 hours of work, ~3 months. The milestones will be hour based; 160 (1 month), 320 (2 months), 480 (3 months). At the completion of hours, he will provide the Monero Fund committee references to the work that was completed during that timeframe.</p>
<p>Some features that are being targeted in <a href="https://www.github.com/monero-project/monero"><code>monero-project/monero</code></a> :</p>
<ul>
<li>Get new serialization routine merged (work on piecemeal PRs for reviewers sake) (already in-progress)</li>
<li>Complete work necessary to merge DANE/TLSA in wallet2/epee.</li>
<li>Adding trust-on-first-use support to wallet2</li>
</ul>
<p>Work targeted towards <a href="https://github.com/vtnerd/monero-lws"><code>vtnerd/monero-lws</code></a> :</p>
<ul>
<li>Optional full chain verification for malicious daemon attack (already-in progress)</li>
<li>Webhooks/ZMQ-PUB support for tx sending (watch for unexpected sends)</li>
<li>ZMQ-pub support for incoming transactions and blocks (notifies of any new transaction or block)</li>
<li>Implement "horizontal" scaling of account scanning (transfer account info via zmq to another process for scanning)</li>
<li>Make account creation more "enterprise grade" (currently scanning engine re-starts on every new account creation, and uses non-cacheable memory) * Unit tests for REST-API</li>
<li>Create frontend LWS C/C++ library</li>
<li>Provide official LWS docker-image</li>
<li>Provide official snap/flatpak/appimge (tbd one or all of those)</li>
<li>Provide pre-built binaries</li>
<li>(Unlikely) - reproducible builds so community members can verify+sign the binary hashes</li>
<li>It is unlikely that all features will be implemented, at which point the unfinished features will roll into the next quarter.</li>
</ul>


This development work will improve security, performance, and usability with an end goal of helping to broaden the user base. 

vtnerd Monero and Monero-LWS dev work for Q1/Q2 2024

### Funded goal: 28,800 USD
### Start: February 2024

vtnerd (Lee Clagett) is the author of [Monero-LWS](https://github.com/vtnerd/monero-lws), and has been a [contributor to the Monero codebase since 2016](https://github.com/monero-project/monero/pulls?page=7&q=is%3Apr+author%3Avtnerd+created%3A%3E2016-10-01). He is a veteran of four CCS proposals; [[1]](https://ccs.getmonero.org/proposals/vtnerd-tor-tx-broadcasting.html), [[2]](https://ccs.getmonero.org/proposals/vtnerd-2020-q4.html), [[3]](https://ccs.getmonero.org/proposals/vtnerd-2021-q1.html), [[4]](https://ccs.getmonero.org/proposals/vtnerd-2023-q3.html)

This proposal funds 480 hours of work, ~3 months. The milestones will be hour based; 160 (1 month), 320 (2 months), 480 (3 months). At the completion of hours, he will provide the Monero Fund committee references to the work that was completed during that timeframe. 

Some features that are being targeted in [`monero-project/monero`](https://www.github.com/monero-project/monero) : 

* Get new serialization routine merged (work on piecemeal PRs for reviewers sake) (already in-progress)
* Complete work necessary to merge DANE/TLSA in wallet2/epee.
* Adding trust-on-first-use support to wallet2

Work targeted towards [`vtnerd/monero-lws`](https://github.com/vtnerd/monero-lws) : 

* Optional full chain verification for malicious daemon attack (already-in progress)
* Webhooks/ZMQ-PUB support for tx sending (watch for unexpected sends)
* ZMQ-pub support for incoming transactions and blocks (notifies of any new transaction or block) 
* Implement "horizontal" scaling of account scanning (transfer account info via zmq to another process for scanning) 
* Make account creation more "enterprise grade" (currently scanning engine re-starts on every new account creation, and uses non-cacheable memory) * Unit tests for REST-API
* Create frontend LWS C/C++ library 
* Provide official LWS docker-image 
* Provide official snap/flatpak/appimge (tbd one or all of those) 
* Provide pre-built binaries 
* (Unlikely) - reproducible builds so community members can verify+sign the binary hashes
* It is unlikely that all features will be implemented, at which point the unfinished features will roll into the next quarter.


### Funded Goal: 220 XMR (86 XMR contributed from MAGIC Monero Fund general fund)
### Start: June 2023
### End: September 2023
### Result: [Research paper](/pdf/Borggren-Sept-2023-Probing-the-Attacks-on-the-Privacy-of-the-Monero-Blockchain.pdf)

The EAE (Eve-Alice-Eve) attack is a threat to Monero user privacy. When a Monero user sends and/or receives funds repeatedly with an entity (Eve) that aims to trace funds, enough information in the local transaction graph and ring signatures may be available to make a probabalistic guess about the true destination or source of funds. There are different names for this attack and related attacks, which mostly differ in how many colluding entities are involved and how much information they may possess: EABE, poisoned outputs, Overseer, Flashlight, Tainted Dust, and Knacc attacks. One of the videos of the Breaking Monero series [discusses the EAE attack in detail](https://www.monerooutreach.org/breaking-monero/poisoned-outputs.html).

The EAE attack has been a concern of the Monero Research Lab for years, but rigorous measurement of the possible risk of this attack and possible defenses against it have not been successfully researched. "Churning", the practice of users sending funds to themselves, has been suggested as a possible defense, but neither its effectiveness nor details about best churning procedures have been determined by research to date.

Dr. Nathan Borggren has stepped up to investigate these important research questions about how to best protect Monero user privacy. Dr. Borggren is lead author of two papers about possible statistical threats to Monero user privacy: Borggren & Yao (2020) ["Correlations of Multi-input Monero Transactions"](https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=57) and Borggren et al. (2020) ["Simulated Blockchains for Machine Learning Traceability and Transaction Values in the Monero Network"](https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=58). His work analyzing transparent blockchains includes Borggren et al. (2017) "Deanonymizing Shapeshift: Linking Transactions Across Multiple Blockchains" and Borggren (2017) "Deep Learning of Entity Behavior in the Bitcoin Economy".

Dr. Borggren has proposed using Topological Data Analysis and Bayesian statistical methods to analyze the EAE attack and related attacks on Monero user privacy. The false positive and false negative rate of the EAE attack will be investigated through simulations and possibly analysis of Monero's mainnet blockchain. The full details of the plan are in [the research proposal](https://github.com/MAGICGrants/Monero-Fund/blob/main/projects/borggren_research-MAGIC-submission.pdf).


> "I think that the EAE attack is one of Monero's biggest *practical* attack surfaces currently, and I see value in quantification plus real world data-informed best practices."

&mdash; [isthmus](https://github.com/Mitchellpkt), Monero Research Lab researcher and lead author of ["Fingerprinting a flood: Forensic statistical analysis of the mid-2021 Monero transaction volume anomaly"](https://mitchellpkt.medium.com/fingerprinting-a-flood-forensic-statistical-analysis-of-the-mid-2021-monero-transaction-volume-a19cbf41ce60)

> "Borggren has previously released fascinating papers quantifying Monero privacy pitfalls and I'm excited he is looking to continue."

&mdash; [ACK-J](https://github.com/ACK-J), author of ["Lord of the Rings: An Empirical Analysis of Monero's Ring Signature Resilience to Artifically Intelligent Attacks"](https://raw.githubusercontent.com/ACK-J/Monero-Dataset-Pipeline/main/Lord_of_the_Rings__An_Empirical_Analysis_of_Monero_s_Ring_Signature_Resilience_to_Artificially_Intelligent_Attacks.pdf)


The EAE attack is one of Monero's privacy weak points. Churning may be a solution.

Research to Defeat EAE Attack and Analyze Effectiveness of Churning Procedures

### Funded Goal: 24,000 USD (5,000 USD contributed from the MAGIC Monero Fund general fund)
### Start: September 2022
### End: August 2022
### Result: [Mainnet beta software release](https://reddit.com/r/Monero/comments/1382rva/ethxmr_atomic_swap_beta_release/)

The MAGIC Monero Fund raised funds for noot to continue development on ETH-XMR atomic swaps. View [the campaign here](https://www.gofundme.com/f/noot-ethxmr-atomic-swap-development-4-months).

This proposal covers 4 months of work focused on the following:

### Relayer support

The current implementation of the protocol requires the ETH-recipient to have some ETH in their claiming account to pay for the transaction fees to claim the swap ETH. However, this is bad for UX and privacy, as users cannot withdraw to fresh ETH accounts.

To allow for users to claim ETH into a fresh account, integration with a relayer service can be implemented. This will allow users to withdraw to a fresh account by paying a small fee to a relayer to submit the transaction on their behalf.

### Ethereum privacy improvements

On the ETH side of the swap, there is no privacy, and which accounts and amounts participating in the swap are visible.

### ERC20 support

To support swaps for ERC20s without hurting liquidity, the swap contract can be integrated with a DEX such as Uniswap to automat-ically swap received ETH for the desired ERC20 token.

### Disk permanence

The current implementation of the swap does not store anything to disk apart from information needed for recovery of swap funds in case of failure. However, there are other components that should be stored to disk and restored upon reload, such as current swap of-fers made, historic swap information, and peer information. This will require a simple key-value database implementation.

### General maintenance and bugfixes

See https://github.com/noot/atomic-swap/issues for open issues on the repo. Issues not covered by the above work are part of this sec-tion. This includes RPC calls and documentation, codebase maintenance, testing, and fixes of any bugs found during testing.





A trustless way to exchange Monero and Ethereum.

ETH<>XMR Atomic Swap Continued Development

### Funded Goal: 12,000 USD (12,000 USD contributed from MAGIC Monero Fund general fund)
### Start: March 2022
### End: August 2022
### Result: [Research paper](https://raw.githubusercontent.com/ACK-J/Monero-Dataset-Pipeline/main/Lord_of_the_Rings__An_Empirical_Analysis_of_Monero_s_Ring_Signature_Resilience_to_Artificially_Intelligent_Attacks.pdf)

ACK-J created a series of Monero transactions using different spend patterns and applied artificial intelligence models to determine the resiliency of ring signatures against these models, absent external information. The MAGIC Monero Fund approved the research grant from its general fund.

The full paper "Lord of the Rings: An Empirical Analysis of Monero's Ring Signature Resilience to Artifically Intelligent Attacks" is available [on the author's GitHub](https://raw.githubusercontent.com/ACK-J/Monero-Dataset-Pipeline/main/Lord_of_the_Rings__An_Empirical_Analysis_of_Monero_s_Ring_Signature_Resilience_to_Artificially_Intelligent_Attacks.pdf), along with [the accompanying dataset pipeline](https://github.com/ACK-J/Monero-Dataset-Pipeline).

The transcript of a short inverview with ACK-J discussing the results is [here](https://magicgrants.org/Monero-Tracing-Research/).

## Main results

With 11 ring members, public information on the Monero blockchain could aid an attacker in predicting the true spend of a transaction greater than the random guessing probability of 9% (1/11). With this model, the likelihood of a correct guess grew to 13.3%, a modest increase. Since the data was collected, Monero increased its ring size to 16; thus, the accuracy should now be lower, but we do not have numbers for this.





A test of machine learning attacks on Monero's untraceability.