Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
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.
Informal audit of monero-lws
Subaddresses are not yet supported in light wallets. 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.