Git-Mirrors/monero-ccs-proposals
1
0
Fork 0
mirror of https://repo.getmonero.org/monero-project/ccs-proposals.git synced 2024-10-01 01:35:55 -04:00
Code Issues Packages Projects Releases Wiki Activity
42238a4f55
monero-ccs-proposals/jeffro256-full-time-2023Q3.md
luigi1111 3d09f82cf3 Update jeffro256-full-time-2023Q3.md - ms2
2023-09-12 19:15:13 +00:00

4.0 KiB
Raw Blame History

layout title author date amount milestones payouts
wip jeffro256 full-time development 2023Q3 jeffro256 May 30, 2023 147
name funds done status
Month 1 33% (49.0) 3 August 2023 finished
name funds done status
Month 2 33% (49.0) 7 September 2023 finished
name funds done status
Month 3 33% (49.0) unfinished
date amount
16 August 2023 49
date amount
12 September 2023 49
date amount

What

I plan to work full-time to work towards accomplishing:

  1. Implementing Seraphis wallet code with Ukoe, jberman, et al.
  2. Drafting a formal specification for decoy selection and implementing it in a modular, robust, easily-testable way, and then creating a multitude of unit tests, integration tests, and statistical checks for this code.
  3. Reviewing other Monero core PRs, especially those related to Seraphis or @vtnerd's serialization changes.

To expand on point 2, I think the decoy selection code is in need of a makeover. In light of recent, high-impact decoy selection bugs (more info here and here), and whereas ring signatures are generally regarded as the weakest link in Monero's privacy model, I believe a new development initiative needs to take place to replace the decoy selection code. Typically I am against refactoring code "just because", but in this case it is warranted. All of the aforementioned bugs could have been spotted by statistical checks. However, currently, it is rather difficult to test the decoy selection in isolation due to the monolithic design of wallet2. In theory, decoy selection code could be written to be rather functional. To over-simplify, we take distribution of enotes on-chain usable for given for true spends, apply arbitrary picker distribution, then request information for selected decoys over RPC, retrying the process if enotes are blackballed or otherwise unsuitable. There are a lot of edge cases to consider, but there isn't any major reason why decoy selection can't be modularized and standarized apart from the rest of the wallet code. This goal also overlaps with point number 1, since this code can be used not only in wallet2, but in future versions of core wallets if written correctly.

Who

I have been contributing to the Monero core repository for over a year with a total of >=48 merged commits thus far. Some more notable contributions:

  • Implemented research issue 109 by authoring a PR that, when spending coinbase enotes, chooses coinbase enotes as decoys and vice versa.
  • Implemented a requested wallet transfer feature that enables "fee-included" transactions
  • Found and fixed an issue which nearly allowed a double spend bug, and could cause double spend bugs in the future if the code was not carefully inspected
  • Helped review patch and write disclosure report on recent decoy selection bug.

Previous Proposals:

Payment

I propose to work 40 hours/week for 3 months so 480 hours total. I'm setting my hourly rate at ~$43/hour, and at a price of $140/XMR (as of June 10th 2023), this makes for a total of 147.4 XMR. The proposal is broken into 3 milestones, one for each "month". These milestones may lag behind schedule if I do not complete 40 hours per calendar week, but in that event, I will not ask for payout until the hours are done.