j-berman full-time development (3 months)

Having spent a lot of time chatting with @j-berman in group chats, DMs, and meeting him in person and seeing his talent and dedication first-hand, I am beyond excited to see him jump in full-time and provide his skill-set and passion to Monero, while getting paid for it via community donations.

It is clear in my time with him that he has a deep understanding of Monero, a serious passion for privacy, and a unique skill-set that is much-needed in the Monero ecosystem.

I will be donating immediately when this is merged and hope many others will jump in to do the same.

Thank you for all you have done so far, @j-berman, and I cannot wait to see the things you'll be able to do for the space moving forward full-time :)

Added comment on the specifics -- the focus on monero-lws is much needed and appreciated.

A solid, easy to use light-wallet server is a must-have for Monero, and will be a huge boon to the mobile wallet UX once mobile wallets integrate support.

Not having to wait for extended syncing periods on each wallet open would clear up the biggest UX hurdle around mobile use of Monero, and hopefully we can get monero-lws to the point of being quite easy to run on top of your own node.

Once the code is good to go I will build out a Dockerized version to make bundling it with monerod a bit easier for less tech-savvy users.

Very kind words, very much so appreciated @sethsimmons. Thank you

I personally do not know Justin, but he seems the perfect person for this CCS. He has my full support on CCS, looking forward to his contributions!

Regarding monero-lws, I would love to see his changes and improvements in a such under-estimated project. Monero lightwallet is a must for people like me that would like to have their own self-hosted "Mymonero". I'm really excited to see someone focusing on it. A question for Justin: will you improve a little bit the software by adding new features or just an informal privacy audit?

Thank you!

A question for Justin: will you improve a little bit the software by adding new features or just an informal privacy audit?

I'd be happy to work on new features too! It seems there is a lot of interest for it. Are there any features in particular you want to see added? Can talk to @vtnerd about it too

Glad that you chose to work on Monero full time. I'm happy to support this.

Glad you decided to make the jump! I'm also glad that you decided to go the CCS route instead of going through a third party.

As a side note:

I received a job offer to join Cypher Stack doing research work.

The fact that a for-profit entity is closely monitoring the space for contributors, whom it thinks the Monero community is likely to fund and approaching them first, worries me and frankly strikes me as predatory behavior. I will be voting against any future CCS proposals mediated by Cypher Stack on this basis.

First important clarification, I was actively encouraged to make an independent CCS proposal when I mentioned to them that was what I was looking to do.

My opinion: taking a hostile stance toward Cypher Stack on the grounds of my experience with them is misplaced, and makes me feel like I’ve caused harm to Monero.

Personally I am very deeply drawn to the CCS process and the idea of being 100% directly beholden to the entire community. And because I am young, my expenses are low, I don’t have any dependents to take care of, I don’t plan on getting a loan any time soon, I can write ok, and I have a general pre-disposition toward things that bend the norm (like working full-time for people on the internet via 3 month written proposals where my pay is known to the world and is paid in Monero), I’m completely cool with not being on a normal salary and not working at a normally structured organization. In fact I’m beyond excited for the chance of this CCS proposal getting accepted. But I can absolutely 100% see why others who have the capacity to be strong contributors may not be as interested in the above. Cypher Stack is an option for them. Taking steps that reduce that option for others I feel could reduce contributions to Monero. Figure goes without saying, but this includes from one of the most important contributors to Monero.

And truth be told, I am very grateful to have received the offer of a stable salary to be able to work on things that could benefit Monero. It is nice to know the option is there. Truthfully, it gave me a ton of confidence that I might be able to get a CCS proposal accepted -- it felt like a very strong signal. The fact that the Cypher Stack option is there just makes me feel even more comfortable trying as hard as I can to go the CCS route, because there is a backup option there in case the CCS proposal doesn’t work out.

I don’t want to work part time on Monero. I want to work full time on Monero. I don’t want to feel like I need to get a separate job or find separate work to feel comfortable enough financially to be able to push Monero forward as best as possible. And the fact that Cypher Stack is there increases my comfort level.

