jeffro256 full-time dev work 2024Q4
What
The last quarter I began implementing Jamtis-RCT, as written by tevador. However, with the FCMP++ integration PR opened against master, and upon discussion of the general health of wallet development in the broader ecosystem, it became readily apparent that the way to move forward is to initially support existing Monero addresses in a way that would be indistinguishable on-chain from Jamtis-RCT, adding full Jamtis-RCT support later. As such, I formulated the Carrot specification, which expanded upon the legacy address section in tevador's original Jamtis-RCT proposal. I contacted and conducted meetings with auditors in regards to auditing this spec, which culminated in several proposals. I also implemented transaction scanning code and transaction construction code for Carrot. I would like to continue this work for the next few months ahead of the hardfork. The main things to work on for Carrot at this point are 1) persistent enote stores for both legacy and Carrot scan types together, 2) integration into the main wallet codepaths, 3) hardware device support, and 4) picking and organizing an auditor to move forward with. Ideally, there should also come a point in the near future where the implementation is reviewed against the audited specification. I wish the development of Carrot generally to be swift, in order not to impede the release date of the FCMP++ consensus protocol. It should be noted that if the current addressing protocol is not modified, then users' transactions will not be afforded conditional forward secrecy. This would mean that a potential future adversary with the ability to solve the decisional Diffie-Helman problem (e.g. a usable quantum computer) would be able to retroactively reveal the transaction graph without any obfuscation. Carrot, like Jamtis-RCT, leverages the forward secrecy property of FCMP++ while also tackling other issues like the burning bug, Janus attacks, etc. If all goes well, the adoption of Carrot will seamlessly move Monero users into the full realization of the privacy and security that the FCMP++ proving system has to offer.
If I still have time left over this quarter, I would like to work on code to build the curve tree structure wallet-side during the normal scan process. In FCMP++, there is a Merkle tree-esque structure called a curve tree where the leaves of the tree are the transaction outputs on the chain. The first layer of in-tree nodes are "hashed" (not technically a hash but it works for the analogy) from the leaves, AKA the transaction outputs. The nodes of the next layer are the result of several hashes of the previous, so on and so forth until one gets to the root node of the curve tree. Signing a transaction in FCMP++ requires the wallet to know the path of the transaction output it is attempting to send. A path of a transaction output is defined as itself, its siblings, its parent, its parent's siblings, its parent's parent, its parent's parent's siblings, its parent's parent's parent, its parent's parent's parent's siblings, etc. If one is already familar with Merkle trees, this is exactly how a Merkle proof is defined. There are three main ways that the wallet can obtain paths for its owned transaction outputs: 1) it can request it directly from the daemon which already has the tree built in its database in order to verify new transactions, 2) it can request that path along with other decoy paths, much like how decoy selection is done today, or 3) the wallet can build up the tree on its side and calculate the paths during scanning. Solutions 1 and 2 are suboptimal when using an untrusted daemon since it leaks traceability information. A FCMP++ proof normally makes the statement that one out of all on-chain transaction outputs is being spent, without revealing any additional information. However, using decoy selection while fetching the paths (or fetching the path alone, God forbid), reveals to the untrusted daemon that their client is likely spending one of a subset of the on-chain transaction outputs. On the other hand, building the tree in-wallet and calculating transaction output paths allows for minimal tracing information leakage.
To recap, here is a list of things I will attempt to work on this quarter, in rough order of execution:
- Finalize Carrot spec audit
- Implement Carrot enote store
- Implement Carrot hardware device support
- Integrate Carrot into main wallet codepaths
- Begin soliciting Carrot implementation audit
- Develop code to build FCMP++ trees in-wallet
P.S. To all the generous supporters of my previous proposals, I apologize that the direction of my work has shifted so significantly and so frequently in the past. So many developments have occurred within the last year that it makes my head spin, which in the end will no doubt be a good thing. So while a lot of previous goals have been abandoned, and a lot of previous work put on ice indefinitely, things seem to be finally solidifying towards a forseeable, readily-achieveable outcome in regards to the upcoming hardfork, thanks to many hard-working contributors. Hopefully, all of the work for this quarter will actually see the light of day in the short to medium term. Thanks for your patience. I am very grateful for it.
Who
I have been contributing to the Monero core repository for over two years with a total of 76 merged commits to master thus far, with many open PRs. I also began working on the Seraphis migration project, so you can see some of my contributions here and here. Additionally, as I mentioned, last quarter I wrote up the Carrot specification for formal auditing, which will be the main addressing protocol post-FCMP++ if all goes according to plan.
Previous Proposals:
Payment
I propose to work 40 hours/week for 3 months so 40 (hours/week) * 3 (months) * weeks_per_month = 40 (hours/week) * 3 (months) * (365 / 12 / 7) (weeks/month) = 521 hours total on-paper, though I usually work more than that. The proposal is broken into 3 milestones, one for each month. I am setting my hourly rate at 47 USD/hour (+1 USD/hour higher than last quarter), and at a market price of 170.37 USD/XMR, that makes for a total of 143.7 XMR. Price was calculated as 14-day simple average of opening prices on CoinGecko from 2024-09-04 to 2024-09-17 (day of writing), same as last quarter.