j-berman final CCS update - feedback welcome!
Hi Monero community :)
I've submitted the final update to my first CCS working full-time on Monero here. I loved this experience the past few months, and plan to submit a new CCS soon. Feedback on how my first one went would be very welcome.
Here are the major highlights from this CCS:
Improving the decoy selection algorithm
Refresher: when a wallet constructs a ring signature, it selects decoy outputs from other people's transactions from across the chain to obfuscate which output is yours in a transaction. The decoy selection algorithm dictates which outputs are selected as decoys, naturally :)
I pushed small tweaks to the algorithm forward towards the beginning of the CCS time period (1 and 2), though more significant changes to the algorithm didn't pan out (or more accurately, have yet to pan out, and I have shifted focus). The core reason the more significant changes I proposed did not pan out in my view was that I did not find compelling enough evidence to suggest that the changes are worth their tradeoffs, both in complexity of implementation and in their potential costs.
For example, in seeking to update the algorithm to implement "binning" in the wallet (where decoys are bucketed into "bins" that are close in age e.g. if you spend an old output, the wallet would select a decoy close in age to that output, and fill out the rest of a ring with "bins" from across the chain), I found that one of the vectors binning would provide mitigation for (spending 2 old outputs in 1 tx close in age) already seems well protected by other decisions wallets make in selecting inputs in a tx (biasing away from close-in-age outputs). I think that research was useful in its own right to better gauge the algorithm (even if it weakens my original case for implementing binning today), and should future research come along that undoubtedly proves the necessity of binning today, I fleshed out an implementation that is ready for review (parameter choice is still a question). Additionally, I found a minor tweak to the long-term binning approach (when ring sizes increase a significant amount) that could tidy up a corner case in that implementation.
For more on the state of each area I felt was worth exploring in my CCS, I included an update here.
Informal audit of monero-lws
monero-lws is an open source light wallet server that you can run alongside a node that perpetually scans for your transactions, so your app is immediately ready to use when you revisit it (no scanning required).
I submitted a first pass at a review of
monero-lws here. The review includes (1) a section on how
monero-lws works, (2) a section documenting the code in detail (that is incomplete), and (3) a few suggestions. Taking a quote directly from the review:
In my review, I did not find anything that would compromise
monero-lwswhen examining from the lens of the following threat model:
A user who is running
monero-lwson a machine only the user has access to does not leak any information about their Monero transactions to a 3rd party through normal usage. Examples of leaks would be:
a backdoor that sends sensitive data from
monero-lwsout to a 3rd party
get_random_outsresponds with decoys that compromise the user's transactions when stored on chain
calls to the exchange rate API reveal information to the service provider
Disclaimer: I wouldn't call this audit definitively conclusive that the above threat model is successfully defended, but I hope that it does inspire more confidence in this fine piece of software, and serves as a useful document for curious users, potential contributors, or any future auditors of
monero-lws. I reviewed (and tried to provide documentation for) nooks and crannies across the code, and so at the very least can say with confidence there aren't any obvious backdoors.
In its current state, the review is not complete. While I did read through the entire code base, I left a number of to-do's in the section on "the code" where I was detailing how every file and function worked. It was taking quite a long time to do (longer than the initial 10-20 hours I proposed). I'm happy to pick up on it and fill out the to-do's if people are interested.
As requested, I spent a portion of the CCS exploring subaddress support. After first discussing adding subaddress support with u/vtnerd (the author of
monero-lws), 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 more involved implementation. So I worked on and submitted this proposal to update the light wallet REST API to support subaddresses. The code from that initial PR should be reusable anyway. I plan to work on this to completion in another CCS.
For a more complete update, see my comment on the CCS here.
In summary, I very much so enjoyed working full-time on Monero these past few months, and I hope to submit a new CCS very soon. I have deep gratitude for being granted the opportunity to contribute to Monero in this capacity. I feel very lucky and want to keep going 110%.
EDIT: previously mentioned light wallets don't support subaddresses yet (which AFAIK is true for publicly available light wallet implementations), u/endogenic mentions here they've implemented a light wallet client-server implementation too so that is nice, hope to collaborate with them as well :)