If there is one thing to take away from my rambling, it is that the CCS <> Cypher Stack relationship can (and seems to me to be) a symbiotic and mutually beneficial relationship.

I hope the Cypher Stack <> CCS relationship can be symbiotic, like you say, but there's little evidence so far. It seems like a one-way street at the moment, where the CCS is on the giving side and Cypher Stack is on the receiving end. Maybe that will change in the future and Cypher Stack will indeed make some original contributions that do not simply involve it making a commission from a CCS proposal.

I'm glad they made you an offer, but do you really think that if your CCS proposal is unsuccessful, they will go through with that offer? Their business model relies on CCS funding, either through the original CCS or the forked CCS they illegitimately re-sold to Firo. If your CCS proposal fails, I see no reason to believe that a CCS proposal by them on your behalf will succeed. Which means that they will likely try to get you work with another project and if that fails, your job offer will fall through.

Their behavior in previous instances has clearly indicated that their interests are first. The interests of the projects "their researchers" are working on are a distant second. They withheld information from the community while seeking funding for the contributor you reference and neglected to offer the option of hiring that valuable contributor on a full time basis, despite expressed interest by the community, while proactively offering that option to a competitor. They then threatened to withhold further work if an additional funding demand, beyond the agreed amount, were not met.

That is the difference between being beholden to the entire community and being beholden to a private entity with its own priorities. I'm glad that you clearly see the difference and I hope others do too.

@geonic1 it really seems to me that you're bringing unnecessary meta drama into here. The CCS is used to fund things, that's what it's for, whether it's an individual or an entity. Entities have asked for money on many occasions, including the atomic swaps and quantum computer proposals. The CCS only pays if tasks are complete as described, regardless of the circumstances.

It seems to me that you're once again rushing to defend your friend and former LLC partner while actively avoiding the issues that are being raised. You also forget that your friend was one of the two administrators of the CCS before founding a temp agency to shepherd CCS proposals that also offers Monero contributors to other projects. This alone is cause for concern even if we ignore the actual behavior they've exhibited.

@geonic1 whatever your beef with the situation was (and it seems your understanding is incorrect, since he has never been a partner in anything I've done), it does not warrant harassing other contributors who open their own independent CCS proposals in any circumstance.

@sgp huh? https://www.reddit.com/r/Monero/comments/i9qc74/rehrar_clarification_on_the_llc/

Let's pick a different venue please, this is starting to veer too far from the original discussion. The proposal mentioned Cypher Stack and I elaborated my thoughts on the matter. I'm afraid the only person harassing anyone in this conversation is you.

do you really think that if your CCS proposal is unsuccessful, they will go through with that offer?

The sequence of events you described is possible if assuming the absolute worst. I generally hope for the best and prepare for the worst; in my mind, having another potential option available is better than not having an option available. And again, I can understand why others would prefer to have more options, I can see how having more options would be beneficial toward attracting more contributors to Monero, but I don't know enough to comment further on the specifics of other circumstances.

I don't really have much else to add except that I don't feel harassed, no worries @sgp :) Thanks for looking out

Yeah i approve this and will donate once possible.

I approve, please move. It's great to see Justin take the initiative to jump in headfirst.

Well written CCS, seems like a technically solid person based on background, and improving the decoy selection is certainly something that's worthwhile given increased resources as of late poured into adversarial chain analysis that seeks to undermine user privacy. Hopefully it gets approved!

mentioned in commit 49315361

merged

5 XMR donated to this proposal by Haveno. Keep up the good work!

b1c87e855f846b91ebbb6926bc7a433c2ad027d5374818cf24c5432a5cd3682d

Thanks @erciccione and team!

Thank you!!! I'm a fan of what you guys are doing :D

@j-berman Not sure if this is at all possible, but it would be great to see subaddresses added to Monero-LWS for receiving XMR/or just a kind of feasibility investigation to figure out what needs to be done to get them added.

Will look into this!

