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: wip
+layout: cp
 title: Funding for The Monero Moon Newsletter
 author: John Foss
 date: April 22, 2021
@@ -7,23 +7,21 @@ amount: 18
 milestones:
   - name: Publish issues #16 through #21
     funds: 6 XMR
-    done:
-    status: unfinished
+    done: 29 June 2021
+    status: finished
   - name: Publish issues #22 through #27
     funds: 6 XMR
-    done:
-    status: unfinished
+    done: 13 January 2022
+    status: finished
   - name: Publish issues #28 through #33
     funds: 6 XMR
-    done:
-    status: unfinished
+    done: 31 March 2022
+    status: finished
 payouts:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
+  - 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.

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.

m0n3r0d1c3-monero-dice-site-deployment.md

+---
+layout: cp
+title: Deploy and maintain Monero Casino.
+author: M0n3r0d1c3
+date: April 4, 2022
+amount: 1
+milestones:
+  - name: Deployment
+    funds: 100% (1 XMR)
+    done: 5 May 2022
+    status: finished
+payouts:
+  - date: 5 May 2022
+    amount: 1
+---
+
+Hello! I'm M0n3r0D1c3, and I've created casino for Monero.
+Yup already created, the code is written and it works pretty well. Hence - it was even deployed once but died because of lack of proper marketing and funding.
+
+Here are some screenshots:
+ - https://ibb.co/bPcpS4t
+ - https://ibb.co/Gd2ygDG
+ - https://ibb.co/7R9WvvZ
+
+Here is an overview of features
+ - Provably fair bets, casino can't fake the bet result.
+ - No minimum bet, withdrawal and deposit amounts.
+ - Community funded bankroll - If you don't feel like playing in casino you can always pick the other side. Be a investor and take adventage of the 1% house edge!
+ - On-site chat bridged with telegram chatroom and tip command.
+ - Referral system.
+ - Deposits can be made using any of the currencies supported by majesticbank and will be exchanged onto xmr and deposited to the site.
+ - Monero as accepted currency and Bitcoin as a tolerated currency (with an option to add other currencies, if community wants that).
+
+Now here come few elephants in the room:
+ - The casino was already started once - https://bitcointalk.org/index.php?topic=5383564 - but failed due to, lack of investments, lack of marketing, time and funds to promote the site.
+ - I'm having extremely bad time with predicting monero transaction fee using the rpc wallet, so the fee amount is constant and the difference is being cashed back to the account (even if negative). But that's being worked on already.
+
+That being said, I'm opening this CCS to get funding mainly for hosting the service, buying the domain ~~(and getting some more attention by the community)~~.
+
+All I'm asking for is money for the VPS with following specs that will run a hidden service, xmr (full) and btc (pruned) node.
+
+ - 2GB Memory 
+ - 512 GB (mixed hdd and ssd)
+ - Unmetered Bandwidth
+
+For 10$/m.o. for one year, resulting in a 120.00$ yearly price
+
+And another VPS, bought at another vendor that will be responsible for serving clearnet frontend (it will act as a proxy for the hidden service on clearnet.)
+
+It's specs are similar, except for storage - only around 25GB. The offer that I found cost 6$/m.o. (72$/year) and will do the job.
+
+Why two servers? Because one server will be easy to find in case the site will get reported. And at worst case scenario they will take down the clearnet service, but the hidden service will remain up and working - that will allow me to buy another server to serve clients (or at worst case scenario - allow people to withdraw their funds using hidden service).
+
+Last expense is the domain. I think that domain name should be discussed as a part of this prospal. Njal.la will be a good choice for a provider, and their pricing is at 15eur - 70eur, but I think that the most interesting domain names are at 30eur - so domain name will cost us around 35$.
+
+To sum everything up:
+ - vps server 1: 120.00$
+ - vps server 2: 72.00$
+ - Domain: 35.00$
+ - Total: 227$
+
+According to `Market Rates: Apr 4, 2022 at 12:53 PM UTC` fetched from CoinMarketCap 227 USD is equal to `1.07187734` XMR (~1.08 XMR)
+
+If you wish to discuss some things with me directly, please contact me using telegram - [@M0n3r0D1c3](https://t.me/M0n3r0D1c3). Or comment on this proposal, I'll be happy to explain everything.
+
+P.S. After funding this proposal I'll be able to deploy the site within few days - including monero node sync time (bitcoin sync however will take somewhat longer amount of time). But the site will need investors that will provide bankroll, to become a investor all you need to do is deposit money on site and create a new investment on the bottom of it. I won't be able to provide any bankroll because my personal monero holding are relatively small (I wouldn't ask for 1XMR otherwise).

maintaining-flatpak-package.md

+---
+layout: wip
+title: Maintaining Flatpak package
+author: BigmenPixel
+date: March 21, 2023
+amount: 10.02
+milestones:
+  - name: manifest to core repo
+    funds: 3.5
+    done:
+    status: unfinished
+  - name: 3 month maintenance
+    funds: 1.63
+    done: 2 April 2024
+    status: finished
+  - name: 3 month maintenance
+    funds: 1.63
+    done: 2 April 2024
+    status: finished
+  - name: 3 month maintenance
+    funds: 1.63
+    done: 2 April 2024
+    status: finished
+  - name: 3 month maintenance
+    funds: 1.63
+    done: 2 April 2024
+    status: finished
+payouts:
+  - date: 9 April 2024
+    amount:  6.52
+  - date:
+    amount: 
+  - date:
+    amount: 
+  - date:
+    amount: 
+  - date:
+    amount: 
+---
+
+## **Maintaining flatpak package `org.getmonero.Monero`**
+
+## Summary
+
+I have been maintaining `org.getmonero.Monero` on Flathub since July 2021. Now I want to move its manifest to the [monero-gui](https://github.com/monero-project/monero-gui) repository. The org.getmonero.Monero github repo which is now used to push files to flathub will be discontinued. The files will be built and pushed directly from the monero-gui repository. Users will then be able to compare the hashes of files on their machines to those from the monero-gui workflow run. We can then give Monero-gui flatpak app a "verified" checkmark. This is an optional step for the community to decide at a later date. Flatpak installs will still remain 3rd-party and users are encouraged to confirm hashes, as they are with any other package repository.
+
+Thanks to this, users will be able to trust this flatpak package more.
+
+## Installing and using
+
+The `org.getmonero.Monero` flatpak package is a good replacement for ordinary packages in GNU/Linux distributions, for example it can be used in Whonix to [replace](https://forums.whonix.org/t/how-to-verify-the-monero-binaries-that-are-shipped-with-whonix/16439/10) the Debian package. 
+
+At first you have to [setup flatpak](https://flatpak.org/setup) with Flathub repository on your GNU/Linux distribution. After that, run this command:
+```
+$ flatpak install flathub org.getmonero.Monero
+```
+
+By default, `org.getmonero.Monero` has access only to the `~/Monero` directory, if you need more, do it:
+```
+$ flatpak --user override --filesystem=/path_to_your_directory org.getmonero.Monero
+```
+
+Some people need access to the `monerod` command:
+```
+$ flatpak run --command=monerod org.getmonero.Monero [options|settings] [daemon_command...]
+```
+
+## About me
+
+I am [BigmenPixel](https://github.com/BigmenPixel0), who maintains Monero GUI on Flathub and some packages in the [AUR](https://aur.archlinux.org/account/BigmenPixel).
+
+### Milestone 1 (3.5XMR)
+
+Move the manifest to the [monero-gui](https://github.com/monero-project/monero-gui) repository.
+
+### Milestone 2 (6.5XMR)
+
+1 year of maintenance to be paid quarterly @1.63XMR after performance review (updates are ready in a timely manner / critical issues solved).
+
+These rates are based off of the previous [debian package maintenance](https://ccs.getmonero.org/proposals/adrelanos-debian-package.html) proposal.

mature-atomic-swaps-ecosystem.md

+---
+layout: wip
+title: "From Prototype to Marketplace: Maturing the XMR-BTC Atomic Swaps Ecosystem"
+author: "binarybaron and einliterflasche"
+date: July 9, 2024
+amount: 729
+milestones:
+  - name: 1st month
+    funds: 121.5
+    status: finished
+    done: 15 October 2024
+  - name: 2nd month
+    funds: 121.5
+    status: finished
+    done: 26 November 2024
+  - name: 3rd month
+    funds: 121.5
+    status: finished
+    done: 21 January 2025
+  - name: 4th month
+    funds: 121.5
+    status: unfinished
+    done:
+  - name: 5th month
+    funds: 121.5
+    status: unfinished
+    done:
+  - name: 6th month
+    funds: 121.5
+    status: unfinished
+    done:
+payouts:
+  - date: 19 October 2024
+    amount: 121.5
+  - date: 6 December 2024
+    amount: 121.5
+  - date: 3 February 2025
+    amount: 121.5
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+![https://i.ibb.co/3NvpYp2/upload-398781d371d354427bb455356731258c.png](https://i.ibb.co/3NvpYp2/upload-398781d371d354427bb455356731258c.png)
+![https://i.ibb.co/wgYK9FF/generated-gif-2.gif](https://i.ibb.co/wgYK9FF/generated-gif-2.gif)
+
+### Who
+
+We (binarybaron and einliterflasche) are two Monero enthusiasts from Berlin and both computer science students. We have been excited about XMR<>BTC atomic swaps since the COMIT team started development of their prototype. binarybaron has contributed to the project since its early stages while einliterflasche joined later on.
+
+### What is this project anyway?
+
+The project mostly consists of four parts:
+
+1. A command-line utility ([ASB](https://github.com/comit-network/xmr-btc-swap/blob/master/docs/asb/README.md)) that enables individuals to operate a 'swap provider' service. These swap providers offer to sell Monero in exchange for Bitcoin.
+2. A command-line interface ([CLI](https://github.com/comit-network/xmr-btc-swap/blob/master/docs/cli/README.md)) that allows users to connect with swap providers and exchange their Bitcoin for Monero.
+3. A graphical user interface ([GUI](https://github.com/UnstoppableSwap/unstoppableswap-gui/)) that utilizes the CLI behind the scenes, making the swap process way more user-friendly.
+4. A command-line utility for hosting a [rendezvous point](https://github.com/comit-network/rendezvous-server) in the decentralized discovery network. Swap providers can register at these nodes to make themselves known to the network. CLI users can retrieve a list of swap providers.
+
+### What we have been working on over the last 2 years:
+
+- Developed an early web interface to simplify XMR<>BTC swaps. This project has since been deprecated and replaced with a desktop GUI. 
+- Stepped in as maintainers for the [xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap) project which includes the ASB and CLI applications. We have become the main developers fixing issues, implementing new features and pushing out releases.
+- Developed the [GUI](https://github.com/UnstoppableSwap/unstoppableswap-gui/). Last year alone, more than 3,000 swaps were completed using our GUI. Since we completed our second CCS from May 2022, we worked on the project during our free time. This is also the reason we weren't able to dedicate as much time to the project as we'd like to and, frankly, as it deserves.
+- Running a mainnet swap provider to kickstart adoption that has performed over a thousand swaps with users. This has been put on pause for now as more swap providers have emerged.
+- We have also been hosting, and developing publicely accessible infrastructure
+    - An API service that gathers a list of all known swap providers. This can be used in the GUI and also by others in the community (e.g [OrangeFren](https://orangefren.com/)) in addition to rendezvous points.
+    - A reliable rendezvous point
+- As part of our efforts to make atomic swaps accessible to the general public we have have been writing [documentation](https://docs.unstoppableswap.net/) for atomic swaps in general as well for the GUI and CLI applications.
+
+### Proposal:
+
+We're excited to keep working on atomic swaps. While swaps work realiably under optimal conditions, there are still many imperfections. We are confident that given a few months time to fully dedicate to the project, we can transform the ecosystem from more of a proof of concept into a mature marketplace.
+
+We are asking the community for funding in order to be able to focus our efforts on improving the atomic swaps ecosystem.
+
+We request 729 XMR for continued development for 6 months. At the end of each month 121.5 XMR will be paid out. We will dedicate 35 hours of focused work per week per person. Our hourly rate is 60 EUR. We're calcuating these amounts at a current average price of 138 EUR/XMR.
+
+We will be providing monthly detailed updates in the comment section.
+
+### What we will be working on
+
+We will continue to maintain both the GUI and the underlying CLI/ASB by:
+- Planning, coordinating and implementing new features and bug fixes,
+- Coordinating releases,
+- Keeping in touch with users and the community as a whole as well as offering a built-in feedback system in the GUI.
+
+Furthermore, we will continue to manage some community infrastructure:
+- We host a [webpage](https://unstoppableswap.net/) for the GUI as well as [documentation](https://docs.unstoppableswap.net/).
+- We maintain both a public registry of swap providers as well as a reliable node in the decentralized discovery network.
+
+For the CLI and ASB, which form the backbone of the GUI and swap provider infrastructure respectively, our focus will be to improve overall reliability. While swaps work consistently under optimal conditions, there are many moving parts, leading to various challenges in practice. These challenges include:
+- Reliably staying in sync with both the Bitcoin and Monero blockchains,
+- Completing swaps amid connectivity issues,
+- Discovering peers in the network,
+- Maintaining backwards compatability between peers (network protocols),
+- Handling concurrent swaps,
+- Accounting for blockchain congestion,
+- Stringently enforcing protocol compliance,
+- Ensure fail safety when swaps can't be completed,
+- Minimizing the manual intervention required (e.g having to manually refund in some edge cases),
+- ...
+
+For the ASB daemon specifically, our focus will be on enhancing its ability to handle large amounts of liquidity reliably. We will also make it easier for a wider range of individuals to become a swap provider and sell their Bitcoin for Monero. This will improve competition and in turn lead to lower markup rates. Our work will include:
+- Developing user-friendly tooling to simplify the setup and operation of the ASB and its accompanying services.
+- Improving ASB extensibility and automatability by implementing an JSON-RPC server:
+   - Swap providers can connect to their ASB using a standardized OpenRPC protocol
+   - This will enable providers to:
+     - Dynamically adjust their exchange rate based on current conditions and market assessment
+     - Flexibly set maximum and minimum swap amounts according to their risk tolerance
+     - Automate access to internal Bitcoin and Monero wallets for fund management
+     - Listen for all kinds of events
+- Enabling anyone to automate their ASB service to their liking by developing easy-to-use connector libraries for popular programming languages (e.g. Python, TypeScript, Rust, Java).
+
+Integrating the RPC server and developing client libraries will take a lot of work and large refactors, but it will be worth the effort. It will enable the creation of custom applications and scripts built on top of the ASB. This will open basically unlimited possibilities but the most obvious use cases include:
+   - Complete access to statistics and internal data and logging
+   - Adjust exchange rate and minimum swap amount based on current Bitcoin transaction fees
+   - Listening for specific events and executing custom actions e.g. sending notifications or replenishing funds by executing trades on other platforms
+   - Integration of Bitcoin privacy protocols (e.g., CoinJoin, Whirlpool) for received funds
+
+For the GUI itself our focus will be to:
+- Make the GUI more accessible to non technical users (e.g. tooltips, explanations, ...),
+- Provide documentation for end users as well as technical documentation to improve transparency and attract new developers,
+- Work on migrating the GUI framework (from Electron to Tauri) to simplify the architechture,
+- Release an Android (and possibly iOS) version of the GUI.
+- _(We are also looking into a web version, powered by WebAssembly, which can run in browsers. This may not be possible and will require extensive refactors in the code base.)_
+- Build a new UI for hosting and managing the ASB from inside the GUI. Thereby enabling selling Monero for Bitcoin.
+
+### Why
+
+We want to enable anyone to reliably acquire Monero by building an anonymized, decentralized and trustless market that is resiliant to censorship. We believe that by realizing the potential of this project we can bring this to reality.
+
+A mature ecosystem will attract more users and swap providers. This will lead to increased liquidity and competition and thus make atomic swaps a viable alternative to centralized exchanges.

michaelizer-translations-into-spanish.md

 ---
-layout: wip
+layout: cp
 title:  "Spanish translation and proofreading of the monero site, GUI/CLI wallets and User Guides"
 author: michaelizer
 date: May 28, 2021
@@ -7,23 +7,19 @@ amount: 12
 milestones:
   - name: Milestone 1 - Translation and proofreading of the Monero site
     funds: 33.33% (4 XMR)
-    done:
-    status: unfinished
+    done: 15 July 2022
+    status: finished
   - name: Milestone 2 - Translation and proofreading of the GUI and CLI wallets
     funds: 41.67% (5 XMR)
-    done:
-    status: unfinished
+    done: 15 July 2022
+    status: finished
   - name: Milestone 3 - Translation and proofreading of the user guides
     funds: 25% (3 XMR)
-    done:
-    status: unfinished
+    done: 15 July 2022
+    status: finished
 payouts:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
+  - date: 23 July 2022
+    amount: 12
 ---
 
 ## What the proposal is about? 

midipoet-Oslo_Freedom_Forum_CCS_proposal.md

+---
+layout: cp
+title: midipoet-Oslo_Freedom_Forum_CCS_proposal.md
+author: midipoet
+date: April 6, 2022
+amount: 8.5 XMR
+milestones:
+  - name: Proposal funded
+    funds: 4.25 XMR
+    done: 25 April 2022
+    status: finished
+  - name: Report submitted
+    funds: 4.25 XMR (2.25 to midipoet, 2 to GF)
+    done: 24 September 2022
+    status: finished
+payouts:
+  - date: 25 April 2022
+    amount: 4.25
+  - date: 28 September 2022
+    amount: 2.25
+  - date: 20 September 2022
+    amount: 2
+---
+
+
+**WHO**
+
+I am known in the community as midipoet. I have been an active contributor for quite a number of years now, and would like to think that I have earned a level of trust from the community at large.
+
+I have been involved in the [Monero Policy Working Group](moneropolicy.org) since its inception, contributing directly to all the [policy consultations](https://github.com/monero-policy/monero-policy.github.io/tree/master/assets/pdfs) we have done over the last year or so.  - more info [here](https://www.reddit.com/r/Monero/comments/r5vodq/mpwg_final_two_responses_to_the_public/), [here](https://www.reddit.com/r/Monero/comments/qowwm4/monero_policy_working_group_response_to_the/), [here](https://www.reddit.com/r/Monero/comments/mxr15w/monero_policy_working_group_response_to_fatf/), and [here](https://www.reddit.com/r/Monero/comments/m1es4t/monero_policy_working_group_response_to_european/).
+
+I have also conducted research on Monero, working to produce a respected journal paper for a three star academic journal. More info [here](https://www.reddit.com/r/Monero/comments/ijhas9/monero_research_those_who_control_the_code/). 
+
+I am also part of the organising team for [MoneroKon 2022](https://www.reddit.com/r/Monero/comments/tjyrut/ccs_update_monerokon_2022_location_and_venue/), being involved from the start for all the heavy lifting. 
+
+Over the years, I have given a number of talks on Monero, funded by the community (thank you!). More info [here](https://www.reddit.com/r/Monero/comments/9yh9zi/cryptofinance_oslo_2018_report_by_midipoet/) and [here](https://www.youtube.com/watch?v=6JIz_H8irAQ)
+
+In 2019, I attended the Oslo Freedom Forum on a ‘reconnaissance’ mission, to give a talk, and also to hold a fringe event. More info [here](https://www.reddit.com/r/Monero/comments/bvoarg/oslo_freedom_forum_fringe_review_midipoet/). 
+
+**WHAT**
+
+Now that we are back to in person event, I would like to attend the [2022 Oslo Freedom Forum](https://hrf.org/category/oslo-freedom-forum/) - May 23-25 2022 in Oslo - and more specifically like to attend the [Financial Freedom Track](https://hrf.org/hrf-and-seetee-present-the-financial-freedom-track-at-off-2022/). I think this is extremely important for two predominant reasons. 
+
+1. The Monero Policy Working Group (and the Monero community at large) should try and have a representation at these sorts of events to understand what the narrative being pushed is, and HOW it is being pushed. This is especially important when the overarching message is “Bitcoin is good for censorship resistance and the pursuit of liberty and freedom”. We all know that this is an EXTREMELY DANGEROUS message - if not communicated alongside the requirement for privacy, decentralisation, and fungibility - that only Monero ACTUALLY provides. 
+
+2. It gives the Monero community a choice to raise a voice - similar to being a raconteur - to stand up to the BTC maxi narratives and to ensure that the “Bitcoin is the answer narrative is met with sound political, technical, and ideological pushback. 
+
+**WHY**
+
+In 2019 we were lucky enough to be invited to host a fringe event at the Oslo Freedom Forum. We did not get the same invite this year - but were provided with free tickets to attend and a warm invite from Alex Gladstein (the Chief Strategy Officer). 
+
+I have recently given a podcast talk, on the Exit Strategy podcast, in response to Gladstein’s maxi narrative. You can listen to this [here](https://exitstrategypod.libsyn.com/015-robin-renwick-revisiting-bitcoin-human-rights-and-the-oslo-freedom-forum) and the original Gladstein talk [here](https://exitstrategypod.libsyn.com/005-alex-gladstein-bitcoin-and-human-rights). 
+
+I am happy to donate my time to going, attend the event, and to provide a report to the community on the narrative, discussions and overarching message/propoganda that is being pushed. 
+
+I also think it is a good opportunity to hand out info/flyers at the event, and I will work to ensure I attend with a number of flyers/info sheets in pursuit of this. 
+
+Exit Strategy podcast has also agreed to interview me after the event to provide an update. I plan to use that opportunity to discuss the inherent dangers of promoting the BTC narrative in discussions in human rights, censorship resistance, etc. I would also use that opportunity to call out the ill-informed narratives that are pushed both at the event, and in the wider BTC community. It is time now to start taking the message seriously. 
+
+**MILESTONES**
+
+I propose half of the XMR being paid out to allow me to pay for flights and hotels. I have priced hotel at ~ €200 per night (same hotel I stayed at in 2019), and flights at ~€300 (sub-total of €1100)
+
+I propose a stipend for food of €50 per day for four days (sub-total €200). 
+
+I also propose writing a report and partaking in an Exit Strategy podcast. My time for this would be approximately 6 hours at €50 p/h (sub-total €300). 
+
+I also include printing costs for 200 flyer/info sheets (€100), similar to the ones we did for Oslo Freedom Forum 2019.
+
+In total this is €1700. 
+
+At the current market rate of ~€200, this is 8.5 XMR. 
+
+**EXPIRATION DATE**
+
+As I would like to get the accommodation and flight booked asap, I propose an expiration of 1st May on the CCS, and an expiration of the whole CCS of 1st July. Though this would also depend on the interview with Exit Strategy podcast. 
+
+**AMOUNT**
+
+8.5 XMR.
+
+
+

mj-compil-time-reduction.md

 ---
-layout: wip
+layout: cp
 title: Compilation time reduction and housekeeping
 author: mj
 date: April 15, 2020
@@ -27,11 +27,11 @@ milestones:
     status: unfinished
   - name: Forward declarations of own classes + interfaces
     funds: 15% (8 XMR)
-    done:
+    done: moot
     status: unfinished
   - name: One class per header
     funds: 4% (2 XMR)
-    done:
+    done: moot
     status: unfinished
   - name: Parallel tests (ctest -jN)
     funds: 9% (5 XMR)
@@ -39,40 +39,38 @@ milestones:
     status: finished
   - name: Static methods of the wallet2
     funds: 8% (4 XMR)
-    done:
+    done: moot
     status: unfinished
   - name: Proper ordering of headers (general last)
     funds: 6% (3 XMR)
-    done:
+    done: moot
     status: unfinished
   - name: Miscellaneous hourly work @ $40/hr (23.4 XMR remaining)
     funds: 47% (25 XMR)
-    done:
+    done: moot
     status: unfinished
+  - name: All remaining -> General fund
+    funds: All remaining (40.4 XMR)
+    done: 26 February 2022
+    status: finished
 payouts:
   - date: 4 January 2021
     amount: 2.9
   - date: 17 June 2021
     amount: 9.6
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
+  - date: 26 February 2022
+    amount: 40.4
 ---
 
+# Update
+This proposal has been marked completed and the remaining funds forwarded to the Monero General Fund at the request of the proposer, after seeking community input. The 12.5 XMR was paid out to mj, leaving 40.4 XMR.
+
 # What
 The proposal is about minimizing the compilation time of the project. 
 
 # Who
 I have 12 years of object oriented programming experience, mostly in C++. I'm a passionate programmer, not only somebody who does this for money. I hold a M.Sc. degree in Computer Science.
-Although I'd prefer staying anonymous, what I can tell about myself, is that I used to actively develop a couple of space flight navigation instruments in C++ for a realistic freeware space flight simulator. 
-Nowadays I work on an automated trading and backtesting platform, also in C++, where speed matters.
 Being able to see the code in a hierarchical order, both projects allowed me to create an extensive library, ready to be reused in a project like Monero, with serialization being my first low hanging fruit.
-To pay the rent, I've worked in various fields, from automatic control, GIS apps, navigation systems, visual driving assistance and recently in autonomous driving.
 My contributions to Monero so far are the following:
 - I was able to bring ccache to the project. The amount of code committed is not large, but the effect size is. The Travis CI compilation time went from 22 minutes down to [2 minutes for each build](https://github.com/monero-project/monero/pull/6452#issuecomment-615024910).
 - afterwards, selsta picked it up and [brought ccache to the CI "workflows"](https://github.com/monero-project/monero/pull/6495), achieving similar results.

mj-part-time-2021-q4.md

 ---
-layout: fr
+layout: cp
 title: mj part time coding Q4 2021
 author: mj
 date: Oct 20, 2021
@@ -7,23 +7,23 @@ amount: 72.0 XMR
 milestones:
   - name: Month 1
     funds: 24.0 XMR
-    done:
-    status: unfinished
+    done: 30 November 2021
+    status: finished
   - name: Month 2
     funds: 24.0 XMR
-    done:
-    status: unfinished
+    done: 31 December 2021
+    status: finished
   - name: Month 3
     funds: 24.0 XMR
-    done:
-    status: unfinished
+    done: 29 January 2022
+    status: finished
 payouts:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
+  - date: 4 December 2021
+    amount: 24
+  - date: 5 Jan 2022
+    amount: 24
+  - date: 26 February 2022
+    amount: 24
 ---
 
 

mj-part-time-2022-q2.md

+---
+layout: cp
+title: mj part time coding Q2 2022
+author: mj
+date: Mar 01, 2022
+amount: 102.0 XMR
+milestones:
+  - name: Month 1
+    funds: 34.0 XMR
+    done: 30 March 2022
+    status: finished
+  - name: Month 2
+    funds: 34.0 XMR
+    done: 10 May 2022
+    status: finished
+  - name: Month 3
+    funds: 34.0 XMR
+    done: 18 June 2022
+    status: finished
+payouts:
+  - date: 2 April 2022
+    amount: 34
+  - date: 18 May 2022
+    amount: 34
+  - date: 4 July 2022
+    amount: 34
+---
+
+
+# What
+
+I propose to work for 3 months, spending 30 hours a week on Monero Core and Monero GUI, specifically on topics such as (in this order):
+- reviewing the Monero Core and GUI code
+- enabling and helping new developers
+- providing more documentation for new devs
+- CI fixes
+- addressing user issues (whenever I can help)
+- benchmarking [tsqsim](https://github.com/mj-xmr/tsqsim) (although this one is arguable)
+- regenerating and extending my [Monero health report](http://cryptog.hopto.org/monero/health/)
+- adding Monero-GUI to the health report
+- general firefighting, whatever problems we face in near future
+
+# Why
+
+Over the last 3 month period, I've been fully focused on developing my [tsqsim](https://github.com/mj-xmr/tsqsim) tool for Monero Research Lab's [OSPEAD](https://ccs.getmonero.org/proposals/Rucknium-OSPEAD-Fortifying-Monero-Against-Statistical-Attack.html) project. Even though I did occasionally review new code in Monero Core and GUI, a few members noted that since I was being focused on the tool so much, they felt developer resources being dragged away from Core/GUI. I'd gladly take it as a compliment :>
+
+The current state of tsqsim is "usable", but not yet perfect. To unleash its full potential, some more work has to be put in: I estimate ~2-4 months. However this can be scheduled for later (and half-time) as well, while the OSPEAD research could already start, based on the current state of tsqsim.
+
+Therefore in the next 3 months, I'd like to catch up with the usual maintenance. Additionally, I'd like to continue enabling new devs, by pointing them to documentation, explaining and extending it. Previously, I was helping new devs in the #monero-dev channel. Just recently I noticed, that there's quite a crowd awaiting directions in the Recruitment Matrix Channel, formed at the end of last year by @Rucknium (correct me if I'm wrong). I promised them, that I'd be available from March for either 1-on-1 sessions or to answer general questions in the channel.
+
+## Benchmarking tsqsim
+
+A special sub-task of the quarter would be benchmarking the tsqsim, requested by @selsta and @bigbklynballs. Even though C and C++ remain the fastest languages (yielding only to Assembler), I'm of the opinion, that the USP of tsqsim is the ability of setting up controlled experiments, without the need of them to be coded by the Researcher. This fact will be reflected by the benchmark, or more generally then: a comparison. While the user @bigbklynballs suggested benchmarking tsqsim against [all of his proposed 10 alternatives](https://libera.ems.host/_matrix/media/r0/download/libera.chat/ffa8bb5c2f97fd1ff5b9990a70f139ad96586270), which were:
+
+- https://github.com/statsmodels/statsmodels
+- https://github.com/rapidsai/cuml
+- https://github.com/h2oai/h2o4gpu
+- https://github.com/alkaline-ml/pmdarima
+- https://github.com/timeseriesAI/tsai
+- https://github.com/facebookresearch/Kats
+- https://github.com/unit8co/darts
+- https://github.com/winedarksea/AutoTS
+- https://github.com/alan-turing-institute/sktime
+- https://github.com/linkedin/greykite
+
+, I'll spare the Community's funds by restricting the benchmarking process to 1 or 2 of the above tools and then ask for further wishes.
+
+# Who
+
+mj, I have been contributing to Monero-core since 2020. Here is a [list of my previous work](https://github.com/pulls?q=is%3Apr+author%3Amj-xmr+archived%3Afalse+is%3Amerged+), all related to Monero, even if it got upstreamed.
+
+
+## Previous reports
+Here is a list of the previous reports, that describe my completed or started tasks in more detail:
+- [Report 01](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/200#note_10764)
+- [Report 02](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/200#note_10860)
+- [Report 03](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/200#note_10954)
+- [Report 04](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/231#note_11248)
+- [Report 05](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/231#note_11421)
+- [Report 06](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/231#note_11662)
+- [Report 07](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/266#note_14040)
+- [Report 08](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/266#note_14436)
+- [Report 09](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/266#note_14671)
+
+[Previous CCS Proposal](https://ccs.getmonero.org/proposals/mj-part-time-2021-q4.html)
+[Postponed CCS Proposal (tsqsim)](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/283)
+
+# Proposal
+
+I will spend 30 hours a week on Monero for the next 3 month period, starting from 1st March.
+
+I propose a wage of 45 €/h for 3 months. As of 01.03.2022 the average between the opening and closing price of XMR/EUR was at (159.850 + 151.990)/2 = 155.92 € [according to investing.com](https://www.investing.com/crypto/monero/xmr-eur-historical-data). This would make a total of:
+45 €/h * 30 h/week * 4 weeks * 3 months / 155.92 XMR/EUR = 103.899 XMR. Rounded down to be divisible by 3 -> 102 XMR.
+
+Cheers!
+
+
+
+# Expiration date
+30 Jun, 2022

monero-bash.md

+---
+layout: cp
+title: monero-bash, a wrapper for monero written in bash, for Linux
+author: hinto-janaiyo
+date: March 24, 2022
+amount: 10.0 XMR
+milestones: 
+  - name: Integrated P2Pool Mining
+    funds: 5 XMR
+    done: 30 April 2022
+    status: finished
+  - name: RPC/Daemon API integration
+    funds: 3.5 XMR
+    done: 30 April 2022
+    status: finished
+  - name: Mining quickstart commands
+    funds: 1 XMR
+    done: 30 April 2022
+    status: finished
+  - name: Automated encrypted wallet backup
+    funds: 0.25 XMR
+    done: 30 April 2022
+    status: finished
+  - name: Auto GPG key verification for binaries
+    funds: 0.25 XMR
+    done: 30 April 2022
+    status: finished
+payouts:
+  - date: 30 April 2022
+    amount: 10
+---
+
+# Intro
+
+Hi everyone, I'm hinto. This is my first CCS Proposal.
+
+I would like to develop directly for Monero, but unfortunately: I cannot code. With that said, I've setup Monero nodes and miners on many machines for others and myself, and after a while, ended up making tons of Bash scripts to automate these processes.
+
+I rewrote a couple scripts to make them usable by anyone and put them in the public:
+- [XMRig-Auto-Build, for downloading/building everything needed to build XMRig](https://github.com/hinto-janaiyo/XMRig-Auto-Build)
+- [monero-toolchain, a link filterer that always downloads the latest releases of monero-related software](https://github.com/hinto-janaiyo/monero-toolchain)
+
+I'd like to receive support through this CCS to continue on a more ambitious project: `monero-bash`
+
+## What
+
+[monero-bash](https://github.com/hinto-janaiyo/monero-bash) is a wrapper for monero written in bash, for Linux.
+
+monero-bash does what bash normally does:
+**it glues together multiple programs in a more automatic fashion, in this case:**
+- monerod
+- monero-wallet-cli
+- monero-rpc
+- (p2pool planned...)
+
+monero-bash abstracts `monero-cli` commands into interactive prompts and `linux-like` syntax
+
+while monero-bash is helpful for people who want everything automated, it's also just as powerful as monero-cli because:
+~~~
+it is essentially a bunch of bash scripts invoking monero-cli
+~~~
+and so, any `monerod.conf` or `monero-wallet-cli.conf` that may be in your `.bitmonero` folder, can be used by monero-bash
+
+## Features
+**currently implemented:**
+- Automatic `monero` release upgrades, verified with SHA256SUMS
+- Software and wallet management
+- Easy wallet/daemon control
+- Price stats from API
+
+**to be added:**
+- Automatic P2Pool mining
+- RPC/Daemon API integration
+- Mining quickstart commands
+- Encrypted wallet backups
+- GPG key verification for binaries
+
+## Issues
+`monero-bash` runs into problems much like [systemd](https://en.wikipedia.org/wiki/Systemd):
+There are massive conveniences to having a single program manage and abstract everything for an end user, however, that funnels all the trust onto that single program. Although... `systemd` is a highly adopted system-manager on Linux, `monero-bash` is a niche script-system for Monero *from some random person.* So, the question might be asked:
+
+## But, Why?
+I think something like `monero-bash` would give a nice and easy bootstrap to people who normally wouldn't have manually setup a node or setup P2P mining. Another (maybe selfish) reason is that I'm making this to actually use it myself! Running `monerod`, `monero-wallet-cli`, `monero-rpc`, `XMRig` and `P2Pool` on multiple headless machines makes me wish there were a more central program to manage it all.
+
+## Security
+As the person who will be making this, I obviously have no problems using it, however, even I would be wary of using other's supposedly "safe" scripts to manage sensitive things like Monero. Thankfully since it's just Bash, anyone that uses Linux (or macOS,BSD) will most likely be able to audit everything. If there are `spooky` looking functions or variables, I'd be happy to explain its purpose and what it does. If something looks over-complicated, it's not on purpose, I'm just bad at bash.
+
+## End-Game & Proposal
+I'd like for:
+- Running a Monero Node
+- Managing Wallets
+- Upgrading and Verifying Monero-CLI Binaries
+- Mining on P2Pool as the Default
+
+to be as simple as running a couple commands.
+
+I'll be working for however long it takes to satisfy these milestones:
+- 5.0 XMR: Integrated P2Pool Mining
+- 3.5 XMR: RPC/Daemon API integration
+- 1.0 XMR: Mining quickstart commands
+- 0.25 XMR: Automated encrypted wallet backup
+- 0.25 XMR: Auto GPG key verification for binaries
+
+for a total of 10XMR, regardless of fiat pricing.
+
+[For full details of the current version, here is the GitHub.](https://github.com/hinto-janaiyo/monero-bash)
+Feedback would be appreciated.

monero-inflation-checker.md

+---
+layout: cp
+title: Creation of Python tools and educational material for checking and explaining the absence of money leakage (a.k.a. inflation) in Monero.
+author: DangerousFreedom
+date: March 25, 2022
+amount: 43.2
+milestones:
+  - name: MLSAG
+    funds: 14.4
+    done: 31 May 2022
+    status: finished
+  - name: CLSAG
+    funds: 14.4
+    done: 3 July 2022
+    status: finished
+  - name: Seraphis / Optimizations / Functional website delivery
+    funds: 14.4
+    done: 4 September 2022
+    status: finished
+payouts:
+  - date: 2 June 2022
+    amount: 14.4
+  - date: 6 July 2022
+    amount: 14.4
+  - date: 7 September 2022
+    amount: 14.4
+---
+## TLDR
+Minimal Python tools and educational material for checking inflation in Monero.
+Check the initial scratch [here](https://criptando.pythonanywhere.com/).
+I would like your support to finish it :)
+
+## What and Why ?
+I will try to address the following issues:
+
+1) Provide solid information about inflation.
+    This project is highly focused on building the minimum necessary tools in Python to prove that there is no money leakage (inflation) occurring or that has occurred. Therefore, the community is welcome to use the tools provided here and also make improvement suggestions on how to answer this question in the most decisive way.
+
+2) Educational material.
+    This work also intends to convey the message that Monero is as safe or more as Bitcoin (cryptographically speaking). Therefore some educational material is provided for the layman and for someone looking to understand the code. Convincing someone about something may require different levels of explanations. This work tries to address this issue.
+
+3) Provide more transparency and ease the fear of users and investors.
+    Nobody heavily invests into something that they do not understand. This work provides more transparency and education on how the blockchain works with the focus on the inflation issue. Therefore, users would feel safer by investing and using Monero.
+
+4) Abstraction of the C++ code and further implementations using Python.
+    This work also gives more independence from the C++ code, which the great majority of people heavily relies on to verify the blockchain. If useful functions are implemented here, it could also help, in the future, other people to make different implementations like wallets and nodes in Python.
+
+5) Overview of blockchain history focused on the inflation issue.
+    Any successful project has to be able to tell its history in the most detailed way for the newcomers that did not live the events that happened in the past. Therefore, scanning the whole blockchain looking for leakages and providing some educational material with codes, some stats and insights is crucial not only for the new members but actually for anyone who wants to revisit the history.
+
+
+## Who
+- I would like to stay anonymous for the moment. I believe that the goal of the CCS is to fund an idea instead of a person so if I do not do the job, the CCS can fund someone else to do it in the way it was proposed here.
+- I have never contributed to Monero and I actually got on-board recently although I know its existence for some years.
+- I started investigating after this post on [reddit](https://www.reddit.com/r/Monero/comments/s9z67a/again_about_the_inflation/).
+- I have a broad set of experiences like web design, Python coding, applied math and economics.
+- I am highly motivated to work on this project as it is almost an existential question for me.
+- I am pretty sure that I am capable of doing it following the proposed time schedule as I have been working in this project for the past two months already.
+
+
+## About the proposal
+First, I would like to thank everyone in the MRL channel for pointing me some directions. I believe that basically what needs to be done is the creation of Python scripts and educational materials in order to: check the ring signatures, check the amounts involved, check the uniqueness of key images and check the emission curve.
+
+These tasks have to be done for the Pre-RingCT era, MLSAG and CLSAG.
+
+As I have already done a scratch for the Pre-RingCT (v1) era (it is not ready yet but I strongly recommend you to check out the [temporary version](https://criptando.pythonanywhere.com/) to have an idea how the final product will look like), I still need to do improve the Pre-RingCT era and create the necessary material for the MLSAG and CLSAG. I also propose to create some educational material and scripts for Seraphis.
+
+This work does not intend to end the discussion about inflation in Monero, it is quite the opposite, it looks for providing tools and educational material so people can have the same base for a serious and structured discussion about it. I do not expect to deliver the message that you should blindly trust in Monero but I expect to deliver a message which will raise the awareness on the inflation issue.
+
+I will do my best to reply in a meaningful way the concerns of the community and I also will be constantly in touch with the developers and the ones that have much more knowledge than me (they have been really nice and kind so far) to explain the inflation issue in the best way. 
+
+## Importance for the community
+- Give some material and orientation for the ones looking to increase their understanding about the Monero blockchain with the focus on the inflation issue.
+- Create Python functions (ring signature verifiers and others) to check the real data stored in the blockchain
+- Give more transparency and explanation to the verification process of a transaction
+- Reduce the fear of investors that do not understand how Monero can be transparent and at the same time private.
+
+
+
+## Timeline and payouts
+First delivery: Codes, nice explanation and some stats about MLSAG /
+Date: End of May /
+Amount: 14.4 XMR
+
+Second delivery: Codes, nice explanation and some stats about CLSAG /
+Date: End of June /
+Amount: 14.4 XMR
+
+Third delivery: More codes and explanations (Seraphis), clean website, optimizations and corrections /
+Date: End of August /
+Amount: 14.4 XMR
+
+I propose to work for 18 USD per hour, 30h per week, for 16 weeks. Which means 18*30*16 = 8640 USD / 200 USD = 43.2 XMR
+Total: 43.2 XMR
+
+I will also pay for the costs to host the website and buy a meaningful domain name for the project.
+
+
+## About deliveries
+I will make all the content (codes, images, texts, ...) available and free to use, modify, share and do whatever you want.
+As soon as I finish some task, I will make them available.
+
+## Expiration Date
+It would be nice if it get funded before 30.04.2022 so I can keep the expected timeline. Thank you very much in advance.

monero-serai-wallet-audit.md

+---
+layout: wip
+title: Audit monero-serai and monero-wallet
+author: kayabaNerve
+date: October 11, 2024
+amount: 1050 XMR
+milestones:
+  - name: Audit of monero-[serai, wallet], including the FROST-inspired multisig protocol
+    funds: 1050 XMR
+    done:
+    status: unfinished
+payouts:
+  - date: 3 December 2024
+    amount: 1050
+---
+ 
+monero-serai and monero-wallet are public-good libraries built by myself as part of my work on Serai DEX. Despite the "-serai" name, both libraries have always been intended to be usable and actually used by the Monero community as a whole. Development has been ongoing for over two years. During that time, I have hired developers to work on and review it (including j-berman who truly needs credit and acknowledgement for their contributions), yet have never seeked community funding for my work. Now that monero-serai and monero-wallet are ready for their 1.0 release, meaning they have reached the necessary milestone to be considered sufficiently developed and meaningful, I have decided to request the community's support for their audits.
+ 
+monero-serai is a from-scratch reimplementation of the Monero transaction protocol in Rust. It originally also
+included wallet functionality yet that was split out into the monero-wallet library to offer greater
+flexibility to consumers.
+ 
+monero-serai is used by Cuprate[[1]](
+  https://github.com/Cuprate/cuprate
+)[[2]](
+  https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/405
+)[[3]](
+  https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/422
+)[[4]](
+  https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/431
+)[[5]](
+  https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/456
+)[[6]](
+  https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/469
+)[[7]](
+  https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/484
+) for its parsing/handling/stateless verification of Monero transactions. Specifically, included is:
+ 
+- An implementation of v1 and v2 transactions
+- Cryptonote ring signature, MLSAG, and CLSAG verification
+- Borromean, Bulletproofs, and Bulletproofs(+) verification
+ 
+monero-serai also underpins monero-wallet, a Rust library for sending and receiving Monero. It's intended to have a clean, high-level API, be usable in a variety of contexts (from desktops to embedded devices to web browsers), and support everything from traditional wallets to more novel use cases (such as atomic swaps). As part of this, it offers:
+ 
+- Proving CLSAG, Bulletproofs, and Bulletproofs(+)
+- Honest-sender outgoing view keys (deterministically derived transaction keys to simplify payment proofs and allow verifying transactions match an intent)
+- A FROST-inspired multisig which has O(1) per-signer upload complexity and O(n) computational complexity, compared to Monero's multisig which has O(n!) complexity (where n is the amount of signers)
+ 
+Potentially of most note is the work on multisig. FROST is a widely regarded, [IRTF standardized](https://datatracker.ietf.org/doc/rfc9591/) multisignature protocol for Schnorr signatures which I've applied to Monero's CLSAG (caveats apply). The application to CLSAG is built upon [modular-frost](https://github.com/serai-dex/serai/tree/develop/crypto/frost), a FROST implementation I wrote for Serai and have already [prior audited](https://github.com/serai-dex/serai/tree/develop/audits/Cypher%20Stack%20crypto%20March%202023).
+
+Monero has historically had issues with its multisig which has a novel high-complexity DKG and a signing protocol which isn't formalized (though is currently Musig2-inspired). monero-wallet represents an opportunity to step forth with a formalized, proven, and audited multisignature implementation. One idea occassionally brought up has been to remove multisig from Monero proper, placing it in its own distinct repository, in order to not have multisig burden Monero. With the work done on monero-wallet, and the audit being funded here, completely deferring multisig to it would become a viable option.
+ 
+monero-wallet has also been checked to have a matching decoy selection algorithm (specifically, a matching distribution of selected decoys), fee algorithm, and various other properties (such as TX extra) to ensure its transactions won't be fingerprintable.
+ 
+There is interest by multiple wallets to use monero-wallet, and it's already being developed on top of by Serai, a user-facing multisignature use case, and an application premised on web technology (which compiles monero-wallet to WASM).
+ 
+This CCS is to fund the formalization of the implemented CLSAG multisig protocol (already outlined), provide the necessary security proofs (derived from FROST), and audit monero-[serai, wallet]. The audit will be done by Cypher Stack (their quoted amount being the amount requested). The one milestone is to be paid directly, immediately, and in full, to Cypher Stack for their work.
+
+After the audit, the plan is to transfer monero-serai into the newly created [monero-oxide](https://github.com/monero-oxide/monero-oxide) organization (head by myself and boog900 from Cuprate). This is to help ensure it stands as a public good and doesn't solely service a single project's needs. Additional discussions are ongoing regarding the future governance of monero-wallet.

monero-to-the-oscars.md

+---
+layout: cp
+title: Help an independent film featuring Monero get to the Oscars™!
+author: markofdistinction_
+date: January 20, 2023
+amount: 154
+milestones:
+  - name: upon approval
+    funds: 77
+    done: 25 September 2023
+    status: finished
+  - name: upon qualifying for Academy Award
+    funds: 77
+    done: 25 September 2023
+    status: finished
+payouts:
+  - date: 5 November 2023
+    amount: 154
+---
+
+### Note: This proposal generated significant and thoughtful discussion; potential donors are invited to read it [here](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/371).
+
+![HorizontalPoster](https://raw.githubusercontent.com/markofdistinction/ccs/main/MarkOfDistinction_16x9_1280x720.jpg)
+
+# Help an independent film featuring Monero get to the Oscars™!
+
+### Who are you?
+
+Hey all, my name is George Nicholas, an “award-winning” filmmaker and Monero enthusiast. You can see my IMDb profile here: https://www.imdb.com/name/nm11077440/    
+I was involved with making "Monero Means Money".
+
+### What’s up?
+
+I’ve written and directed an independent, 38-minute live-action film titled MARK OF DISTINCTION. The film is in Spanish and English and was shot in Tijuana, Mexico in July of ‘22 on 16mm Kodak film. It features Monero, but is not focused on it -- it is inspired by real events and tells the story of a 16-year-old boy who gets recruited by the Mexican cartel to smuggle liquid meth across the border. The boy dies tragically at the hands of U.S. Customs and Border Protection, who ask him to drink the liquid to prove that it’s not drugs.
+    
+    
+You can see a report and footage of the incident here:
+https://www.youtube.com/watch?v=7KsKtVnrRaM    
+And some behind-the-scenes photos from our shoot [here](https://twitter.com/markofdistinctn/status/1554237266460954625?s=20) and [here](https://twitter.com/markofdistinctn/status/1554237518098313217?s=20).    
+    
+Government coercion over the individual is the reason I came to Monero and it is the reason I was driven to tell this story.
+
+### How is this related to Monero?
+
+Monero is featured in 3 scenes. As background, the protagonist, MANUEL, has found a physical Monero coin that his father had stashed away for him before his disappearance--
+
+### Did you just say a physical Monero coin? gtfo
+
+Yeah, a physical Monero coin, like this one: https://bitcointalk.org/index.php?topic=1502918.0
+
+### OK, so what happens next?
+
+So, Manuel is carrying the coin around in his pocket like an idiot, not realizing what he has. His friend, RODOLFO, sees him trying to shove it down a slot machine, but thankfully the coin is too big to fit. Rodolfo explains to him what he has and Manuel’s eyes light up. Outside the bar, the two get beat up because of an earlier incident and the hooligans make off with Manuel’s scooter and his coin. Manuel gets his revenge and recovers the scooter, but not the coin. Rodolfo later finds the coin and tries to give it back to Manuel, but it is too late…    
+    
+Monero represents the boy’s potential – the unrealized wealth that every individual carries within, although not everyone finds the key to unlock it. The coin ends up with the person who understands its value, as often happens in real life.
+
+### How can we help?
+
+I self-funded the shoot and post-production (the budget was in the low six figures), which exhausted my personal savings. We need funds for the most crucial phase – the release of the film. This includes getting it in front of festivals and promoting it there, hiring a publicist, running an awards campaign. All this costs money and I am coming to the Monero community for help.
+
+### What do we get in return?
+##### 1. Exposure (the good kind)
+The film has the chance of reaching hundreds of thousands and even millions of people. Not every viewer will become a Monero user, but they will all be exposed to Monero in a positive way. The community will also receive an acknowledgement in the credits, to the effect of "this movie was kindly supported by the Monero community" with the Monero logo and getmonero.org underneath.    
+    
+Monero already gets exposure in the media and [even some TV shows](https://twitter.com/vikrantnyc/status/1616152774856540166?s=20), but almost always as a Ransomcoin. This is a story that shows Monero being used in the way most of us use it -- as a savings vehicle that we can spend or pass down to our loved ones outside of anyone else's control. Monero means money, but it also represents so much more -- a path towards personal freedom, away from coercion by the state or others. This is what the film tries to get across and hopefully it succeeds.
+
+##### 2. Physical presence
+With the community's help and the right release strategy, the film will play at major festivals across the world. Anytime the film plays, this will be an opportunity for an impromptu Monero meetup. Screenings can be publicized in the community beforehand to attract local Monero fans throughout the world.
+
+##### 3. A cause to rally behind
+I know we take the whole magic internet money thing seriously around here, which is why I love Monero. It is the reason no other coin was considered to take its place in the film. And I respect the more conservative view that the CCS should only be used to fund developer work. The number of undelivered, CCS-funded projects is dishearteninig, which is why I held off on asking for help until the film was actually made and ready to go.    
+    
+Monero has the best p2p cash characteristics of any coin, but we could do a better job of celebrating that. This film will give us an opportunity to rally behind a cause that almost all of us agree with -- the right of the individual to remain free from oppression, especially from governments. We can go to festivals together or follow from home, celebrate the wins and mourn the losses. Consider it an exercise in community-building.
+
+##### 4. Some cool GIFs, of course.
+But you'll get them regardless, since the film is already made.
+
+![CoinGIF](https://raw.githubusercontent.com/markofdistinction/ccs/main/coin_squeeze.gif)
+    
+Also, the idea to have a private screening for the community at MoneroKon was floated, which I'd be open to doing if there is interest.
+
+### Alright, how much do you want? Spit it out.
+
+###### We are looking to raise 154 XMR (the equivalent of $25K at Kraken’s current 20-day EMA)
+
+### What's your Oscars strategy? (i.e. How are you going to spend it?)
+
+Films under 40 minutes are considered live action short films by the Academy of Motion Picture Arts and Sciences. This is the category we're aiming for. There are two ways for a film to qualify:
+
+1. The film must win an award at one of the ~130 Academy Award-qualifying festivals throughout the world:
+    https://www.oscars.org/sites/oscars/files/95aa_anim_short_festivals.pdf
+    Submission fees to these festivals are generally in the $50-$100 range, so that alone can eat up $10K.
+2. The film must be publicly exhibited for paid admission in a movie theater in Los Angeles or New York City for
+    one week:  https://www.oscars.org/sites/oscars/files/93aa_short_films.pdf 
+    This is the cheaper option at about $3K, but films that qualify with a festival win are preferred by Academy voters, so we'll try the festival route first.
+
+Once the film qualifies, the remaining funds will go towards hiring a publicist and running an awards campaign. Jim Dobson at Indie-PR has seen the film and loves it.    
+He ran the Oscars campaign for AUDIBLE, a short documentary that received a nomination in 2022. https://www.indie-pr.com/about    
+Another PR firm with extensive experience that has expressed interest is JJPR: http://joshuajasonpr.com/film-campaigns    
+    
+I make no guarantees that we will win an Oscar or be nominated, but every industry professional who has seen the film thinks we have a good chance (and not just the publicists who stand to make money). We are taking this journey and I'd like the community to come along!
+
+### Who else has seen the film?
+
+I've reached out to some people I know in the community, who have kindly taken the time to see it. Here's what they had to say:
+ 
+##### jberman said:
+    "This has the feel of something that would win a lot of awards."
+    "Was the idea of the friend chasing him to give the coin to him basically saying Monero represented an
+    alternative path to a better life/better system instead of the darker one he chose? That's how I read its place
+    in the story."
+##### midipoet said:
+    "you don't need me to tell you, but for what it's worth, the production value is extremely high" 
+    "it's pretty much feature length quality, as you were aiming for. what struck me most though was the quality
+    of the acting."
+##### Vik Sharma said:
+    "Really, really well made."
+##### Doug from MoneroTalk said:
+    "Captivating! Sunita and I loved it."
+##### Johnny Mnemonic said:
+    "Awesome film! The Monero coin inclusion was great… 
+    Touching story… I really feel for the kid at the end because he’s just trying to make things right with his grandfather. 
+    I also liked that you included real footage at the end… really makes you feel how real it is. "
+##### dsc said:
+    "that last scene had me on the edge of my seat!"
+### What happens if Monero's price fluctuates in the meantime?
+The amount we're raising is denominated in XMR. Any fluctuations in fiat value are at our own risk/benefit.
+
+### When do you expect to be paid?
+50% upon approval, 50% upon qualifying for the Academy Awards, as described above.
+
+### Is the film on any social media?
+
+https://twitter.com/markofdistinctn    
+https://instagram.com/markofdistinctionfilm    
+https://fb.com/markofdistinctionfilm
+
+### Can I see it before I donate?
+Yes, please send 1 piconero (0.000000000001 XMR) to the donation address as a captcha and email markofdistinction@proton.me with the txid and tx key and you'll receive a link back.
+
+### OK, take my money! ;-)
+