Git-Mirrors/monero-ccs-proposals
1
0
Fork 0
mirror of https://repo.getmonero.org/monero-project/ccs-proposals.git synced 2024-12-18 04:14:32 -05:00
Code Issues Packages Projects Releases Wiki Activity
a12960833d
monero-ccs-proposals/j-berman-3months-full-time-4.md

6.9 KiB
Raw Blame History

layout title author date amount milestones payouts
cp j-berman full-time development (3 months) j-berman November 21, 2022 253 Monero
name funds done status
Month 1 33% (84.3 Monero) 31 December 2022 finished
name funds done status
Month 2 33% (84.3 Monero) 21 February 2023 finished
name funds done status
Month 3 33% (84.4 Monero) 16 May 2023 finished
date amount
23 February 2023 168.6
date amount
21 May 2023 84.4

What

Continue full-time another 3 months in a similar capacity:

  • Prioritize debugging any significant issues that arise, such as daemon connection issues, zmq missing publishing txs submitted to the daemon, recovering multisig wallets from seed, etc.
  • Complete work stress testing how daemons handle a transaction pool under heavy load to both gauge daemon performance, and to help get PR 8076 - reduce wallet round trips to the daemon across the finish line after gauging its impact on pool processing performance.
    • The day leading up to the hard fork this summer, the transaction pool experienced heavier load than usual. Daemons that saw heavy traffic reported issues serving RPC requests. I would like to dig deeper into this.
  • Start working through Seraphis and Jamtis wallet tasks piecemeal, picking up collaboration with @koe, @rbrunner7, and @dangerousfreedom. The first task I've gotten a handle on and have a decently fleshed out view of what work is needed is input selection. I intend to get @koe's naive input selection implementation to production-ready, ensuring it functions as close to the wallet does today. From @koe here: "a real implementation needs many more mechanisms and heuristics (e.g. filter for dust threshold to ignore, filter for origin statuses to permit, randomization and spread to mitigate timing analysis)"
    • The general plan with Seraphis/Jamtis is to start fresh with new wallet code that avoids the complexity and pitfalls of wallet2.cpp, which at the moment is a source of growing technical debt (discussed a bit here). Considering Seraphis and Jamtis would bring a number of changes to core wallet features (a new address scheme, new balance recovery algorithm, new fee calculation, etc.), the proposed plan currently on the table is to start fresh rather than factor the existing wallet2.cpp. Many of the features that users already expect (such as sweeps, tx key recovery, watch-only wallets, etc.) would be maintained, or improved where possible. The implementation of some existing features is still up for discussion, such as accounts.
    • I'd like to reiterate this point: Seraphis and Jamtis still need to undergo stringent review both from the community and by independent 3rd parties. At this time, @koe is still working on the technical paper describing the protocol in its current iteration, which will need to undergo review in the future. Further, feedback on the core feature changes is still strongly encouraged and desired.
  • Review PR's.

Who

I've identified and patched several privacy issues with varying severity in the Monero ecosystem:

  1. The reference wallet's decoy selection algorithm didn't select very recent spendable outputs in some cases. (source)
  2. The reference wallet truncated integers in the decoy selection algorithm, which would have borked the decoy selection algorithm entirely if tx volume were to increase; in the normal case, it marginally weakened the algorithm. (source)
  3. openmonero was still using the old proven weak decoy selection algorithm, also leaving a fingerprintable trail by decoy selection algo. (source)
  4. MyMonero didn't use the updated CLSAG fee calculation which fingerprinted MyMonero txs on chain by tx fee. (source)
  5. MyMonero's fee calculation->input selection logic differed ever-so-slightly from the reference wallet, resulting in a fingerprintable tx fee. (source)
  6. monero-lws fee masking on the server caused ever-so-slightly different fee calculations from the reference wallet, resulting in a fee fingerprintable to monero-lws (a fingerprint distinct from MyMonero). (source)
  7. In PR review on the latest hard fork's changes to the tx fee, identified the introduction of slightly different fee calculation logic that would have caused tx fees to be fingerprintable to either old or new version until the hard fork.

Other contributions:

Prior CCS proposals:

Proposal

253 XMR. 480 hours, 0.16 XMR/hr + $48/hr, $131/XMR from coingecko.

I'm requesting a raise from my prior CCS because I feel I have continued to demonstrate my work is worth a competitive market rate.