changed the description

Update 1

Weeks 1-2 [Aug 30 - Sep 12]

Hours worked: 93 (CCS_1_time_tracking_weeks_1-2.ods)

Summary

First, I want to say I'm beyond thrilled and ecstatic to have received this opportunity to work on what I love. I'm deeply appreciative to the Monero community for giving me the chance, and I am bent on maximizing the value I bring to Monero. I'm working toward that aim to the best of my ability.

Second, I will be the first to say I wasn't as productive as I had hoped the first couple weeks, but I'm picking up steam and improving quickly. I'm certain my deliverables will be much stronger by next update at the end of my first month. I've also decided I want to deeply focus on this CCS proposal exclusively, and won't be picking up contracting work, at least until I've completed this proposal.

What I did these past 2 weeks

continued decoy selection algo analysis and recommended patching the integer truncation bug in wallet2 for next release (this was point 1 of the areas to improve the decoy selection algo)
- added analysis of the MyMonero+monero-lws & openmonero decoy selection algorithms in response to vtnerd's feedback and criticisms of my (too strongly held) conclusions that real outputs seem more likely identifiable
worked on a postmortem of the decoy selection algorithm bugs
- IMPORTANT: while sanity checking the monero-lws decoy selection algorithm to ensure it's working as expected, I realized that it did not have the decoy selection bug that was widely publicized. This means that the widely publicized decoy selection bug stating that some recent outputs are guaranteed identifiable is not the case, since MyMonero (and monero-lws) users could have feasibly constructed transactions with early spends as decoys. I had reached out to MyMonero a month or so ago to see what implementation they were using, and found that they were using the monero-lws implementation, but did not realize at the time the code did not have the same bug.
helped update monero-lws to work with version 0.17.2.3 of Monero
submitted a PR to match the monero-lws decoy selection algorithm to wallet2's
- although in hindsight, given vtnerd's feedback and criticisms, it's clear I should have moved forward on integer truncation in wallet2 first before submitting this PR
submitted PR's to make a number of daemon RPC functions thread safe
- PR that makes functions that strictly read LMDB -- and don't write -- thread safe
- while working on this^, found and patched a tiny bug in on_getblockhash where it wouldn't correctly return an error response when the height requested is greater than the chain height, and also found a small bug in on_get_transactions will fix in the future
- PR that makes flushing the entire pool thread safe
started reading through monero-lws and scoped out an audit framework
started looking into getting subaddresses working in monero-lws (more on this below)
contributed in discussions on the anomalous tx volume spike from the end of July
reviewed Sech1's PR to update monerod for p2pool & reviewed ndorf's PR to update the lightwallet server REST API to allow retrieving only new tx's a client has yet to see

What I plan to do in the next 2 weeks

Push forward the binning solution to improve the decoy selection algo

Refresher: binning = a strategy to select decoy outputs in "bins" of similar ages to mitigate known weaknesses of the decoy selection algo.

UkoeHB highlighted an issue with unlock times that negatively affects binning. An attacker could feasibly construct many outputs that are locked, which results in an undesirable circumstance that is worse for binning implementations:

What if the local outputs around the output you want to spend are all locked? There might not be enough decoy outputs available to make a bin with the real spend in it. This opens a serious attack vector.

UkoeHB highlighted 3 solutions to this: removing unlock times, encrypting unlock times, or only using decoy outputs that are unlocked (which opens an attack vector where someone can slowly aggregate a number of outputs that unlock at a specific time e.g. a delayed flood attack). I figure the decision on what to do with the unlock time is a blocker for binning at this point, so I pushed forward discussions on what to do with the unlock time in today's MRL meeting, and will continue to push forward on that front. Once it seems there is solid consensus on what to do with it (which seems like it's nearly there), I will start putting more work into binning.

Informally audit monero-lws

vtnerd initially mentioned he’d want someone to look for obvious privacy backdoors. I will do that and a bit more.

