hinto-4.md

+---
+layout: wip
+title: hinto-janai full-time work (3 months)
+author: hinto-janai
+date: February 7, 2025
+amount: 186
+milestones:
+  - name: Month 1
+    funds: 62 XMR
+    done:
+    status: unfinished
+  - name: Month 2
+    funds: 62 XMR
+    done:
+    status: unfinished
+  - name: Month 3
+    funds: 62 XMR
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+## What
+Work full-time for 480 hours on:
+- Cuprate
+  - Alpha release cycle [1](https://github.com/Cuprate/cuprate/issues/371) [2](https://github.com/Cuprate/cuprate/issues/374)
+  - User book [1](https://user.cuprate.org) [2](https://github.com/Cuprate/cuprate/pull/165) [3](https://hinto-janai.github.io/cuprate-user-book)
+  - Project roadmap Q1/Q2 goals [1](https://github.com/Cuprate/cuprate/issues/376) [2](https://github.com/Cuprate/cuprate/pull/369) [3](https://github.com/Cuprate/cuprate/pull/370)
+  - Misc. review work
+- Monero
+  - FCMP++ related review [1](https://github.com/monero-project/monero/pull/9440) [2](https://github.com/monero-project/monero/pull/9436) [3](https://github.com/monero-project/monero/issues/9422#issuecomment-2504037485)
+
+Cuprate is preparing its first alpha release, with a 4-week cycle. A progress report for 2024 is [here](https://www.reddit.com/r/Monero/comments/1ij2sw6/cuprate_2024_progress_report), the roadmap for 2025 is [here](https://github.com/Cuprate/cuprate/issues/376). I will be buying/renting a variety of hardware for testing/development and will post receipts for all hardware acquired at the time of exchange within this CCS.
+
+If developer resources becomes a bottleneck for FCMP++ activation on `monerod`, I will switch priority when/where possible. This was discussed [here](https://github.com/monero-project/meta/issues/1137). Otherwise, I will continue working on Cuprate Q1/Q2 goals noted in the project roadmap, specifically: user book, release cycle, RPC integration [1](https://github.com/Cuprate/cuprate/issues/379).
+
+## Who
+[hinto-janai](https://github.com/hinto-janai)
+
+Previous proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/422
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/456
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/484
+
+## Funding
+186 XMR. 
+
+$65 + 0.1 XMR per hour for 480 hours at $225/XMR.

j-berman-3-months-full-time.md

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: August 30, 2021
+amount: 78
+milestones:
+  - name: Month 1
+    funds: 33% (26 Monero)
+    done: 29 September 2021
+    status: finished
+  - name: Month 2
+    funds: 33% (26 Monero)
+    done: 29 October 2021
+    status: finished
+  - name: Month 3
+    funds: 33% (26 Monero)
+    done: 4 February 2022
+    status: finished
+payouts:
+  - date: 6 October 2021
+    amount: 26
+  - date: 10 November 2021
+    amount: 26
+  - date: 8 February 2022
+    amount: 26
+---
+
+## What
+
+### Improve the Decoy Selection Algorithm
+
+When constructing a new transaction, your wallet references a past output you received in a prior transaction, and uses it as one of the inputs to your new transaction. The wallet hides this output among a set of decoy outputs from other people's transactions from across the blockchain, in order to sever the link from your newly constructed transaction to your prior transactions. That is what the decoy selection algorithm does in the wallet: it mixes your real outputs spent in a transaction among a set of decoy outputs. This algorithm has room for improvement to better protect users under a wider set of circumstances today, and I would like to focus on these areas. I found and patched a couple low-hanging fruit areas of improvement, and have written about 4 areas worth continuing to focus attention on today [here](https://github.com/monero-project/research-lab/issues/86):
+
+1. Assess observed chain data and determine the relative safety of fully patching an [integer truncation issue](https://github.com/monero-project/monero/pull/7798#issuecomment-900728961).
+2. Push forward a "binning" solution to bucket outputs into bins, in order to mitigate weaknesses in exclusively using past spending patterns to select decoy outputs.
+3. Collaborate with community member @Rucknium on methods of improving the probability distribution used in the decoy selection algorithm, so that it would more accurately reflect true spending patterns (it currently uses a gamma distribution -- @Rucknium believes there are likely better distributions to use).
+4. Work on a PoC that demonstrates how to simply enforce transaction uniformity in decoy selections via consensus.
+
+### Informally audit [monero-lws](https://github.com/vtnerd/monero-lws) (light wallet server) for safety issues
+
+The benefits of running a light wallet server alongside a node are significant. You could connect a light wallet compatible client to your server from anywhere, and your wallet would stay synced and ready to use at all times. This way you wouldn't have to wait for your wallet to sync when you load your wallet. The minor downside is that your address and view key would be "hot" on your server, meaning if someone gets access to your server, they get access to your address and view key and could therefore see all of your past and future outputs received. @vtnerd has evidently put a ton of effort into [monero-lws](https://github.com/vtnerd/monero-lws), it would be great to get it into more hands. @vtnerd mentioned in IRC that having someone look over the implementation for obvious privacy backdoors is one of the last steps needed to get it into the main repository. I'd love to spend 10-20 hours (or more?) on an informal audit. I'm decently familiar with the light wallet stack, since I worked on a fork of [openmonero](https://github.com/moneroexamples/openmonero) (and the MyMonero client libraries) in the past.
+
+### Other one-off tasks I'd like to work on as well
+
+- Update [openmonero's](https://github.com/moneroexamples/openmonero) decoy selection algorithm to use the latest version
+- make the daemon RPC thread safe
+	- I started on this [here](https://github.com/j-berman/monero/pull/1)
+- make wallet cache an lmdb file
+- authenticated encryption for wallet cache
+- rw lock for the Blockchain class instead of mutex
+- zeromq msgpack support (performance - discussed with vtnerd)
+- json-schema support (ease of use for developers - discussed with vtnerd)
+- [reduce # of requests to poll a daemon](https://github.com/monero-project/monero/issues/7571)
+- [add wallet-dir flag for monero-wallet-cli](https://github.com/monero-project/monero/issues/7674)
+- scan the wallet2 code for ways of providing stronger protection from malicious nodes
+
++ any other high value tasks that come along I can help out on, prioritizing safety issues above all else, then liveness issues, then performance/usability. I plan to help out where I can on PR reviews as well.
+
+
+## Who
+
+I'm Justin Berman (I go by jberman in IRC). This is my first CCS proposal. I've been working full-time on patches for (and analysis of) the decoy selection algorithm for close to 2 months. I have knowledge of the Monero code base from past work on a fork of Monero for 4.5 months (Haven). I decided I'd really like to work on Monero full-time if it's possible. I am very passionate about Monero and want to see the best sound, hard, private money used everywhere :) I have a bachelor's degree in Computer Science from the University of Texas at Austin.
+
+My past contributions to Monero include:
+
+- [Finding](https://github.com/monero-project/monero/issues/7807) and [patching](https://github.com/monero-project/monero/pull/7821) the issue where the core wallet code ignores very recent spendable outputs when selecting decoys.*
+- [Finding](https://github.com/monero-project/monero/pull/7798) and [patching](https://github.com/monero-project/monero/pull/7845) an issue where the wallet truncates integers in the decoy selection algorithm, which would have eventually caused wallets to construct transactions that would reveal real spent outputs 95%+ of the time if left unchanged.
+- Improving a protection measure [in the wallet](https://github.com/monero-project/monero/pull/7848).
+
+Unfortunately the above are all small snippets of code, so it may not be the most useful means of gauging my abilities. If desired, I can point to larger swathes of changes I made on Haven to show I am comfortable working across the entire code base (from wallet to RPC interface to consensus rules to LMDB), though many of my contributions there are not shown to be authored by me on Github.
+
+**Full disclosures**
+
+- I received a job offer to join Cypher Stack doing research work. I personally would prefer the CCS route, though I may pick up contracting work if I feel that the work could strongly push Monero forward.
+
+- I received a contracting offer from Cake Wallet to work on the Thorchain Monero integration. I haven't decided yet what I'd like to do on this.
+
+- I'm a co-owner of [Userbase](https://userbase.com), which is a SaaS tool for web devs to make end-to-end encrypted apps. I spend ~5 hours a month on support, and in my free time would like to implement new features from time to time.
+
+Final point on me: Justin Berman is my real name. I think anons are extremely important, and I debated using a nym myself. Ulimtately I feel having a balance of anons + non-anons is a good thing. Personally I want to show that sound, hard, private money should be a publicly acceptable, normal thing. I'm not a shadowy super coder, I'm just a normal dude who thinks normal people and businesses don't want to share all their financial information with the entire world :)
+
+## Proposal
+
+$24 + 0.08 Monero per hour for 40 hours a week, for 12 weeks starting August 30th, ending November 21st. At the current exchange rate of $290 / XMR from coingecko, this totals to [($24 / $290) XMR + 0.08 XMR] * 40 * 12 = [0.0828 XMR + 0.08 XMR] * 40 * 12 = ~78 Monero
+
+To be clear, I am comfortable accepting the volatility, and am requesting a total of 78 Monero for this proposal. I figure $24 + 0.08 Monero per hour is a good price point for future CCS proposals as well.
+
+As of right now, I'd like to work over 40 hours a week on this proposal and don't expect to be compensated for doing so, but if I do decide to take on contract work, I may end up working less than 40 hours a week on this proposal. My promise is to work a total of at least 40 * 12 hours = 480 hours, even if it extends past November 21st, though I anticipate working more than 480 hours over the period.
+
+I'll keep track of my hours and provide bi-weekly updates for the first 2 months, then a single update for the final month.
+
+**(*) Correction: previously stated that some recently spent outputs were definitively linkable as a result of the discovered bug, which [was not the case](https://www.getmonero.org/2021/09/20/post-mortem-of-decoy-selection-bugs.html).**

j-berman-3months-full-time-2.md

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: February 7, 2022
+amount: 135
+milestones:
+  - name: Month 1
+    funds: 33% (45 Monero)
+    done: 14 March 2022
+    status: finished
+  - name: Month 2
+    funds: 33% (45 Monero)
+    done: 13 April 2022
+    status: finished
+  - name: Month 3
+    funds: 33% (45 Monero)
+    done: 23 June 2022
+    status: finished
+payouts:
+  - date: 29 July 2022
+    amount: 135
+---
+
+Hi all, I love my new job and very much so hope that my performance has been satisfactory. I'm requesting 135 XMR to continue working on Monero full-time for the next 3 months (2/7/22 - 5/2/22).
+
+On my immediate radar, I'd like to help ensure the upcoming fork goes smoothly. I can take on the following:
+
+- help the ecosystem prepare for view tags:
+	- [monero-lws](https://github.com/vtnerd/monero-lws)
+	- [openmonero](https://github.com/moneroexamples/openmonero)
+	- potentially others if needed
+- help resolve merge conflicts between PR's
+- bump the ring size from 11 to 16 (tiny bit more effort than changing a single constant) (edit: PR for this [here](https://github.com/monero-project/monero/pull/8178))
+- whatever else I have the skills to help on
+
+Beyond the fork, here are some concrete tasks I'd also like to work on:
+
+### [Background wallet sync cache](https://github.com/monero-project/monero/issues/8082)
+
+This is a great idea by @hyc for wallets to continuously scan for a user's transactions in the background. This should make scanning a more pleasurable experience on mobile. The key idea behind the proposal is keeping the view key "hot" on the device, but *not* the spend key. This way wallets can more safely do this background scanning without leaving a spend key exposed.
+
+### Subaddresses in [`monero-lws`](https://github.com/vtnerd/monero-lws)
+
+I proposed a way to implement subaddresses in light wallet servers in [this PR](https://github.com/monero-project/meta/pull/647). I'd like to see this through to completion. To me, completion == there is a well-tested client-server implementation (with tests), where a frontend can interact with your own running `monero-lws` server. Been in communication with various light wallet ecosystem folks to move forward to flesh out the details of the API spec (shoutout to @endogenic, @vtnerd, and @ndorf for their involvement) :)
+
+### Complete monero-lws informal audit if there is demand
+
+If there is demand, I'm happy to complete [this review of monero-lws](https://github.com/vtnerd/monero-lws/pull/29) I started as part of my prior CCS. To be clear, I've read through the whole code base, and stand firm behind my conclusion that it is great software with no obvious backdoors. There are a number of files I left as "TO-DO's" in the review since it was taking up a lot more time than anticipated. Happy to fill it out if people would like.
+
+### Other tasks
+
+I have a running list of stuff I'd like to get to (some rolled over from last CCS):
+
+- complete [these issues](https://github.com/vtnerd/monero-lws/issues/created_by/j-berman) as needed in monero-lws + work through the suggestions shared in [my review](https://github.com/vtnerd/monero-lws/blob/16f1ceaa6a5eb4d9263863068bf57bc8e032a408/docs/review_02.03.22/review_02.03.22.md#suggestions)
+- continue investigating ways to make wallet scanning faster
+- pick up on research into [deterministic binning](https://github.com/monero-project/research-lab/issues/84)
+- [thread safety in the daemon RPC](https://github.com/monero-project/monero/pull/7936)
+- implement a rw lock for the Blockchain class
+- encrypt the wallet cache
+
+## Who
+
+j-berman on github, jberman on Matrix/IRC, and here is my [last CCS](https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html).
+
+Merged commits: [monero-project/monero](https://github.com/monero-project/monero/pulls?q=is%3Apr+author%3Aj-berman+is%3Aclosed), [openmonero](https://github.com/moneroexamples/openmonero/pulls?q=is%3Apr+author%3Aj-berman)
+
+Open commits: [monero-project](https://github.com/monero-project/monero/pulls/j-berman)
+
+## Proposal
+
+Requesting 135 XMR, which is a 25% raise from last CCS proposal from (0.08 XMR + $24)/hr to (0.1 XMR + $30)/hr, for 480 hours (12 weeks), at $168 / XMR from coingecko. This hourly rate totals to 133.8 XMR for the period (0.1 XMR + $30/$168 XMR = 0.279 XMR/hr * 480 hrs = ~133.8 XMR), which divides into 3 payments of 44.6 XMR. I rounded 44.6 XMR up to 45 XMR to land on a total of 135 XMR (3 * 45 = 135 XMR).
+
+My prior CCS, I ended up working about a month longer than expected without submitting another CCS, since I wanted to see things through to completion as best I could, and prioritize must-do work before spending time wrapping up the prior CCS, and writing this proposal. I'd like to have more flexibility and comfort in making a decision like that, which I feel a higher rate affords.
+
+I will share monthly updates, and will keep track of my hours as before, but likely won't be submitting an hourly time tracking spreadsheet with each update (it feels a little invasive and no one seems to care about it anyway, I probably shouldn't have done it in the first place). I'll also continue attending every #monero-research-lab + #monero-dev meeting I can, and sharing what I work on there when applicable.
+
+Final note: if I run into any bounties that I want to work on in the future (like [view tags](https://bounties.monero.social/posts/28/implement-view-tags-to-decrease-wallet-sync-times-in-monero)), I'd like to work on them as part of my CCS, and pay the bounty out to PR reviewers (and in some cases, to original idea-havers too). I'd like to have flexibility to make decisions on what I think would be most valuable for me to work on, but will always welcome feedback :)

j-berman-3months-full-time-3.md

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: July 18, 2022
+amount: 187.5 Monero
+milestones:
+  - name: Month 1
+    funds: 33% (62.5 Monero)
+    done: 14 September 2022
+    status: finished
+  - name: Month 2
+    funds: 33% (62.5 Monero)
+    done: 28 October 2022
+    status: finished
+  - name: Month 3
+    funds: 33% (62.5 Monero)
+    done: 28 October 2022
+    status: finished
+payouts:
+  - date: 4 November 2022
+    amount: 187.5
+---
+
+## What
+
+I'd like to continue full-time another 3 months in a similar capacity:
+
+- Continue with PR review (especially on larger time-intensive PR's), including wrapping up [8076](https://github.com/monero-project/monero/pull/8076) (reduce wallet load and refresh time).
+- Patch bugs.
+- Finish the background sync mode that enables scanning for txs without a spend key. My code is [here](https://github.com/j-berman/monero/commit/238ea538f218ad447808c6806386a73bb1ab0fd5) and is functional as is. I approached it cautiously and thoughtfully to ensure it's safe as I went along. I still have some final touches on it + tests to add to wrap it up, [described here](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/285#note_15356).
+- Potential tasks:
+	- Start going deeply through Seraphis code, implementing Jamtis features, and working toward completing a handoff from UkoeHB -> core repo. [From @UkoeHB](https://libera.monerologs.net/monero-research-lab/20220713#c120001): "Todos after [he finishes his final poc tasks]: investigate/implement the wallet-side features of Jamtis (RIDs, Polyseed, address authentication), build wallets that use the seraphis library interface for building/handling txs and enotes (full wallet, view-only wallet, multisig full wallet, payment validator), integrate seraphis into the daemon/ledger, ...".
+		- My own opinion on the state of Seraphis/Jamtis: both should undergo deeper review and round(s) of audits from independent parties and earn "rough consensus" before ultimately deployed. It would also be nice to see research into trustless zk-SNARKs move further along to have a better idea of how they could fit alongside Seraphis/Jamtis. Still, I think it would be valuable to start getting more finalized audit-able code prepared, especially code that likely wouldn't be impacted by the latter (such as RIDs, Polyseed, and address authentication).
+	- Work together with @endogenic on factoring wallet2.
+	- Implement subaddresses in `monero-lws` as per [this spec](https://github.com/monero-project/meta/pull/647). At this point, moving this forward feels dependent on others in the light wallet ecosystem and isn't fully in my hands (unless enough people want subaddress support in the server and don't need a client).
+- Whatever seems highest priority to work on to me that I know can add value on that comes along. As of this moment, [PR 7999](https://github.com/monero-project/monero/pull/7999) (a serialization overhaul) is a leading candidate; however, with 7999, there is a chance I'm unable to provide an adequately deep review that the PR requires as my skill level may not be at that point yet. If I do decide to work on 7999, I wouldn't count my hours toward my CCS unless those hours lead to demonstrable value that pushes what the PR aims to solve forward.
+
+## 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](https://www.getmonero.org/2021/09/20/post-mortem-of-decoy-selection-bugs.html))
+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](https://www.getmonero.org/2021/09/20/post-mortem-of-decoy-selection-bugs.html))
+3. `openmonero` was still using the old proven weak decoy selection algorithm, also leaving a fingerprintable trail by decoy selection algo. ([source](https://github.com/moneroexamples/openmonero/pull/177))
+4. MyMonero doesn't use the updated CLSAG fee calculation which fingerprints MyMonero txs on chain by tx fee. ([source](https://github.com/mymonero/mymonero-core-cpp/pull/35))
+5. MyMonero's fee calculation->input selection logic differs ever-so-slightly from the reference wallet, resulting in a fingerprintable tx fee. ([source](https://github.com/mymonero/mymonero-core-cpp/pull/36))
+6. `monero-lws` fee masking on the server also caused ever-so-slightly different fee calculations from the reference wallet, resulting in a fee fingerprintable to `monero-lws` (a fingerprint that is distinct from MyMonero). ([source](https://github.com/vtnerd/monero-lws/pull/31))
+7. In PR review on the upcoming hard fork's changes to the tx fee, identified the introduction of [slightly different fee calculation logic](https://github.com/monero-project/monero/pull/7819#discussion_r804404285) that would have caused tx fees to be fingerprintable to either old or new version until the hard fork.
+
+Most of the above took a significant amount of time to investigate and in some of the cases, patch. Some were really simple to patch, some were difficult but only took a couple lines.
+
+Some other contributions:
+
+- implemented [view tags](https://github.com/monero-project/monero/pull/8061) to speed up wallet scanning.
+- identified and patched daemon reliability issues, especially for users of tor/i2p daemons (moved forward solving long-standing issues [6631](https://github.com/monero-project/monero/issues/6631), [6929](https://github.com/monero-project/monero/issues/6929), and [6938](https://github.com/monero-project/monero/issues/6938)):
+	- [Tor/i2p daemons periodically send a peer list that gets itself dropped](https://github.com/monero-project/monero/pull/8324).
+	- [The daemon periodically drops outgoing tor/i2p connections](https://github.com/monero-project/monero/pull/8330).
+	- [Tx re-relay math was off](https://github.com/monero-project/monero/pull/8326).
+- since Ledger was fairly unresponsive, I implemented the changes for the upcoming hard fork needed to send and receive:
+	- [monero repo](https://github.com/j-berman/monero/commit/cfbd590fd63ff9e0c5ec68c618e2f3fdaf24d241)
+	- [ledger repo](https://github.com/j-berman/app-monero/commit/c1a6eb8bbbc1cc7974ce0938e9d8f920d0ad3ae9)
+- patched a [cryptographic vulnerability in monero-python](https://github.com/monero-ecosystem/monero-python/commit/ece5b9d4cd929ced9539dca839d8a9fda4271663) (identified by kayabaNerve) where a malicious sender can get an honest recipient (who's using `monero-python` to scan for txs) to assume they received an arbitrary amount chosen by the sender (e.g. a 0.00000001 XMR tx could be made to look like 1000 XMR).
+- [identified that the updated fee algorithm didn't implement the expected algorithmic block size increase at consensus](https://github.com/monero-project/monero/pull/7819#discussion_r799064615).
+- implemented view tags in:
+	- [the onion block explorer](https://github.com/moneroexamples/onion-monero-blockchain-explorer/pull/266)
+	- [monero-lws](https://github.com/vtnerd/monero-lws/pull/33)
+	- [openmonero](https://github.com/moneroexamples/openmonero/pull/181)
+
+## Proposal
+
+187.5 XMR. 480 hours, 0.12 XMR/hr + $36/hr, $133/XMR from coingecko.
+
+I'm requesting a raise from my prior CCS because I feel I have demonstrated my contributions are worth a more competitive rate, and can continue to provide (increasing) value to Monero in a full-time capacity.

j-berman-3months-full-time-4.md

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: November 21, 2022
+amount: 253 Monero
+milestones:
+  - name: Month 1
+    funds: 33% (84.3 Monero)
+    done: 31 December 2022
+    status: finished
+  - name: Month 2
+    funds: 33% (84.3 Monero)
+    done: 21 February 2023
+    status: finished
+  - name: Month 3
+    funds: 33% (84.4 Monero)
+    done: 16 May 2023
+    status: finished
+payouts:
+  - date: 23 February 2023
+    amount: 168.6
+  - date: 21 May 2023
+    amount: 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](https://github.com/monero-project/monero/issues/8520#issuecomment-1310975634), [zmq missing publishing txs submitted to the daemon](https://github.com/monero-project/monero/pull/8427), [recovering multisig wallets from seed](https://github.com/monero-project/monero/issues/8537#issuecomment-1233946415), 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](https://github.com/monero-project/monero/pull/8076) 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](https://github.com/seraphis-migration/wallet3/issues/8#issue-1368934355): "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](https://github.com/monero-project/monero/issues/8157)). 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](https://github.com/seraphis-migration/wallet3/issues/21).
+  - 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](https://www.getmonero.org/2021/09/20/post-mortem-of-decoy-selection-bugs.html))
+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](https://www.getmonero.org/2021/09/20/post-mortem-of-decoy-selection-bugs.html))
+3. `openmonero` was still using the old proven weak decoy selection algorithm, also leaving a fingerprintable trail by decoy selection algo. ([source](https://github.com/moneroexamples/openmonero/pull/177))
+4. MyMonero didn't use the updated CLSAG fee calculation which fingerprinted MyMonero txs on chain by tx fee. ([source](https://github.com/mymonero/mymonero-core-cpp/pull/35))
+5. MyMonero's fee calculation->input selection logic differed ever-so-slightly from the reference wallet, resulting in a fingerprintable tx fee. ([source](https://github.com/mymonero/mymonero-core-cpp/pull/36))
+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](https://github.com/vtnerd/monero-lws/pull/31))
+7. In PR review on the latest hard fork's changes to the tx fee, identified the introduction of [slightly different fee calculation logic](https://github.com/monero-project/monero/pull/7819#discussion_r804404285) that would have caused tx fees to be fingerprintable to either old or new version until the hard fork.
+
+Other contributions:
+
+- Implemented [view tags](https://github.com/monero-project/monero/pull/8061) to speed up wallet scanning.
+- Implemented [background sync](https://github.com/monero-project/monero/pull/8619) initially proposed by @hyc so that wallets can scan for transactions in the background when the user is not active, without the spend key loaded in memory.
+- Identified and patched daemon reliability issues (moved forward solving issues [8520](https://github.com/monero-project/monero/issues/8520), [6631](https://github.com/monero-project/monero/issues/6631), [6929](https://github.com/monero-project/monero/issues/6929), and [6938](https://github.com/monero-project/monero/issues/6938)):
+	- [Tor/i2p daemons periodically send a peer list that gets itself dropped](https://github.com/monero-project/monero/pull/8324).
+	- [The daemon periodically drops outgoing tor/i2p connections](https://github.com/monero-project/monero/pull/8330).
+	- [Tx re-relay math was off](https://github.com/monero-project/monero/pull/8326).
+- Implemented the changes needed for Ledgers to function for the latest hard fork:
+	- [monero repo](https://github.com/j-berman/monero/commit/cfbd590fd63ff9e0c5ec68c618e2f3fdaf24d241)
+	- [ledger repo](https://github.com/j-berman/app-monero/commit/c1a6eb8bbbc1cc7974ce0938e9d8f920d0ad3ae9)
+
+Prior CCS proposals:
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
+- https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html
+
+## 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.

j-berman-3months-full-time-5.md

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: July 26, 2023
+amount: 216 Monero
+milestones:
+  - name: Month 1
+    funds: 33% (72 Monero)
+    done: 21 September 2023
+    status: finished
+  - name: Month 2
+    funds: 33% (72 Monero)
+    done: 19 October 2023
+    status: finished
+  - name: Month 3
+    funds: 33% (72 Monero)
+    done: 18 November 2023
+    status: finished
+payouts:
+  - date: 8 November 2023
+    amount: 72
+  - date: 2 December 2023
+    amount: 144
+---
+
+## What
+
+Work full-time 3 months on:
+
+- Continuing Seraphis wallet library work.
+  - My next task is to complete an async wallet scanner implementation using the Seraphis wallet lib that points to `monerod`.
+    - I have a working implementation that can be tested as described [here](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/359#note_21276).
+    - When I point this async scanner on my local machine to a remote `monerod` instance @selsta spun up, I observe a **~40% speed-up in scanning** over the current wallet2 scanner.
+    - The bulk of the remaining work to get it to PR-ready includes:
+      - Explore replacing the existing epee http client lib with a widely used http client lib like libcurl. This avoids needing to rewrite the epee http client lib to safely handle concurrent network requests.
+      - Code cleaning/factoring.
+      - Unit tests.
+  - Once I complete the async scanner, I plan to collaborate with @dangerousfreedom @rbrunner7 and the no-wallet-left-behind working group to work on whatever is next highest priority to get the Seraphis wallet lib ready for production.
+- Integrating [full chain membership proofs](https://github.com/kayabaNerve/full-chain-membership-proofs/) into the Seraphis library (and therefore demonstrate how to integrate them into the core Monero repo). The goal is to construct and verify Seraphis transactions using full chain membership proofs, including a suite of unit tests and benchmarks.
+  - In my view, before Monero could actually consider accepting a PR for full chain membership proofs, there is a large amount of work still needed to prove its security and to land on a ready-for-production design. That work is currently proceeding in parallel. I would personally like to proceed with the above implementation work to maximize certainty that the Seraphis upgrade path is compatible with reasonably efficient full chain membership proofs.
+- Miscellaneous Monero work, debug issues, review PR's.
+
+## Who
+
+j-berman on github / jberman on matrix
+
+Past CCS's:
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-4.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
+- https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html
+
+## Proposal
+
+216 XMR
+
+480 hours, 0.16 XMR/hr + $48/hr, $166/XMR from coingecko

j-berman-3months-full-time-6.md

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: December 18, 2023
+amount:  211 Monero
+milestones:
+  - name: Month 1
+    funds: 33% (70.3 Monero)
+    done: 23 February 2024
+    status: finished
+  - name: Month 2
+    funds: 33% (70.3 Monero)
+    done: 4 April 2024
+    status: finished
+  - name: Month 3
+    funds: 33% (70.4 Monero)
+    done: 1 May 2024
+    status: finished
+payouts:
+  - date: 4 March 2024
+    amount: 70.3
+  - date: 9 April 2024
+    amount: 70.3
+  - date: 14 May 2024
+    amount: 70.4
+---
+
+## What
+
+Work full-time 3 months on:
+
+- Continuing Seraphis wallet library work.
+  - Complete the async wallet scanner implementation using the Seraphis wallet lib.
+    - When I pointed this async scanner on my local machine to a remote `monerod` instance @selsta spun up, I observed a **~40% speed-up in scanning** over the current wallet2 scanner.
+    - Link to the draft PR that details all remaining TODO's in the PR description: https://github.com/UkoeHB/monero/pull/23
+    - This CCS proposal will not be complete until I complete all major TODO's from the PR linked above, and deliver a final version of the async scanner PR for review.
+  - Once I complete the async scanner, I plan to collaborate further with @jeffro256 @rbrunner7 @dangerousfreedom and the no-wallet-left-behind working group to work on whatever is next highest priority to get the Seraphis wallet lib ready for production.
+- Continue work integrating [full chain membership proofs](https://github.com/kayabaNerve/full-chain-membership-proofs/) into the Seraphis library (and therefore demonstrate how to integrate them into the core Monero repo). The goal is to construct and verify Seraphis transactions using full chain membership proofs, including a suite of unit tests and benchmarks.
+  - In my last CCS, I got an initial setup working to call full chain membership proof code written in Rust from a Monero repo C++ performance test. This was step 1-of-many toward the goal of constructing a full chain membership proof in a transaction using the Seraphis wallet lib.
+- Miscellaneous Monero work, debug issues, review PR's.
+  - Highest on my list right now is to review @vtnerd's p2p encryption implementation (source: https://github.com/monero-project/monero/pull/8996).
+
+## Who
+
+j-berman on github / jberman on matrix
+
+Past CCS's:
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-5.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-4.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
+- https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html
+
+## Proposal
+
+211 XMR
+
+480 hours, 0.16 XMR/hr + $48/hr, $172/XMR from coingecko

j-berman-3months-full-time-7.md

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: May 2, 2024
+amount:  376 Monero
+milestones:
+  - name: Month 1
+    funds: 33% (125.3 Monero)
+    done: 25 May 2024
+    status: finished
+  - name: Month 2
+    funds: 33% (125.3 Monero)
+    done: 10 July 2024
+    status: finished
+  - name: Month 3
+    funds: 33% (125.4 Monero)
+    done: 16 August 2024
+    status: finished
+payouts:
+  - date: 17 June 2024
+    amount: 125.3
+  - date: 17 July 2024
+    amount: 125.3
+  - date: 30 August 2024
+    amount: 125.4
+---
+
+## What
+
+Work full-time 3 months on:
+
+- Integrating [full-chain-membership proofs](https://ccs.getmonero.org/proposals/fcmp++-development.html) into Monero under RingCT.
+  - As part of this CCS, I will submit PR's to the core Monero repository that do the following:
+    - Implements the tree in C++ described in section 6.1 ([paper](https://github.com/kayabaNerve/fcmp-ringct/blob/develop/fcmp%2B%2B.pdf), [reference commit](https://github.com/kayabaNerve/fcmp-ringct/blob/221e8c0e155d5fe526080c6e56c6418e0433177d/fcmp%2B%2B.pdf))
+      - Implements the `grow` and `trim` algorithms (sections 6.1.1 and 6.1.2)
+    - Implements tree initialization with existing cryptonote outputs on boot (section 6.2.1)
+    - Implements growing the tree as the node syncs (section 6.2.2 and 6.2.3)
+    - Implements the transaction class containing FCMP's (part of sections 6.3 - 6.6)
+      - I will probably extend `cryptonote::transaction` to do this.
+  - The following tasks from the rest of section 6 are necessary to complete the integration; I'm happy to divide and conquer if someone wants to work on this as well:
+    - Implement transaction construction with FCMP's (sections 6.3 - 6.6)
+      - A pre-requisite for this is implementing the transaction class above.
+    - Implement transaction verification (section 6.7)
+    - Implement RPC route to return a path for outputs (section 6.9)
+    - Implement unifying the distribution of {coinbase, pre-RCT, RCT} outputs and use it to select decoys paths (section 6.10)
+    - Implement changes for multisig (section 6.11)
+- Continuing Seraphis wallet library work.
+  - My next task on this front is to bring the Serpahis lib async scanner into the current wallet API.
+    - To be clear, this is not implementing the Seraphis upgrade; it is bringing the Seraphis wallet **library**, which supports scanning today's blockchain, into the core Monero repository. This would speed up wallet scanning **today**, and is part of an effort to deprecate wallet2 and its technical debt, and replace it with the Seraphis lib ([source](https://github.com/seraphis-migration/wallet3/issues/64#issuecomment-2067030930)).
+    - The async scanner is currently under review ([source](https://github.com/UkoeHB/monero/pull/23))
+    - In the latest round of benchmarks, I observed scanning speed-ups of 50-60% with a clearnet remote node, 40-45% with a tor node, 25-35% with a local node, all running the **current chain** (not Seraphis).
+    - To be usable in the wallet API today, the following still needs to be implemented (I'm also happy to divide and conquer here):
+      - Pre-RCT index handling (needs [source](https://github.com/UkoeHB/monero/pull/23))
+      - A mutable subaddress lookahead ([source](https://github.com/UkoeHB/monero/pull/23#issuecomment-2036086371))
+      - Pool scanning ([source](https://github.com/UkoeHB/monero/issues/41))
+      - A clean way to save tx metadata ([source](https://github.com/UkoeHB/monero/issues/48))
+- Complete p2p SSL review ([source](https://github.com/monero-project/monero/pull/8996)).
+- Misc. review, debugging, etc.
+
+## Who
+
+j-berman on github / jberman on matrix / IRC
+
+Past CCS's:
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-6.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-5.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-4.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
+- https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html
+
+## Proposal
+
+376 XMR
+
+480 hours, 0.25 XMR/hr + $65/hr, $122/XMR from coingecko
+
+I'm requesting a siginificant raise from my past CCS (0.16 XMR/hr -> 0.25 XMR/hr, $48/hr -> $65/hr) because I believe I have demonstrated improved performance, and believe the recent donations to CCS proposals demonstrate the community is capable of paying strong Monero contributors market / above-market rates. I believe paying market / above-market rates for strong contributors is a stronger strategy for Monero to attract and retain strong talent.

j-berman-3months-full-time-8.md

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: August 26, 2024
+amount:  317 Monero
+milestones:
+  - name: Month 1
+    funds: 33% (105 Monero)
+    done: 14 October 2024
+    status: finished
+  - name: Month 2
+    funds: 33% (106 Monero)
+    done: 11 November 2024
+    status: finished
+  - name: Month 3
+    funds: 33% (106 Monero)
+    done: 12 December 2024
+    status: finished
+payouts:
+  - date: 20 October 2024
+    amount: 105
+  - date: 19 November 2024
+    amount: 106
+  - date: 12 January 2025
+    amount: 106
+---
+
+## What
+
+Work full-time 3 months on:
+
+- Integrating full-chain membership proofs++ into Monero under RingCT.
+  - As part of this CCS, I will prioritize and guarantee completion of the following in this PR: https://github.com/monero-project/monero/pull/9436
+    1. Trim the tree on reorgs and when popping blocks.
+    2. Key image migration.
+    3. Optimize tree building where possible.
+        - Multithreaded output conversion to leaves.
+        - Multithreaded hashing.
+        - Batched inversion.
+    4. Construct fcmp++ transactions.
+        - I anticipate updating `cryptonote::construct_tx_and_get_tx_key` for this, and not touching wallet2 in this proposal.
+        - By the end of this proposal, there will be a modular function wallets can use to construct fcmp++ txs, but I may not have an end-to-end functioning wallet that can construct fcmp++ txs implemented by the end of this proposal.
+    5. Verify fcmp++ transactions.
+    6. Consensus changes for fcmp++.
+        - New unlock time logic.
+        - Allowing new fcmp++ RCT type.
+        - Implement a grace period for current tx types in the pool at the fork to make it into the chain.
+        - Misc. necessary changes.
+  - Work together with @dangerousfreedom on full wallet scanning.
+  - The remaining integration tasks that I would also work on if time permits and someone else doesn't:
+    - Construct fcmp++ transactions in a fully functional wallet.
+      - Pre-requisites: modular function to construct fcmp++ transactions and full wallet scanning.
+    - Implement the RPC route for light wallets to query for paths in the curve trees tree.
+    - Wallet changes for background syncing.
+    - Multisig.
+- Continuing Seraphis wallet library work.
+  - Making it clear up front: I anticipate not making much progress on the Seraphis wallet library work in this CCS. I plan to prioritize fcmp++. If time permits, I would work on bringing the Seraphis wallet library to production.
+  - To be clear, working on the Seraphis wallet library is not implementing the Seraphis upgrade; it is bringing the Seraphis wallet library, which supports scanning today's blockchain, into the core Monero repository. This would speed up wallet scanning today, and is part of an effort to deprecate wallet2 and its technical debt, and replace it with the Seraphis lib ([source](https://github.com/seraphis-migration/wallet3/issues/64#issuecomment-2067030930)).
+  - Next I plan to resolve merge conflicts in the current open PR's, and open all piecemeal PR's to the core Monero release branch to prepare Monero daemons/wallets and reduce the size and scope of the async scanner PR.
+- Misc. review, debugging, etc.
+
+## Who
+
+j-berman on github / jberman on matrix / IRC
+
+Past CCS's:
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-7.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-6.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-5.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-4.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
+- https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html
+
+## Proposal
+
+317 XMR
+
+480 hours, 0.25 XMR/hr + $65/hr, $158/XMR from coingecko

j-berman-3months-full-time-9.md

+---
+layout: wip
+title: j-berman full-time development (4 months)
+author: j-berman
+date: December 16, 2024
+amount: 360 Monero
+milestones:
+  - name: Month 1
+    funds: 25% (90 Monero)
+    done: 21 January 2025
+    status: finished
+  - name: Month 2
+    funds: 25% (90 Monero)
+    done: 24 February 2025
+    status: finished
+  - name: Month 3
+    funds: 25% (90 Monero)
+    done:
+    status: unfinished
+  - name: Month 4
+    funds: 25% (90 Monero)
+    done:
+    status: unfinished
+payouts:
+  - date: 4 February 2025
+    amount: 90
+  - date: 19 March 2025
+    amount: 90
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+## What
+
+Work full-time 4 months on:
+
+- Work towards a test network that includes Full-Chain Membership Proofs++.
+  - Continue optimizing building the FCMP++ curve tree to improve sync time both in the daemon and wallet.
+  - Construct FCMP++ transactions via the CLI/RPC/GUI.
+  - Verify FCMP++ transactions in the daemon.
+  - Implement all consensus changes needed for FCMP++.
+    - New unlock time logic.
+    - Allowing new FCMP++ RCT type.
+    - Implement a grace period for current tx types in the pool at the fork to make it into the chain.
+    - Misc. necessary changes.
+  - Update the cold wallet <> hot wallet integration and background syncing for FCMP++.
+- Misc. high priority tasks as they arise.
+
+## Who
+
+j-berman on github / jberman on matrix / IRC
+
+My open PR for the WIP FCMP++ integration: https://github.com/monero-project/monero/pull/9436
+
+My branch that includes the wallet sync integration: https://github.com/j-berman/monero/commits/fcmp%2B%2B-tree-sync-dev/
+
+Past CCS's:
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-8.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-7.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-6.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-5.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-4.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
+- https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html
+
+## Proposal
+
+360 XMR
+
+640 hours, 0.25 XMR/hr + $65/hr, $208/XMR from coingecko

janowitz-polish-translation-gui-web-subtitles.md

 ---
-layout: fr
+layout: cp
 title: Translation of GUI Wallet, monero-site, Monero Means Money (subtitles), Sound Money, Safe Mode (subtitles) to Polish.
 author: janowitz
 date: November 30, 2020
-amount: 28
+amount: 22
 milestones:
   - name: Milestone 1 - Completion of GUI Wallet, monero-site Translation to Polish
-    funds: 5 XMR
-    done:
-    status: unfinished
+    funds: 4 XMR
+    done: 20 April 2021
+    status: finished
   - name: Milestone 2 - Completion of Monero Means Money (subtitles) Translation to Polish
-    funds: 11 XMR
-    done:
-    status: unfinished
+    funds: 9 XMR
+    done: 15 July 2021
+    status: finished
   - name: Milestone 3 - Completion of Sound Money, Safe Mode (subtitles) Translation to Polish
-    funds: 12 XMR
-    done:
-    status: unfinished
+    funds: 9 XMR
+    done: 25 August 2021
+    status: finished
 payouts:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
+  - date: 26 August 2021
+    amount: 22
 ---
 
 # About this Proposal
@@ -71,4 +67,4 @@ Comprises of 12,404 words, which equals to 12 XMR.
 
 Timeline: 11/01/2021 - 24/01/2021
 
-**Proposal Expiration Date**: 14/12/2020
\ No newline at end of file
+**Proposal Expiration Date**: 14/12/2020

jeffro256-full-time-2023Q3.md

+---
+layout: cp
+title: jeffro256 full-time development 2023Q3
+author: jeffro256
+date: May 30, 2023
+amount: 147
+milestones:
+  - name: Month 1
+    funds: 33% (49.0)
+    done: 3 August 2023
+    status: finished
+  - name: Month 2
+    funds: 33% (49.0)
+    done: 7 September 2023
+    status: finished
+  - name: Month 3
+    funds: 33% (49.0)
+    done: 17 October 2023
+    status: finished
+payouts:
+  - date: 16 August 2023
+    amount: 49
+  - date: 12 September 2023
+    amount: 49
+  - date: 3 November 2023
+    amount: 49
+---
+
+## What
+
+I plan to work full-time to work towards accomplishing:
+1. Implementing Seraphis wallet code with Ukoe, jberman, et al.
+2. Drafting a formal specification for decoy selection and implementing it in a modular, robust, easily-testable way, and then creating a multitude of unit tests, integration tests, and statistical checks for this code.
+3. Reviewing other Monero core PRs, especially those related to Seraphis or @vtnerd's serialization changes.
+
+To expand on point 2, I think the decoy selection code is in need of a makeover. In light of recent, high-impact decoy selection bugs (more info [here](https://www.getmonero.org/2021/09/20/post-mortem-of-decoy-selection-bugs.html) and [here](https://github.com/monero-project/monero/issues/8872)), and whereas ring signatures are generally regarded as the weakest link in Monero's privacy model, I believe a new development initiative needs to take place to replace the decoy selection code. Typically I am against refactoring code "just because", but in this case it is warranted. All of the aforementioned bugs could have been spotted by statistical checks. However, currently, it is rather difficult to test the decoy selection in isolation due to the monolithic design of `wallet2`. In theory, decoy selection code could be written to be rather functional. To over-simplify, we take distribution of enotes on-chain usable for given for true spends, apply arbitrary picker distribution, then request information for selected decoys over RPC, retrying the process if enotes are blackballed or otherwise unsuitable. There are a lot of edge cases to consider, but there isn't any major reason why decoy selection can't be modularized and standarized apart from the rest of the wallet code. This goal also overlaps with point number 1, since this code can be used not only in `wallet2`, but in future versions of core wallets if written correctly.
+
+## Who
+
+I have been contributing to the Monero core repository for [over a year](https://github.com/monero-project/monero/pulls?page=2&q=is%3Apr+author%3Ajeffro256) with a total of [>=48 merged commits](https://github.com/monero-project/monero/graphs/contributors?from=2022-01-25&to=2023-05-30&type=c) thus far. Some more notable contributions:
+
+* Implemented [research issue 109](https://github.com/monero-project/research-lab/issues/109) by [authoring a PR](https://github.com/monero-project/monero/pull/8815) that, when spending coinbase enotes, chooses coinbase enotes as decoys and vice versa.
+* [Implemented](https://github.com/monero-project/monero/pull/8861) a requested wallet transfer feature that enables "fee-included" transactions
+* [Found and fixed](https://github.com/monero-project/monero/pull/8707) an issue which nearly allowed a double spend bug, and could cause double spend bugs in the future if the code was not carefully inspected
+* Helped review [patch](https://github.com/monero-project/monero/pull/8794) and write [disclosure report](https://github.com/monero-project/monero/issues/8872) on recent decoy selection bug.
+
+Previous Proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319
+
+## Payment
+
+I propose to work 40 hours/week for 3 months so 480 hours total. I'm setting my hourly rate at ~$43/hour, and at a price of $140/XMR (as of June 10th 2023), this makes for a total of 147.4 XMR. The proposal is broken into 3 milestones, one for each "month". These milestones may lag behind schedule if I do not complete 40 hours per calendar week, but in that event, I will not ask for payout until the hours are done.
+

jeffro256-full-time-2023Q4.md

+---
+layout: cp
+title: jeffro256 full-time development 2023Q4
+author: jeffro256
+date: Oct 25, 2023
+amount: 147
+milestones:
+  - name: Month 1
+    funds: 33% (47.0)
+    done: 28 December 2023
+    status: finished
+  - name: Month 2
+    funds: 33% (47.0)
+    done: 29 January 2024
+    status: finished
+  - name: Month 3
+    funds: 33% (47.0)
+    done:
+    status: unfinished
+payouts:
+  - date: 6 January 2024
+    amount: 47.8
+  - date: 23 February 2024
+    amount: 46.2
+  - date: 4 March 2024
+    amount: 53
+---
+
+## What
+
+I plan to work full-time to work towards implementing the Jamtis changes discussed by tevador, myself, and others, [here](https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4665372#gistcomment-4665372), [here](https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4692457#gistcomment-4692457), [here](https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4706509#gistcomment-4706509), and [here](https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4708912#gistcomment-4708912). In summary, I will work to implement flexible-sized view tags, light wallet privacy protections, the simplified key derivation structure, and auxiliary enote records, all together. I have already began work on this, which you can see on [this branch](https://github.com/jeffro256/monero/tree/jamtis_lw_take_2).
+
+I also want to begin work on the new wallet after these Jamtis changes are implemented and reviewed. There are many new wallet types enabled by Jamtis, and much thought is needed to be put into the design so that the code stays easily maintainable and robust. I want to spend a lot of time in the design phase for the wallet so we end up in a better scenario than we are in with `wallet2`. 
+
+## Who
+
+I have been contributing to the Monero core repository for [over a year](https://github.com/monero-project/monero/pulls?page=2&q=is%3Apr+author%3Ajeffro256) with a total of [>=69 merged commits](https://github.com/monero-project/monero/graphs/contributors?from=2022-01-25&to=2023-05-30&type=c) thus far. I also began working on the Seraphis migration project, so you can see some of my contributions [here](https://github.com/seraphis-migration/monero/pulls?q=is%3Apr+author%3Ajeffro256) and [here](https://github.com/UkoeHB/monero/pulls?q=is%3Apr+author%3Ajeffro256). Some more notable contributions from this last quarter:
+
+- I [wrote a library](https://github.com/seraphis-migration/monero/pull/4) that is able to load and store into the `wallet2` format without a dependency on `wallet2`. The way it is written allows for very robust conversion, even for hardware wallets, without the hardware being present. It is much more modular than the current `wallet` loading/storing code, and thus should be helpful in the Seraphis migration.
+- I found a solution to some of the privacy problems with Jamtis light wallets and [opened a PR](https://github.com/UkoeHB/monero/pull/15) to fix those issues. I also discussed further changes on the linked Jamtis gist, and will continue to refine Jamtis.
+- I [wrote documentation](https://github.com/monero-project/monero/pull/9024) for Monero decoy selection, as well as an easy-to-read, testable, modular Python script.
+
+Previous Proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/390
+
+## Payment
+
+I propose to work 40 hours/week for 3 months so 480 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 $44/hr, and at a market price of 150 USD/XMR, that makes for a total of 141 XMR.

jeffro256-full-time-2024Q2.md

+---
+layout: cp
+title: jeffro256 full-time development 2024Q2
+author: jeffro256
+date: Feb 27, 2024
+amount: 171
+milestones:
+  - name: Month 1
+    funds: 33% (57.0)
+    done: 7 April 2024
+    status: finished
+  - name: Month 2
+    funds: 33% (57.0)
+    done: 12 May 2024
+    status: finished
+  - name: Month 3
+    funds: 33% (57.0)
+    done: 13 June 2024
+    status: finished
+payouts:
+  - date: 9 April 2024
+    amount: 57
+  - date: 18 May 2024
+    amount: 57
+  - date: 18 June 2024
+    amount: 57
+---
+
+## What
+
+I plan to continue work full-time moving towards a Seraphis testnet (and wallet if I have time). These next dev cycles will likely be spent on writing production-ready serialization code, adding support for validating Seraphis transactions to the Cryptonote core, adding database backing support for these transactions, etc (generally weaving the Seraphis library into the core codebase in a way that makes it active). I have already began expanding Seraphis transaction support by beginning work on a transaction class and paired serialization code which will let us capture all possible Monero-compatible transaction forms and handle them in the codebase (expanded on below). 
+
+## Who
+
+I have been contributing to the Monero core repository for [just over two years](https://github.com/monero-project/monero/pulls?page=2&q=is%3Apr+author%3Ajeffro256) with a total of [57 merged commits to master](https://github.com/monero-project/monero/commits?author=jeffro256) thus far. I also began working on the Seraphis migration project, so you can see some of my contributions [here](https://github.com/seraphis-migration/monero/pulls?q=is%3Apr+author%3Ajeffro256) and [here](https://github.com/UkoeHB/monero/pulls?q=is%3Apr+author%3Ajeffro256). Some more notable contributions from this last quarter:
+
+- Polished [Jamtis changes draft PR](https://github.com/UkoeHB/monero/pull/26) and wrote up changes to the "Implementing Seraphis" paper, which were [approved by @UkoeHB](https://github.com/UkoeHB/Seraphis/pull/6).
+- Began work on creating a [transaction type](https://github.com/jeffro256/monero/tree/monero_tx_variant) that encapsulates all past and Seraphis future transaction forms: cryptonote v1, v2, coinbase, Seraphis squashed, coinbase, with serialization that is backwards compatible. Along this same line, I wrote a [PR](https://github.com/monero-project/monero/pull/9174) that would help the LMDB backend code transition to Seraphis transactions.
+- Wrote a [PR](https://github.com/monero-project/monero/pull/9135) that reduces hard disk usage for nodes.
+- Reviewed @j-berman's [background sync PR](https://github.com/monero-project/monero/pull/8619).
+
+Previous Proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/390
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/421
+
+## 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 45 USD/hour (+1 USD/hour higher than last quarter), and at a market price of 136.88 USD/XMR, that makes for a total of 171 XMR. Price was calculated as 14-day simple average of opening prices on [CoinGecko](https://www.coingecko.com/en/coins/monero/historical_data) from 2024-02-23 to 2024-03-07 (day of writing).

jeffro256-full-time-2024Q3.md

+---
+layout: cp
+title: jeffro256 full-time development 2024Q3
+author: jeffro256
+date: June 14, 2024
+amount: 146
+milestones:
+  - name: Month 1
+    funds: 33% (48.0)
+    done: 16 July 2024
+    status: finished
+  - name: Month 2
+    funds: 33% (49.0)
+    done: 11 August 2024
+    status: finished
+  - name: Month 3
+    funds: 33% (49.0)
+    done: 14 September 2024
+    status: finished
+payouts:
+  - date: 17 July 2024
+    amount: 48
+  - date: 14 August 2024
+    amount: 49
+  - date: 27 September 2024
+    amount: 49
+---
+
+## What
+
+In the last three months, the likely direction of the future of the Monero protocol changed
+drastically with all the work done to bring FCMPs to RingCT. At my last CCS proposal, I
+proposed that I would be working on the Seraphis wallet and consensus integrations. Then
+I shifted gears to implementing [Jamtis-RCT](https://gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96#).
+I propose to refine this codebase and produce and LWS-client demo, in order to have these
+set of features complete before the FCMP++ upgrade, assuming all goes well. This codebase
+can currently construct `cryptonote::transaction`s with Jamtis info encode in the `extra` field,
+and then successfully scan that data. Here is a non-exhaustive list of points that need
+work with this library:
+
+- Legacy address integration and testing
+- Optimization: post-primary-view-tag scanning is about 20% slower than expected
+- Testing against actual FCMP++ composition proofs
+- Multi-threaded compute
+- A live, over-the-wire LWS demo for evaluating the filter-assist/hidden enote trade-offs
+
+I would also like to work on replacing `wallet2` internals with the Seraphis library 'legacy handling'
+code, as discussed at this Github issue: https://github.com/seraphis-migration/wallet3/issues/64. A few people
+are already working on it, but it will need a lot of manpower to bring it to fruition.
+
+
+## Who
+
+I have been contributing to the Monero core repository for [over two years](https://github.com/monero-project/monero/pulls?page=2&q=is%3Apr+author%3Ajeffro256) with a total of [68 merged commits to master](https://github.com/monero-project/monero/commits?author=jeffro256) thus far. I also began working on the Seraphis migration project, so you can see some of my contributions [here](https://github.com/seraphis-migration/monero/pulls?q=is%3Apr+author%3Ajeffro256) and [here](https://github.com/UkoeHB/monero/pulls?q=is%3Apr+author%3Ajeffro256). Some more notable contributions from this last quarter:
+
+- Implemented [Jamtis-RCT](https://gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96#) into the Seraphis library [here](https://github.com/jeffro256/monero/tree/jamtis_rct). This branch provides support for storing Jamtis scanning data into `tx_extra`, and performs a unit test where a pruned transaction is constructed addressed to Jamtis payment proposals, and then successfully scanned for both plain and self-send enote types. The way this branch was written merges the code paths for doing Jamtis on RingCT and Seraphis together. It could use some cleaning up, and the Seraphis multisig tests need to be updated, but otherwise all Seraphis tests are passing.
+- Some other Seraphis stuff including a unified transaction format for Cryptonote, RingCT, and Squashed-Seraphis transactions.
+
+Previous Proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/390
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/421
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/436
+
+## 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 46 USD/hour (+1 USD/hour higher than last quarter), and at a market price of 163.97 USD/XMR, that makes for a total of 146.2 XMR. Price was calculated as 14-day simple average of opening prices on [CoinGecko](https://www.coingecko.com/en/coins/monero/historical_data) from 2024-06-01 to 2024-06-14 (day of writing), same as last quarter.

jeffro256-full-time-2024Q4.md

+---
+layout: cp
+title: jeffro256 full-time development 2024Q4
+author: jeffro256
+date: September 16, 2024
+amount: 144
+milestones:
+  - name: Month 1
+    funds: 33% (48.0)
+    done: 9 November 2024
+    status: finished
+  - name: Month 2
+    funds: 33% (48.0)
+    done: 12 December 2024
+    status: finished
+  - name: Month 3
+    funds: 33% (48.0)
+    done: 14 January 2025
+    status: finished
+payouts:
+  - date: 12 November 2024
+    amount: 48
+  - date: 12 January 2025
+    amount: 48
+  - date: 23 January 2025
+    amount: 48
+---
+
+## What
+
+The last quarter I began implementing [Jamtis-RCT](https://gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96), 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](https://github.com/jeffro256/carrot/blob/master/carrot.md), 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. 
+
+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
+
+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](https://github.com/monero-project/monero/pulls?page=2&q=is%3Apr+author%3Ajeffro256) with a total of [76 merged commits to master](https://github.com/monero-project/monero/commits?author=jeffro256) thus far, with many open PRs. I also began working on the Seraphis migration project, so you can see some of my contributions [here](https://github.com/seraphis-migration/monero/pulls?q=is%3Apr+author%3Ajeffro256) and [here](https://github.com/UkoeHB/monero/pulls?q=is%3Apr+author%3Ajeffro256). Additionally, as I mentioned, last quarter I wrote up the [Carrot specification](https://github.com/jeffro256/carrot/blob/master/carrot.md) for formal auditing, which will be the main addressing protocol post-FCMP++ if all goes according to plan.
+
+Previous Proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/390
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/421
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/436
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/467
+
+## 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](https://www.coingecko.com/en/coins/monero/historical_data) from 2024-09-04 to 2024-09-17 (day of writing), same as last quarter.
+

jeffro256-full-time-2025Q1.md

+---
+layout: wip
+title: jeffro256 full-time development 2025Q1
+author: jeffro256
+date: January 27, 2025
+amount: 114
+milestones:
+  - name: Month 1
+    funds: 33% (38.0)
+    done: 18 February 2025
+    status: finished
+  - name: Month 2
+    funds: 33% (38.0)
+    done:
+    status: unfinished
+  - name: Month 3
+    funds: 33% (38.0)
+    done:
+    status: unfinished
+payouts:
+  - date: 24 February 2025
+    amount: 38
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+## What
+
+The last quarter I implemented the core cryptography for [Carrot](https://github.com/jeffro256/carrot/blob/master/carrot.md). I will note that preliminary performance tests put Carrot scanning at about 30% faster on CPU usage versus scanning today, mostly thanks to the use of the X25519 ECDH library [mx25519](https:://github.com/tevador/mx25519). I also implemented pruned `cryptonote::transaction` [construction and scanning](https://github.com/monero-project/monero/pull/9697) for Carrot. The FCMP++ integration and Carrot integration are finally meeting ends and are almost ready for hot path integration. This next quarter, I want to continue this work to get a testnet out ASAP.
+
+To recap, here is a list of things I will attempt to work on this quarter, in rough order of execution:
+
+- Integrate Carrot scanning/transaction construction into main wallet codepaths
+- Provide support to existing hardware wallet manufacturors on how to securely support Carrot outputs
+- Use benchmarkings and static analysis to inform MRL decisions on transaction weight discussions etc
+- Begin soliciting Carrot core implementation audits
+- Provide Rust implementation of Carrot for Serai/Cuprate
+- Solicit help for multisig implementations of Carrot
+- Help out with the FCMP++ integration wherever I can
+
+## Who
+
+I have been contributing to the Monero core repository for [over two years](https://github.com/monero-project/monero/pulls?page=2&q=is%3Apr+author%3Ajeffro256) with a total of [84 merged commits to master](https://github.com/monero-project/monero/commits?author=jeffro256) thus far, with many open PRs. Over the last few months, I wrote up the [Carrot specification](https://github.com/jeffro256/carrot/blob/master/carrot.md), organized []auditing](https://github.com/cypherstack/carrot-audit), for which the  community graciously funded, and [began](https://github.com/monero-project/monero/pull/9559) [implementing](https://github.com/monero-project/monero/pull/9697) it. Carrot will be the main supported addressing protocol post-FCMP++ if all goes according to plan. I also worked on the Seraphis migration project in 2023/2024.
+
+Previous Proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/390
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/421
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/436
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/467
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/504
+
+## Payment
+
+I propose to work for 3 months at a rate of 38 XMR per month.
+

jeffro256-part-time-2022-q3.md

+---
+layout: cp
+title: "jeffro256: part-time dev work 2022Q3"
+author: jeffro256
+date: 17 May 2022
+amount: 60
+milestones:
+  - name: Month 1
+    funds: 33% (20 XMR)
+    done: 23 September 2022
+    status: finished
+  - name: Month 2
+    funds: 33% (20 XMR)
+    done: 19 November 2022
+    status: finished
+  - name: Month 3
+    funds: 34% (20 XMR)
+    done: 4 April 2023
+    status: finished
+payouts:
+  - date: 24 October 2022
+    amount: 20
+  - date: 29 December 2022
+    amount: 20
+  - date: 11 May 2023
+    amount: 20
+---
+
+
+## What
+
+I propose to spend 20 hours a week for 3 months working on Monero Core and the Monero GUI. Here are some areas, in tentative order of descending importance/specificity, that I'd work on:
+
+1. Work with @selsta to protect GUI users in "simple mode" by implementing a trusted community node system
+2. Create a RPC SSL connection integrity indicator for the CLI and GUI wallets
+3. Allow GUI users more fine-grained control of their SSL connections
+4. Create a more thorough UI for warning users of GUI mode of high fees
+5. Draft a formal Levin/Cryptonote protocol specification
+6. Revamp Doxygen documentation
+7. Do other general documentation of the codebase
+8. Transition legacy OpenSSL code to comply with OpenSSL 3.0 (already started)
+9. Explore using faster & smaller EC OpenSSL certificates in place of traditional RSA certificates
+10. Continue to remove dead code, and simplify codebase, especially the (epee module)[https://github.com/monero-project/monero/pull/8211]
+12. Misc developing / reviews
+
+## Who
+
+My name is Jeffrey; I am currently working on completing a computer science major with a minor in both cybersecurity and mathematics. I have always been fascinated with cryptography and digital privacy, so learning about Monero during the altcoin boom of 2017 was eye-opening and exciting. Soon enough, supporting Monero became a no-brainer for someone who is passionate about digital privacy.
+
+I got my first PR merged on March 18th, and you can see the rest of them here: <https://github.com/monero-project/monero/pulls?q=is%3Apr+is%3Amerged+author%3Ajeffro256>. So far I have been doing it as a hobby, but I would love to spend more time on this project than I currently am, as I am rather busy with schoolwork and my job. As this is my first CCS proposal, I am very open to criticism and questions, so don't be afraid to ask! I will do my best to respond in the comments below.
+
+## Why
+
+### Trusted community node system and high fees (1 & 4)
+
+As can be seen in [this issue](https://github.com/monero-project/monero/issues/8298), among others, there appear to be malicious node(s) which advertise themselves as public nodes, allow users using the GUI wallet in "simple node" to connect, and respond with insanely high fees. This issue runs even deeper, and this exploit can be used to deanonymize GUI users to a certain degree in simple mode when they send transactions. There's no replacement for running your own node (and double-checking your fee amounts), but for those who choose not to, they should be able to expect at a minimum to not have their funds stolen from them.
+
+### RPC connection integrity indicator and fine-grained SSL control (2 & 3)
+
+Getting SSL right is difficult and nuanced. You can verify with system certificates, user-supplied certificates, accept any connection as long as it is secured, or any combination of these options. You can have certificates which sign other certificates. As it stands, the way the GUI wallet secures connections is not ideal. It more or less accepts any connection, using SSL if its available, but for no specific ccertificate, and there is not a way to specify how to connect with SSL (unlike in the CLI wallet). I want to afford the users two things: the ability to quickly asses the quality of their connections to their nodes via an elegant UI element, and the ability to tweak their SSL settings if so desired.
+
+### Levin/Cryptonote Specification (5)
+
+Unclear protocols cause bugs and choke out emerging projects which wish to incorporate into the ecosystem. Here are a couple recent PRs to fix bugs with the p2p/relay code:
+
+* <https://github.com/monero-project/monero/pull/8330>
+* <https://github.com/monero-project/monero/pull/8326>
+* <https://github.com/monero-project/monero/pull/8324>
+
+While it would be quite a feat to document ALL of the cryptonote protocol, it could be helpful to more thoroughly document the Levin protocol commands and the expectations surrounding the calls (interface, relay rules, ban criteria, etc). The p2p protocol of Monero is useful not only for nodes, but also for wallets and light wallet servers, especially when using untrusted connections. This was already started in [this document](https://github.com/monero-project/monero/blob/master/docs/LEVIN_PROTOCOL.md), but could certainly be fleshed out.
+
+### OpenSSL 3.0 Compatibility (8)
+
+It's always a nice thing to have your code compile on all your targets. In newer versions of OpenSSL, they have deprecated a large portion of the API, much of which we rely on to secure connections in Monero, particularly RPC.
+
+### EC OpenSSL certificates (9)
+
+Currently, we use RSA certificates for RPC SSL, but EC certificates are smaller and thus faster. This could offer speed improvements while syncing, etc. @HYC suggested the idea while I was working on moving certain parts of the codebase to OpenSSL 3.0: <https://github.com/monero-project/monero/pull/8335>.
+
+### Nice-to-haves (6, 7, 10, 11)
+
+All of these points do not directly affect the end-user experience but will ultimately improve the developer experience, reducing friction in the future, contributing to the long-term health of the codebase.
+
+## Funding
+* Wage: 30 USD/hr
+* Hours: 12 weeks x 20 hours/week = 240 hours
+* Total pay in USD: 240 hours x 30 USD/hr = $7200 USD
+* Exchange rate: $116.41 USD/XMR. Calculated from one week simple average of closing prices on coinmarketcap.com
+  * 24 June: $126.47
+  * 23 June: $122.70
+  * 22 June: $111.18
+  * 21 June: $118.80
+  * 20 June: $117.30
+  * 19 June: $114.22
+  * 18 June: $104.18
+* Total pay in XMR: $7200 USD / $116.41 USD/XMR = 61.85 XMR
+
+Expiration Date
+1 August, 2022
+

john-foss-the-monero-moon.md

+---
+layout: cp
+title: Funding for The Monero Moon Newsletter
+author: John Foss
+date: April 22, 2021
+amount: 18
+milestones:
+  - name: Publish issues #16 through #21
+    funds: 6 XMR
+    done: 29 June 2021
+    status: finished
+  - name: Publish issues #22 through #27
+    funds: 6 XMR
+    done: 13 January 2022
+    status: finished
+  - name: Publish issues #28 through #33
+    funds: 6 XMR
+    done: 31 March 2022
+    status: finished
+payouts:
+  - date: 28 January 2022
+    amount: 12
+  - date: 4 April 2022
+    amount: 6
+---
+
+WHAT: The Monero Moon is a weekly newsletter regarding all things Monero. It was created in response to fill the vacuum after I previously had to stop due to personal reasons in late 2018. The Monero Moon is a free weekly news publication, and has been created in an effort to keep the Monero community up to date on all the latest news and developments related to Monero. I aim to achieve this by aggregating all the relevant information into one convenient location in an easy-to-digest format. I sift through the noise so you don’t have to. I also endeavour to cross promote other Monero initiatives as much as possible, while also encouraging others to participate in or support the Monero project.
+
+The Monero Moon is independently published by myself on Medium. I have already published three issues (issues 12-14) over the past few weeks. View previous issues 1-14 here.
+
+Weekly readership have been varied so far, and it has appeared that readership increases the more social media promotion gains traction.
+
+Issues from 2018 regularly had on avg 1500 views, however so far this year the newsletter has been receiving on avg 800 views.
+
+A problem I am coming across is how much time is required to operate the weekly newsletter. Family, life, work etc all get in the way and as much as I love Monero it is hard to justify the extra time spent on the Monero Moon.
+
+WHO: I am John Foss. Like many of you, I am a firm believer and supporter of the Monero Project. I have previously written Monero articles on Medium, a couple of How To Buy Monero Guides for the Monero.How website, and wrote Your Guide to Monero, and Why It Has Great Potential back in 2018 which I posted to r/cryptocurrency and had over 25k views and received 1.5k upvotes. Besides that, I have been following Monero for a fair while now, generally hanging out on r/xmrtrader and Twitter, and I also occasionally venture over to the IRC channels.
+
+WHY: As Monero continues its journey, I believe it is extremely important for everyone (community members and outsiders looking in) to be able to closely follow along with all the latest news and developments surrounding Monero, whether it's the latest community update from the developers, or if Monero was featured in a large media publication. And I believe The Monero Moon will help bridge that gap. I believe that the Monero Moon will be extremely beneficial for the growth and adoption of Monero as the newsletter will continue to help spread awareness.
+
+THE PROPOSAL AND MILESTONES: As Monero grows in popularity, it takes more and more time to put together an issue from start to finish. It currently takes me about 10 hours of work per issue. This involves me researching and collating the information, writing it up, then publishing and promoting it via social media platforms.
+
+I am proposing to publish The Monero Moon for 1 XMR per issue from the end of April until the end of August 2021. At the current exchange rate of approximately $375USD per XMR, that comes out to ~$375 per issue which I believe is fair compensation. For example, 1000 readers is equivalent 0.37c per read.
+
+The milestones are also straightforward, for every 6 issues I publish, payment is released. This comes out to 3 milestones in total.
+
+Milestone 1: Publish issues #16 through #21 - 6 XMR
+Milestone 2: Publish issues #22 through #27 - 6 XMR
+Milestone 3: Publish issues #28 through #33 - 6 XMR
+
+There may be periods where I miss a week due to life commitments, however I will endeavour to cover all the recent news in one big bumper newsletter issues, and this will still just count as one issue. The newsletter issues will carry on from previous publications.
+Additionally, at the end of this period of 18 issues published I will re-evaluate whether I shall continue the newsletter.
+
+Cheers,
+John Foss

kayabaNerve-fcmp-retroactive.md

+---
+layout: cp
+title: Retroactive funding for work on full-chain membership proofs
+author: Luke Parker (kayabaNerve)
+date: July 24, 2023
+amount: 310 XMR
+milestones:
+  - name: Implementation of Bulletproofs+
+    funds: 150 XMR
+    done: 23 June 2023
+    status: finished
+  - name: Implementation of Curve Trees
+    funds: 100 XMR
+    done: 23 June 2023
+    status: finished
+  - name: Application of elliptic curve divisors for multiple times faster proofs
+    funds: 50 XMR
+    done: 23 June 2023
+    status: finished
+  - name: Implementation of COPZ's efficient cross-group discrete log equality proof
+    funds: 10 XMR
+    done: 23 June 2023
+    status: finished
+payouts:
+  - date: 21 March 2024
+    amount: 310
+---
+
+Prior to Monerokon, I spent a month and a half working on full chain membership proofs for Monero. This is the product of
+
+- Discussions from https://github.com/monero-project/research-lab/issues/100
+- Curve trees, as the fundamental idea https://eprint.iacr.org/2022/756
+- Eagen's application of Elliptic Curve divisors https://eprint.iacr.org/2022/596
+- COPZ's discrete log equality proof, letting us move to a curve cycle https://eprint.iacr.org/2022/1593
+
+Having finished the work, which was considerable, I would like to fundraise for retroactive funding given the expenses occurred to me. Not only did I put off my own work for the significant amount of time spent on this, I made the decision to bring j-berman in at a rate we had prior established for their work on my own project.
+
+To explain the work, it's an implementation of a membership proof _compatible with Seraphis_ which is efficient enough to feasibly support up to 777 million outputs. For more than 777 million outputs, proof time would increase ~50%, yet the chain would continue.
+
+While this work isn't complete, it has asserted its existence as a viable path to proceed down.
+
+# What Has Been Done
+
+- An implementation of Bulletproofs+, designed to be clearly understandable and efficient.
+
+A new implementation was written despite Monero already having a deployed implementation. This was due to Monero's implementation only supporting aggregate range proofs and being so tailored for them, it being infeasible to expand to include support for arithmetic circuits (the proof Curve Trees uses).
+
+It is not yet ready for production for a few reasons.
+
+1) It panics on invalid inputs, instead of returning errors.
+2) It hasn't been externally reviewed/audited.
+3) A design criteria to support curve trees is a vector commitment scheme (VCS). Bulletproofs+ does not support vector commitments, and I had to shim in my own scheme to compensate which is not viable for production.
+
+This will be discussed below.
+
+- An implementation of Curve Trees, or at least, the idea of Curve Trees.
+
+Curve Trees describes a n-ary Merkle Tree where the hash function is a Pedersen hash. Since a Pedersen hash hashes from scalars to a group element, and the variables in an arithmetic circuit are scalars, Curve Trees uses a pair of Bulletproofs over a curve cycle, each layer of the tree represented by the complimentary proof. This ensures the output of the hash is always a native variable. My implementation is similar, yet instead of using the scalar multiplication algorithm provided in its paper, Eagen's application of Elliptic Curve divisors is used. This is multiple times more performant.
+
+Additionally, my work was done over Bulletproofs+, not Bulletproofs, for minor efficiency gains. Post-deciding which arithmetic circuit proof to use, it was learned Curve Trees requires a VCS. Bulletproofs+ does not have a VCS posited, while Bulletproofs has one posited yet not proven. While work could be done to prove the VCS posited for BPs instead of developing a new scheme for BPs+, this would be detrimental in the long term.
+
+To explain why, BPs defines a "inner-product" argument. BPs+, "weighted inner-product". BPs++, "norm". BPs++ argues its "norm" argument can be equivalent to BPs+'s "weighted inner-product", implying future development of a VCS around BPs++ would be best done from a VCS around BPs+. Since it is a goal to move to BPs++ for efficiency, not just for arithmetic circuits (this work) yet also Monero's range proofs (which BPs++ already has funding to be reviewed for), this was kept in mind.
+
+As part of my work, I reached out to Firo, with researcher Aram Jivanyan and contracting researcher Aaron Feickert (sarangnoether) from Cypher Stack. I requested their collaboration in this effort, with current discussions being around them working on developing and proving a VCS. While no guarantees have been made, the answer to if a scheme for BPs+'s WIP argument is possible was estimated to be on the scale of weeks, not months. Accordingly, I'd personally evaluate it within timelines _and long-term fruitful_ to continue with BPs+ and not revert to BPs. If a BPs+ VCS is infeasible, then the work falls back to proving the VCS posited for BPs, which has passed first glances.
+
+- An implementation of Elliptic Curve divisor calculation and checks
+
+Elliptic curve divisors can be used to offer proof-of-knowledge of discrete logarithms which are several times more efficient than in-circuit elliptic curve additions. I implemented the calculation of divisors, checks for them (in and out of circuit), achieving a roughly 3x reduction in DLog PoK circuit size than the Curve Trees DLog PoK circuit. This circuit is most of the overall circuit, and circuit size does directly relate to proof verification time.
+
+- An implementation of COPZ's discrete logarithm equality proof
+
+Since Curve Trees effectively requires a curve cycle, Monero would have to move to one. This proof lets Monero move to a curve cycle at a marginal cost (a one-time 160-byte proof per-output).
+
+# What's Next
+
+A series of tasks can be defined.
+
+1) Proving and implementing a proper VCS scheme
+
+This is currently in progress, and doesn't actively require the Monero project. In the future, it may require our involvement, and if so, we can discuss it then.
+
+2) Proving/formally verifying Curve Trees
+
+I agree more certainty behind Curve Trees is needed. I do not believe we should halt development efforts until we are fully certain, given the amount of evidence before us and alternative paths ahead of us for any road blocks we may face. Already happening is the development of a VCS scheme, with proofs. Once that happens, letting us formally define our Curve Trees instantiation, we can continue obtaining certainty. All of this can be done in parallel to this work's completion.
+
+3) Polishing the above work
+
+This will be tackled by future CCSs. I am planning one, and j-berman has already submitted a CCS which part of is experimentally integrating Curve Trees into Monero (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/401). I have also discussed with multiple developers in the ecosystem getting their involvement.
+
+To be perfectly clear, in no uncertain terms, this CCS does not provide funding for nor guarantee any continued development. It is solely a representation of gratitude and acknowledgement for work already performed, and organization provided.
+
+4) Auditing
+
+Auditing can only occur once the academia, and the code, is completed.
+
+5) The Monero project deciding whether or not to move to a curve cycle
+
+I cannot truly comment here as I do not speak for the Monero community.
+
+My personal thoughts on moving to a curve cycle can be found here: https://gist.github.com/kayabaNerve/97441ad851dc6e4d2a0b699f58a004f2
+
+Relevant MRL issues are https://github.com/monero-project/research-lab/issues/100 and https://github.com/monero-project/research-lab/issues/110.
+
+While this isn't the place to decide if a curve cycle is necessary, or if one will be adopted, it is important to note a curve cycle isn't technically required. It's optimal, and somewhat expected, yet we can hash Ed25519 points into a cycle (at additional cost). Accordingly, this work is relevant even if we don't move to a curve cycle.
+
+6) The Monero project deciding whether or not to integrate this work
+
+In order for the community to decide if this work should be integrated, it must be evaluated. Evaluation requires this work being viable for integration, which won't happen until it's complete. For now, I restate
+
+> While this work isn't complete, it has asserted its existence as a viable path to proceed down.
+
+And accordingly justify not only its historical funding, yet future funding.
+
+# Why Historical Funding
+
+The CCS has a distaste for historical/retroactive funding, which I understand. Personally, I do not accept payment for a job until it is done. While the milestone system offers that, I still must promise and obligate myself to doing the work by the fact I created a CCS and succesfully raised funds. I do not appreciate those obligations when I was unsure of my capabilities to produce not just a membership proof, yet a membership proof viable to continue with which was worth fundraising for. Before I wrote an implementation of BPs+, designed a higher-level arithmetic circuit framework, learned enough math to implement Elliptic Curve divisors, engaged with multiple other parties, and implemented Curve Trees, I was unsure this would become meaningful to Monero. It was on a scale I had never worked with before, and far too much work to ever be certain about before it is done and actual metrics can be assigned. Accordingly, I would never have felt comfortable with funding beforehand.
+
+I also wished to avoid debate about the legitimacy of atttempting this work. This work, as currently implemented, with its current performance, commentary, and understandings, establishes itself as viable. Before it existed, it could not establish itself as viable. By waiting, I removed discussions about if it would be viable by now providing a proof it is.
+
+While this work was done with limited visibility, I did contact parties as soon as they became relevant. Prior mentioned was a collaboration with Firo, yet I also reached out to Liam Eagen (author of BPs++ and a proof applying Elliptic Curve divisors), narodnik, and j-berman as beneficial.
+
+# Funds Breakdown
+
+The amount quoted is roughly 50,000 USD. Given the amount of work produced, and time spent, I believe this to be fair.
+
+This is inclusive of my obligation to j-berman ($3,600) who:
+
+- Reduced the multiplications performed, savings tens of percent off verification time
+- Investigated a new algorithm for further reducing multiplicatios, which would also be applicable to Monero's current BP+ implementation
+
+And my desire to thank Eagen for their contributions with $5,000. Eagen's application of divisors drastically increased the performance of this work. Also notable is narodnik who provided an initial Python reference for divisor construction and evaluation, yet they have declined to be so thanked.
+
+With all of this in mind, and given the extended hours I generally work, my hourly rate would be roughly 100 USD.
+
+# Resolution
+
+If this proposal is not funded within two months, it will be closed regardless of status. All raised funds will be directed towards the already completed milestones, even if only partially funded. Whatever amount raised will close this CCS, and be considered as complete funding for these milestones.