The threat model I'll assess: a user who is running monerod + monero-lws on a server only they have access to does not leak any information about their Monero txs to a 3rd party through normal usage. Examples of leaks would be:

a backdoor that sends sensitive data from monero-lws out to vtnerd/a 3rd party
get_random_outs responds with decoys that compromise the user's transactions when stored on chain
calls to the exchange rate API reveal information to the service provider

To be honest, I don't anticipate finding vulnerabilities that compromise the above threat model - I've already spent some time looking over the code. To inspire confidence in the audit, I plan to read every line in every file, and explain the critical files and functions. The deliverable will be a document that does this.

I'll also keep an eye out for a wider scoped threat model: ideally exposing your monero-lws to the internet would not enable someone to get user-specific information from the server. Meaning only the owner of an address/view key pair can see their own transactions stored on the server.

Update openmonero & monero-lws to match wallet2's decoy selection algo

Waiting on what gets decided for wallet2 in this PR before updating.

Continue working on thread safety in the daemon RPC

There are more functions that need some more work to be made thread safe. I talked about it a bit in this PR.

Subaddress support in monero-lws

As requested by @CryptoGrampy, I spent a bit of time looking into this, and will continue to do so. It doesn't seem like it'll be very challenging to support in monero-lws (technically it seems it can "work" with a couple well placed comments, but the address you see in the CLI would be incorrect). My first guess is that it would take me 2 weeks or so to actually implement it, while I get up to speed working in the code base, but I'm sure vtnerd would have a better idea. I also started talking a bit with Devin from MyMonero about it too, can collaborate with the MyMonero folks + vtnerd on it (especially in case any of them may think it would be a good idea to modify the API a bit, but doesn't seem required to me).

There seems to be a lot of support for getting monero-lws into more hands, so generally speaking I'd be happy to help vtnerd out with it if I can.

Feedback welcome!

First off, man am I pumped to see you already this deep in Monero and taking things so seriously. You've shown (yet again) your work ethic and dedication, and have gone above and beyond with this report.

As for not feeling as productive as you wanted in the first couple of weeks -- it looks like the opposite is true, but I know how the learning curve and headaches of starting a new job are, and there is no central entity or training with Monero. You've gone in head first and are making great progress, which is great to see!

I do think monero-lws (or something similar) is vital for growing usage and adoption of Monero, especially when it can be easily bundled with running monerod in the future (which I will work on personally once monero-lws is more formally audited and stable). Your work on this will be key, and it seems to have pulled more eyes on the project as a whole, so I'm excited to see where it goes from here! Light wallet servers that can be easily self-hosted are a huge step forward for UX.

Thanks again for the detailed report, and I look forward to the next one in 2wks!

Update 2

Weeks 3-4 [Sep 13 - Sep 26]

Hours worked: 96.7

Total hours worked: 189.7

CCS_1_time_tracking_weeks_1-4.ods

Summary

I spent a fair amount of time researching and fleshing out ideas to move forward on decisions to improve the decoy selection algorithm, and I don't have much in way of PR's yet. In my last update, I mentioned I wasn't as productive as I had hoped, though in hindsight, I think it was mainly just getting used to the new type of work. This past 2 weeks, I spent more time reading/thinking/sharing thoughts on the above decisions as opposed to writing code than I anticipated 2 weeks ago (but I anticipate my code output will start to increase soon). As a result, I don't think the deliverables this update are as strong as I had hoped (again), but I'm coming to terms recognizing it can take a bit longer to deliver than I'm used to.

What I did these past 2 weeks

provided a PoC to validate ring member distributions at consensus (point 4 of my initial proposed areas to improve the decoy selection algo)
- This topic started to receive a fair amount of attention in #monero-dev and #monero-research-lab, and so I wanted to share the approach I had in mind that didn't have some of the problems that people were concerned for (e.g. floating point calcs, complexity, performance etc.)
- Discussion on validating ring members at consensus continued in that issue and here
pushed forward the decision on what to do with timelocks, which again to me seems a major blocker for a binning implementation (point 2 of where I wanted to focus on in improving the decoy selection algo)
- researched atomic swaps/payment channels to understand how they (don't) use Monero's timelocks
- dug into alternative methods of proving reserves compared to using a timelock
completed ~50% of the "informal audit" on monero-lws - looking good so far!
looked into subaddresses in monero-lws a bit more
- an acceptable implementation may be more involved than I previously thought, planning to collab with other light wallet maintainers to discuss
published the post-mortem of decoy selection algorithm bugs
reviewed and tested ndorf's PR to fix bug in RPC get_transactions
- this was the bug I had spotted during my first 2 week period and had planned to fix until I saw ndorf's PR

What I plan to do in the next 2 weeks

Push forward the binning solution to improve the decoy selection algo

Continuing to push toward a decision on what to do with timelocks. Will make a request to the community for feedback on it. I think once the community has given feedback, it would be sensible to continue with binning assuming there is wider support for deprecating timelocks.

Complete informal audit of monero-lws

As stated in update 1, planning for the deliverable to be a document that mainly describes what each file in the program does, and what critical functions do. I'm about 50% of the way through with this document.

Update openmonero & monero-lws to match wallet2's decoy selection algo

Was initially waiting on what got decided for wallet2 in this PR before updating, but at this point think it's worth just tee'ing up the code to get it ready. Just going to submit/update the PR's :)

Subaddress support in monero-lws

Reaching out to the other devs involved in light wallet development (MyMonero/vtnerd) to bounce my thoughts off with them on implementing subaddress support, and hope to have a fleshed out proposed implementation squared away.

Continue working on thread safety in the daemon RPC

There are more functions that need some more work to be made thread safe. I talked about it a bit in this PR. Will wait on that PR to ensure I'm taking the right approach.

Address DM'd to @luigi1111 by request, some characters from the address: 86MhAj4G...FR44ANwb

changed the description

Update 3

Weeks 5-6 [Sep 27 - Oct 10]

Hours worked: 91.2 hours

Total hours worked: 280.9

CCS_1_time_tracking_weeks_1-6.ods

Summary

Halfway through! Code output is picking up a bit. I focused mainly on decoy selection algorithm work these past 2 weeks (lots of focus on binning + updated openmonero). I'm optimistic I'll be able to make significant headway into (and finish) most stuff from the CCS proposal by the end of the 3-month period, except for a majority of the one-off tasks (but also hoping to get subaddress support in monero-lws done). A couple others have taken on a couple of those one-off tasks as well. Making progress.

What I did these past 2 weeks

worked on a PoC for "binning" in the decoy selection algorithm (point 2 of my initial proposed areas I'd work on to improve the decoy selection algo)
implemented the gamma-based decoy selection algorithm in openmonero
- updated xmregcore (used by openmonero) to work with Monero v17.2.3
created a new PR to decrease the recent spend window in the decoy selection algo
- the "recent spend window" is meant to capture very recent spent outputs observed on chain back when the 10 block lock time wasn't enforced by consensus, rather than throw out decoys pulled from that part of the distribution. It was first implemented in PR 7821 under the assumption that integer truncation would remain in the client. If integer truncation is patched in next release, I believe reducing the recent spend window from 50 to 15 is sensible. See PR 7993 for a better explanation.
made a bit more progress on monero-lws informal audit, but not much
chatted with vtnerd on a strategy to support subaddresses in monero-lws
- going with a 2-step strategy: step 1 won't require any changes to the lightwallet API and will get subaddresses working in monero-lws, same as openmonero. Step 2 would be more involved

What I plan to do in the next 2 weeks

Binning

Will collect feedback on the PoC and discuss in the next dev meeting. If that PoC gets approved, a wallet2 implementation shouldn't be too difficult. I think the PoC is fairly deeply thought through (and a lot of code is written), so plopping it in to wallet2 shouldn't be too bad.

Complete informal audit of monero-lws

As stated in update 1, planning for the deliverable to be a document that mainly describes what each file in the program does, and what critical functions do. Still about 50% of the way through with this document. Binning took up more of my time than expected these past couple weeks.

Subaddress support in monero-lws

Hope to have a PR ready soon!

Continue working on thread safety in the daemon RPC

There are more functions that need some more work to be made thread safe. I talked about it a bit in this PR. Will wait on that PR to ensure I'm taking the right approach. Probably will be more vocal in requesting a PR on this.

Side comment

Excuse the banner warning at the top The source project of this merge request has been removed. Noob move on my part

Fantastic summary and interesting read! Thanks @j-berman

Thank you @john_r365 :)

Update 4

Weeks 7-8 [Oct 11 - Oct 24]

Hours worked: ~60

Total hours worked: 341

No time tracking spreadsheet this week, explanation provided below

Summary

Ran into a couple snags this period:

I realized a flaw with my proposed binning algorithm.
My hard drive failed on Oct 21.

On (1), I spent a fair amount of time working on a fix for the flaw. That ended up taking most of my time for this period. But I've ended up with what I think is a much better approach :)

On (2), because of this, I unfortunately lost my time tracking spreadsheet for the period. I recall that I was over 40 hours for the 1st week, and approaching 40 for the 2nd, but don't recall exact amounts. Because of this I decided to under-estimate my hours by a wide margin at 30 hours per week for each, which is why I put ~60 hours worked this period.

I'll give another bi-weekly update before my final update as well.

What I did these past 2 weeks

submitted the PoC for "binning" in the decoy selection algorithm, realized a flaw in it, then worked on an approach that does not have the flaw
worked on hardening flaky unit tests in the decoy selection algo
- special thank you to @gingeropolous for getting me set up with their research machines to help with this
started looking at a PR to ensure tx's that make it into the pool before a fork height, that should fail after the fork, don't make it into the chain

Going forward

As of the end of week 8, I have a total of ~140 hours remaining until 480. However, there is still a fair amount of work remaining in the CCS (that I don't think I can definitely complete in 140 hours). 2 tasks I promise to complete as part of this CCS (even if it ends up taking more than 140 hours) are the monero-lws informal audit, and subaddress support in monero-lws.

Separately, I've decided to take on implementing @koe 's proposal to use a "view tag" to reduce scanning time. Any hours spent working on that will not be included as hours worked on my CCS, since there is an open bounty for it.

I will continue to prioritize work on binning above all else (which is currently open for review and feedback). At this point, it feels there is not too much left immediate work on binning (reiterating, implementing won't be too challenging). That is why I feel I have the time to work on implementing the view tag (which is 2nd priority). Planning to prioritize these 2 tasks (binning + view tag) over other work.

Update 5

Hours worked: ~104

Total hours worked: 445

Time tracking spreadsheet: CCS_1_time_tracking_update5.ods

Summary

Since last update, I spent most of my time working on view tags, which is the reason for the large gap since the prior update. CCS-related work done since last update: pushed forward on binning in the decoy selection algorithm (both wallet-side and UkoeHB's longer term deterministic binning), PR review, provided feedback to Rucknium on their in-progress OSPEAD work, and miscellaneous research-related tasks that sprung up, such as not allowing duplicates in the decoy selection algorithm across rings and collecting more feedback from atomic swap people on useful features.

What I did as part of this CCS since last update

completed work to get the wallet-side binning proposal in a state where it is open for feedback
researched to better gauge how beneficial binning would be for users who spend multiple inputs in a single transaction, where their inputs are from older transactions that are close in age
- I found that user privacy seems to be well protected in this case, and binning does not seem it would be of huge help for this particular scenario
put together a very raw code snippet that demonstrates a way to implement a component of UkoeHB's deterministic ring selection, specifically how to map randomly generated values from a seed into the gamma CDF (or any other distribution)
- my code is still a bit raw to share at this point, but I made progress on this that I believe will be useful to push forward deterministic binning generally
finished reviewing and testing moneromoo's PR that makes sure that at the next fork height, the pool will eject transactions that were valid prior to fork, but rendered invalid at fork height
- this avoids this issue where some nodes got stuck last fork for next fork
reviewed yorha-0x's PR that prevents the wallet from selecting duplicate outputs across rings
researched atomic swaps further to better understand the requirements to get swaps working where XMR moves first, which most concretely led to this update in the COMIT matrix channel that essentially explains that Seraphis' "transaction chaining" seems to be the strongest candidate to enable what is needed, and explains why the approach proposed by COMIT may not be viable long-term in a switch to deterministic ring selection when ring sizes increase a significant amount

Going forward

Binning

There are 2 binning proposals currently in flight. 1: my wallet-side binning proposal, and 2: UkoeHB's deterministic binning for when ring sizes increase a significant amount. On my wallet side binning, my view is starting to shift toward thinking that it may be challenging to get everyone on board with it for next fork, considering there are fairly subjective parameter choices in the algorithm, it's a fairly significant change to the decoy selection algo as is, and the need for binning does not appear to be critical. I'm more strongly considering rolling up some of the intuition from what I've done so far into pushing forward on UkoeHB's deterministic binning. I don't think Monero is in a state where binning is an absolute necessity today, and taking some insight I gathered while working on wallet side binning I believe will be helpful in pushing forward on deterministic binning so this isn't a major loss (for example). It's also a backup spec'd out implementation ready to go if the need arises.

At this point, I lean toward pushing forward deterministic binning unless people provide strong feedback that my proposed wallet-side binning proposal is worth implementing today.

monero-lws subaddress support + informal audit

Will have PR's/tangible deliverables to complete this CCS.

Optimizing wallet scanning

While implementing view tags, I believe I may have found some unrelated easy wins to reduce scanning time that could use more rigorous testing to be certain (and do not require a fork). I will likely end up just rolling this investigative work up into another CCS proposal, along with other tasks I'd like to work on.

Update 6 (final update)

Hours worked: 92+ (stopped keeping track on January 20)

Total hours worked: 537+

Time tracking spreadsheet: CCS_1_time_tracking_update6.ods

Summary

Final update! The most significant things I worked on since last update were monero-lws subaddress support, the informal audit of monero-lws, and reviewing/providing feedback on JAMTIS (the next gen address scheme protocol). I've also spent quite a lot of time working on things related to view tags, though not as part of the CCS.

Generally I try to help out in the Matrix/IRC channels when I can.

What I did as part of this CCS since last update

Got a subaddress implementation working in monero-lws, submitted a PR, then in the ensuing discussion with @trasherdk and @selsta reached the conclusion that it probably makes more sense to tackle subaddress support in a more comprehensive way. Then I put together this proposal for adding subaddress support to the light wallet rest API. Moved on to other tasks in the interim.
Submitted a first draft of the informal audit of monero-lws.
Reviewed and provided feedback on JAMTIS, the proposal to update Monero's address scheme alongside the upgrade to Seraphis.
This isn't part of the CCS, but including it anyway since it took up a lot of my time: I worked through comments/feedback provided by community members on the view tag implementation. Also spent a couple days exploring @knacc's potential optimization strategies over in this github branch.

The CCS in review

Improving the decoy selection algorithm

Unfortunately, or fortunately rather, not too much was born out of my efforts in this area over the course of the CCS. I gave the algorithm a very hard look in the areas I highlighted, and spent a large amount of time working through what I initially proposed, but ultimately don't feel I could come up with enough evidence demonstrating why the solutions I proposed would be significant improvements worth their tradeoffs and complexity in implementation.

Here is a more detailed summary on the state of each of the 4 areas I included as worth exploring over the course of the CCS.

monero-lws audit

Here is my submission of the informal audit in its current state. I wasn't able to complete it as it was taking up a lot more time than I anticipated, however, I did take a deep pass through the entire code base. My conclusion is that there are no obvious backdoors :) I also drew up a diagram that may be helpful to people wanting to understand how it works, and included suggestions for monero-lws. I spotted some tiny things to tweak in my pass too, but not really a big deal.

Subaddresses in monero-lws

After first discussing adding subaddress support with @vtnerd, we initially reached the conclusion that it would make sense to support subaddresses in a very simple way first, and then work on a larger proposal later on. After implementing, and in the ensuing discussion on the PR, in my view it became a bit more clear that it would likely make more sense to skip the simpler implementation, and go straight for the larger implementation. So I worked on and submitted this proposal. I plan to work on this to completion in another CCS.

Other significant contributions

I'd say here were the most significant pieces of code I had a part in during this CCS that either did or did not make it into production:

Updated openmonero's decoy selection algorithm to use the correct distribution (merged)
Reduced the window the wallet uses to re-select recently spent decoy outputs from 50 blocks to 15 blocks. The idea behind this window is that the distribution that the wallet references to select decoys was constructed based off spending patterns when users could spend outputs that were <10 blocks old, and so to account for those "recent" outputs, when the distribution suggests an output <10 blocks old, the wallet re-selects outputs within the recent spend window instead. The idea and supporting evidence is explained further in the PR. (merged)
- Proposed merging the change in the decoy selection algorithm to fix an integer truncation bug in tandem. (merged)
Proposed a way to implement a binning decoy selection algorithm in the wallet today. In tandem, I found that wallets seem fairly well protected from a particular scenario that binning would provide protection for. I think both of these would serve as useful research on the decoy selection algorithm, even if the proposed binning implementation does not make it into production.
Reviewed and tested @moneromooo's PR that will ensure that at the next fork height, miners will not be able to mine invalid transactions and cause people to be unable to sync.
Reviewed the PR to update fees based on @ArticMine's proposal at the next fork.

Tasks I did not get to or complete that are not covered above

make the daemon RPC thread safe
- first pass at this still in pending state
make wallet cache an lmdb file
authenticated encryption for wallet cache
rw lock for the Blockchain class instead of mutex (someone from #monero-dev said they'd take this on, but haven't heard from them since)
zeromq msgpack support
json-schema support
reduce # of requests to poll a daemon (edit: @rbrunner7 completed this -- planning to review the PR soon)
add wallet-dir flag for monero-wallet-cli
scan the wallet2 code for ways of providing stronger protection from malicious nodes

Going to keep a running list of stuff! Anyone can feel free to take from the list too if something here catches your fancy over some of the github issues.

j-berman full-time development (3 months)

What

Improve the Decoy Selection Algorithm

Informally audit monero-lws (light wallet server) for safety issues

Other one-off tasks I'd like to work on as well

Who

Proposal

Merge request reports

Activity

Update 1

Summary

What I did these past 2 weeks

What I plan to do in the next 2 weeks

Push forward the binning solution to improve the decoy selection algo

Informally audit monero-lws

Update openmonero & monero-lws to match wallet2's decoy selection algo

Continue working on thread safety in the daemon RPC

Subaddress support in monero-lws

Feedback welcome!

Update 2

Summary

What I did these past 2 weeks

What I plan to do in the next 2 weeks

Push forward the binning solution to improve the decoy selection algo

Complete informal audit of monero-lws

Update openmonero & monero-lws to match wallet2's decoy selection algo

Subaddress support in monero-lws

Continue working on thread safety in the daemon RPC

Update 3

Summary

What I did these past 2 weeks

What I plan to do in the next 2 weeks

Binning

Complete informal audit of monero-lws

Subaddress support in monero-lws

Continue working on thread safety in the daemon RPC

Side comment

Update 4

Summary

What I did these past 2 weeks

Going forward

Update 5

Summary

What I did as part of this CCS since last update

Going forward

Binning

monero-lws subaddress support + informal audit

Optimizing wallet scanning

Update 6 (final update)

Summary

What I did as part of this CCS since last update

The CCS in review

Improving the decoy selection algorithm

monero-lws audit

Subaddresses in monero-lws

Other significant contributions

Tasks I did not get to or complete that are not covered above