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.

knueffelbund-gui-design-for-q2-2019.md

+---
+layout: cp
+title: knueffelbund GUI design for Q2 2019
+author: knueffelbund
+date: 3 April 2019
+amount: 37
+milestones:
+  - name: April
+    funds: 33% (12 XMR)
+    done: 30 April 2019
+    status: finished
+  - name: May
+    funds: 33% (12 XMR)
+    done: 13 May 2019
+    status: finished
+  - name: June
+    funds: 33% (13 XMR)
+    done: 30 June 2019
+    status: finished
+payouts:
+  - date: 8 August 2019
+    amount: 37
+
+
+---
+Hi,
+
+This is my first proposal, but I've been contributing to the design of the Monero GUI wallet [since November, 2017](https://www.reddit.com/r/Monero/comments/7c0bo7/had_some_fun_yesterday_evening_restyling_the/). You can see the designs I've done so far on [Github](https://github.com/GBKS/monero-wallet-design) and [Zeplin](https://scene.zeplin.io/project/5a0777492a92d8ac5beb3125). I also designed and built [ExploreMonero.com](https://www.exploremonero.com) and organize my crypto UX research [here](https://www.cryptouxhandbook.com/). The GUI team has really picked up the pace of development the past few months, and I'd like to continue supporting them with design work as much as I can. That's why I'm putting this proposal together.
+
+A lot of my work as a UX designer has to do with usability. For example, I recently did some [user testing](https://paper.dropbox.com/doc/Monero-GUI-user-testing--AaiYNKmVg5Vjqt5_ik~UEsoMAg-YAWmy01OJa5vkmdQvt6wg) on the wallet, in which it become clear that the mnemonic seed section during wallet creation is easily missed by users. So I created a [design and proposal](https://github.com/monero-project/monero-gui/issues/2043) to move this part into a separate screen. I'm just mentioning this because my proposed work is all about usability improvements, not about changing the visual styling of the wallet (other than the new white theme). Good usability his hugely important if want Monero to become more widely used.
+
+Things I'd like to work on the next 3 months:
+
+- Iterate the merchant page ([first draft](https://www.dropbox.com/s/kf1t5hmip64kpuk/monero-merchant-page-gbks-190314.png?dl=0))
+- Address more feedback from the [user testing session](https://paper.dropbox.com/doc/Monero-GUI-user-testing--AaiYNKmVg5Vjqt5_ik~UEsoMAg-YAWmy01OJa5vkmdQvt6wg), particularly the first steps after wallet creation
+- Revise send flow (which currently involves 4 differently styled overlays)
+- Make it more obvious how accounts and addresses are organized in the wallet
+- Make it more inituitive to add transactions descriptions and manage your address book
+- Support implementation of the white theme
+- Work with Electricsheep01 to integrate [his ideas](https://github.com/monero-project/monero-gui/issues/2024) into the wallet design
+
+If the community has other priorities for design improvements (how about a [mobile app](https://www.dropbox.com/s/inodkkm8xjv7sry/Monero-mobile-concept-gbks-180823.png?dl=0)?), I'd be happy to switch things up.
+
+All my work is directly done in high-fidelity designs (vs wireframes, which are more helpful when creating new software vs iterating existing software). All designs will be publicly posted in Github and Zeplin, and open for discussion via Reddit and Github issues ([example](https://www.reddit.com/r/Monero/comments/ae6zet/feedback_required_wizard_redesign_icons/)).
+
+The funding amount is based on the following math:
+
+- 60 hours = 5 hours per week for 12 weeks (~3 months)
+- 0.6289 XMR per hour ($30 + 0.2 XMR per hour at 1 XMR = $69.95)
+- 60 hours * 0.6289 XMR per hour = ~37 XMR
+
+Let me know if you have any questions, and thanks in advance for your support.
\ No newline at end of file

lh1008_spanish_localization.md

+---
+layout: cp
+title: Spanish Localization
+author: lh1008
+date: 22 Aug 2020
+amount: 10
+milestones:
+  - name: Milestone 1 - 40 hours of work
+    funds: 5
+    done: 30 September 2020
+    status: finished
+  - name: Milestone 2 - 40 hours of work
+    funds: 5
+    done: 31 October 2020
+    status: finished
+payouts:
+  - date: 5 October 2020
+    amount: 5
+  - date: 9 November 2020
+    amount: 5
+---
+
+Hello everyone,
+
+Me @lh1008 again, by myself since 2018 from my first proposal [Monero Outreach Communication Group Coordinator + translator](https://forum.getmonero.org/22/completed-tasks/90581/monero-outreach-communication-group-coordinator-translator). Since then a lot of things have been happening throughout the community and I feel happy to keep being part of the community and contribute with love.
+
+:)
+
+Just to give you an update, I'm currently studying to be a Software Engineer so I can keep contributing to the community. I started last year on September and finished the first cycle in June. Since then I have been catching up with [Monero Outreach](https://www.monerooutreach.org/) work related and of course sharing all my life experience throughout the community. 
+
+####  What is this proposal about?
+
+Spanish localization. I have seen that the Spanish localization has literally stopped. This has been in my thoughts for a long time now.
+
+#### Who will complete the proposal?
+
+Me @lh1008. Since I first knew about Monero and the community it was a kind of falling in love feeling. Not everyone agrees with me on this, but I do have really good feelings towards the community and what Monero represents to the world. Those who know me, know I have been moderating the Spanish community since 2017. I have been building my career with Monero like a lot of us who contribute actively through the community. We have seen how the market has burned our savings, how community contributors come and go, we have suffered, we have loved each other, we have hated each other, we have tortured ourselves, etc. etc..
+
+#### Why is the proposal important for Monero and the community?
+
+This is important because Spanish has 483 million world-wide native speakers. This could help Monero reach all that audience. This is kind of a cliché phrase, but it's the truth and we have a lot of work to do to reach individuals. 
+
+This is also important because this could help level-up Spanish unfinished words for the getmonero site. This proposal is basically to have the weblate web-site section ready. This proposal could also help, for future proposals, update latest Monero content, e.g. user/developer guides, tutorials, moneropedia, etc.
+
+#### Milestones and Projected Timeline
+
+From inside the Monero Outreach I have personally started working a compensation model that has given us an important rate and a period of execution time. I went to https://translate.getmonero.org/projects/getmonero/monero-site/es/ (weblate) and as by 20 of August of 2020 this is what I found:
+
+For a total of 9,329 strings, 4,871 words have been translated. There words in red (Strings needing action - 4,458 words; Not translated strings - 3,509 words; Strings marked for edit - 949 words; Strings with any failing checks - 1,233 words), words in blue (String with suggestions - 579 words; Strings needing action without suggestions - 3,879 words), and words in yellow (Failed check: Unchanged translation - 796 words; Failed check: Trailing newline - 158 words; Failed check: Double space - 293 words; Failed check: Trailing stop - 239 words; Failed check: Trailing colon - 15 words; Failed check: Trailing exclamation - 44 words; Failed check: Mismatching line breaks - 158 words).
+
+I added up the colored words and this is what I got:
+
+- 10,149 red
+- 4,458 blue
+- 1,703 yellow
+
+Total of **16,310** words that need work.
+
+In the compensation model we have been working the following rate:
+
+**Translations**
+
+_0.1 XMR - 1000 words_
+
+**Reviews**
+
+_0.025 XMR - 1000 words_
+
+During our experience working with translations and reviews, this job could take an estimated time of **~81,55 hrs** of work.
+
+**16,310 words** / **200 translated or reviewed words/hr** = **81,55 hrs**
+
+Taking into consideration that I also do volunteered work for the Monero Outreach, I could spend 2 daily hours (5 days in a week) to help get the Spanish translation out in a period of estimated time of 2 months or less if possible (10 weekly hours).
+
+For this work, I'm asking the amount of **10 XMR** distributed like this:
+
+* Red words = For translation
+* Blue and Yellow = To be reviewed
+
+- **10,149 red words** - **1.0149 XMR** _(0.1 XMR - 1000 words)_
+- **4,458 blue words** - **0.11145 XMR** _(0.025 XMR - 1000 words)_
+- **1,703 yellow words** - **0.042575 XMR** _(0.025 XMR - 1000 words)_
+
+Total of **1.168925 XMR**
+
+For every hour of work I will ask for **0.10334106 XMR**, for a total of **8,427463443 XMR**.
+
+**0.10334106 XMR/hr** * **81,55 hrs** = **8,427463443 XMR**
+
+For a total of **9,596388443 XMR** for work and a bonus of **0,403611557 XMR**.
+
+**1.168925 XMR** + **8,427463443 XMR** + **0,403611557 XMR** = **10 XMR**
+
+This proposal is meant to last for _**2 months**_. First milestone will be _**40 hrs**_ of work for _September_ and _**40 hrs**_ of work for _October_.
+
+When these milestones are reached, I will continue with the wallets and whatever other contents that are available for translations.
+
+Thank you for your reading and time.
\ No newline at end of file

live-test.md

 ---
-layout: fr
+layout: cp
 title: Raise some XMR for the General Fund
 author: rehrar
 date: February 19, 2019
@@ -7,11 +7,11 @@ amount: 100
 milestones:
   - name: Send raised funds to the General Fund
     funds: 100 XMR
-    done:
-    status: unfinished
+    done: 6/12/19
+    status: finished
 payouts:
-  - date:
-    amount:
+  - date: 6/12/19
+    amount: 100
 ---
 
 Hey everyone, rehrar here. Just as a way to show off the CCS, and give some people a chance to try it and donate, let's raise a little money for Monero's General Fund, stewarded by the Core Team.
\ No newline at end of file

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).

m2049r-sep-nov-2018.md

+---
+layout: cp
+title: "M2049R: PART-TIME SEPTEMBER-NOVEMBER"
+author: m2049r
+date: September 21, 2018
+amount: 70
+milestones:
+  - name: Milestone 1 - Work
+    funds: 100% (70 XMR)
+    done:
+    status: finished
+payouts:
+  - date: January 3, 2019
+    amount: 70 XMR
+---
+**WHO**
+
+I am m2049r, creator of Monerujo - The Monero Android Wallet.
+
+**WHAT**
+
+I was funded March - August 2018 and would like to continue in that spirit. Please see previous posts for completed milestones & tasks.
+
+Primarily I will be moving the Monerujo App along according to our feature list on Taiga as well as improving the usability as dictated by the Monerujo Team.
+
+**HOW MUCH**
+
+12 weeks x 10 hours/week = 120 hours. @ 0.58XMR per hour = 70XMR.
+
+(June - August I spent 140 hours in addition to Ledger integration)
+
+**NEXT STEPS**
+
+*  OpenAlias support **[Released 2018-09-17]**
+*  Monero 0.13 support **[Beta 2018-10-09, Released 2018-10-14]**
+*  Automated Node discovery **[Alpha 2018-11-20]**
+*  Further Multisig Analysis & Design **[Suspended until it is clear what core GUI will do]**
+*  Talk at the HCPP18 **[Released 2018-10-07]**
+*  Continue development of Monerujo according to the Taiga Project **[ongiong, see Taige & GitHUb for details]**
+*  User Support & Bugfixing **[ongoing]**
+
+**The work for this FFS is complete, see Team Monerujo: Part-Time December-February for followup.**
\ No newline at end of file

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-spanish-translations.md

+---
+layout: cp
+title: "Subtitle translations for the videos Sound Money, Safe Mode and Monero Means Money into Spanish"
+author: michaelizer
+date: November 27, 2020
+amount: 8
+milestones:
+  - name: "Completion of Sound Money, Safe Mode (subtitles) translation into Spanish"
+    funds: 4
+    done: 31 March 2021
+    status: finished
+  - name: "Completion of Monero Means Money (subtitles) translation into Spanish"
+    funds: 4
+    done: 31 May 2021
+    status: finished
+payouts:
+  - date: 26 April 2021
+    amount: 4
+  - date: 10 June 2021
+    amount: 4
+---
+
+## What the proposal is about?
+
+Translation into Spanish of the following video subtitles: [Monero Means Money](https://translate.getmonero.org/projects/community/monero-means-money/) and [Sound Money, Safe Mode](https://translate.getmonero.org/projects/community/sound-money-safe-mode-subtitles/)
+
+
+## Who will complete the proposal?
+
+My name is Miguel Medina, I'm 26 years old Venezuelan studying Software Engeenering and a crypto enthusiast since 2017's boom and have been contributing to blokchain projects since then (as a translator), I worked as part of the translation team in a Community-led project named Utopian on [Steemit](https://steemit.com/@michaelizer), where I translated for several blockchain projects and tech projects of other nature. Also worked as part of the translation team for the [Rchain Cooperative](https://rchain.coop/).
+
+
+## Why it is important for Monero and the community?
+
+Spanish is the official language of 21 countries, is spoken by more than 500 million people around the world, the Spanish community in crypto is rapidly growing and those countries are adopting cryptocurrencies faster than others due to poor governance and payment limitations. I believe having this information translated into Spanish is very important (even more in these current period of time when blockchain is getting a lot of attention) to spread awareness of Monero through those communities.
+
+## Your milestones and projected timeline
+
+This proposal is made up of two milestones
+
+#### **1. Completion of [Sound Money, Safe Mode (subtitles)](https://translate.getmonero.org/projects/community/sound-money-safe-mode-subtitles/) translation into Spanish**
+
+It consists of a total of 12,404 words which means a total amount of 4 XMR
+
+Timeline for this milestone: Completed and reviewed.
+
+#### **2. Completion of [Monero Means Money (subtitles)](https://translate.getmonero.org/projects/community/monero-means-money/) translation into Spanish**
+
+It consists of a total of 11,689 words which means a total amount of 4 XMR
+
+Timeline for this milestone: Completed and pending review.
+
+

michaelizer-translations-into-spanish.md

+---
+layout: cp
+title:  "Spanish translation and proofreading of the monero site, GUI/CLI wallets and User Guides"
+author: michaelizer
+date: May 28, 2021
+amount: 12
+milestones:
+  - name: Milestone 1 - Translation and proofreading of the Monero site
+    funds: 33.33% (4 XMR)
+    done: 15 July 2022
+    status: finished
+  - name: Milestone 2 - Translation and proofreading of the GUI and CLI wallets
+    funds: 41.67% (5 XMR)
+    done: 15 July 2022
+    status: finished
+  - name: Milestone 3 - Translation and proofreading of the user guides
+    funds: 25% (3 XMR)
+    done: 15 July 2022
+    status: finished
+payouts:
+  - date: 23 July 2022
+    amount: 12
+---
+
+## What the proposal is about? 
+
+The purpose of this proposal is to translate what has not been translated, review what has been translated and make the necessary corrections where needed. In this way all the content uploaded to [Weblate](https://translate.getmonero.org/) would be 100% translated into Spanish.
+
+## Who will complete the proposal?
+
+My name is Miguel Medina, I've been around since November 2020 and worked on [these translations](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/223).
+
+## Files to be translated
+
+- [CLI Wallet](https://translate.getmonero.org/projects/monero/cli-wallet/es/) = 8319 words
+- [GUI Wallet](https://translate.getmonero.org/projects/monero/gui-wallet/es/) = 3770 words **
+- [Monero-site](https://translate.getmonero.org/projects/getmonero/monero-site/) = 11214 words *
+
+### And these [User Guides](https://translate.getmonero.org/projects/getmonero-user-guides/)
+
+- [Cli_wallet_daemon_isolation_qubes_whonix](https://translate.getmonero.org/projects/getmonero-user-guides/cli_wallet_daemon_isolation_qubes_whonix/es/) = 422 words **
+- [Howto_fix_stuck_funds](https://translate.getmonero.org/projects/getmonero-user-guides/howto_fix_stuck_funds/es/) = 167 words **
+- [Importing_blockchain](https://translate.getmonero.org/projects/getmonero-user-guides/importing_blockchain/es/) = 397 words
+- [Ledger-wallet-cli](https://translate.getmonero.org/projects/getmonero-user-guides/ledger-wallet-cli/es/) = 1097 words **
+- [Mine-to-pool](https://translate.getmonero.org/projects/getmonero-user-guides/mine-to-pool/es/) = 993 words
+- [Monero_tools](https://translate.getmonero.org/projects/getmonero-user-guides/monero_tools/es/) = 60 words **
+- [Monero-wallet-cli](https://translate.getmonero.org/projects/getmonero-user-guides/monero-wallet-cli/es/) = 1016 words **
+- [Node-i2p-zero](https://translate.getmonero.org/projects/getmonero-user-guides/node-i2p-zero/es/) = 430 words
+- [Offline_Backup](https://translate.getmonero.org/projects/getmonero-user-guides/offline_backup/es/) = 385 words **
+- [Prove-payment](https://translate.getmonero.org/projects/getmonero-user-guides/prove-payment/es/) = 435 words **
+- [Remote_node_gui](https://translate.getmonero.org/projects/getmonero-user-guides/remote_node_gui/es/) = 384 words
+- [Restore_account](https://translate.getmonero.org/projects/getmonero-user-guides/restore_account/es/) = 385 words **
+- [Restore_from_keys](https://translate.getmonero.org/projects/getmonero-user-guides/restore_from_keys/es/) = 302 words **
+- [Securely_purchase](https://translate.getmonero.org/projects/getmonero-user-guides/securely_purchase/es/) = 758 words
+- [solo_mine_GUI](https://translate.getmonero.org/projects/getmonero-user-guides/solo_mine_gui/es/) = 216 words **
+- [Tor_wallet](https://translate.getmonero.org/projects/getmonero-user-guides/tor_wallet/es/) = 629 words
+- [Verification-allos-advanced](https://translate.getmonero.org/projects/getmonero-user-guides/verification-allos-advanced/es/) = 1063 words **
+- [Verification-windows-beginner](https://translate.getmonero.org/projects/getmonero-user-guides/verification-windows-beginner/es/) = 1111 words **
+- [View_only](https://translate.getmonero.org/projects/getmonero-user-guides/view_only/es/) = 499 words
+- [Vps_run_node](https://translate.getmonero.org/projects/getmonero-user-guides/vps_run_node/es/) = 191 words **
+
+The ones ending in " ** " mean that they have been translated (mostly) so they only require revision to verify quality, the monero site ("*") is not fully translated and has some mistranslated parts. So, in total, there are **34243 words**, of which 12409 are not translated, 10620 fall into the category of (practically) revision only and 11214 belong to the monero site, so, given this small distinction in the type of work to be done, I propose the following:
+
+$0.1/word for those where I have to translate from scratch.
+
+$0.06/word for translating what is missing and correcting what was done wrong on the monero site.
+
+$0.06/word for those translations that have already been done but have not been reviewed. It is mostly to review them, but also to translate what is missing.
+
+(12409*$0.1) + (11214*$0.06) + (10620*$0.06) = $2551 at a rate of (+/-) $210/XMR gives a total of 12XMR divided in the following milestones
+
+### Milestone 1 - Translation and proofreading of the Monero site
+
+11214 words for a total of 4 XMR
+
+### Milestone 2 - Translation and proofreading of the GUI and CLI wallets 
+
+12089 words for a total of 5 XMR
+
+### Milestone 3 - Translation and proofreading of the User Guides 
+
+10940 words for a total of 3 XMR
+
+#### Every milestone will take about two weeks each, every update and completion will be posted in the comments
+
+
+
+
+
+
+

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.
+
+
+

midipoet-represent_Monero_at_the_Oslo_Freedom_Forum_2019.md

+---
+layout: cp
+title: Monero representation at the Oslo Freedom Forum 2019
+author: midipoet
+date: May 8, 2019
+amount: 40 XMR
+milestones:
+  - name: Book Flights and Hotel and Food
+    funds: 20 XMR
+    done: 15 May 2019
+    status: finished
+  - name: Return and deliver report
+    funds: 20 XMR
+    done: 8 June 2019
+    status: finished
+payouts:
+  - date: May 15, 2019
+    amount: 20 XMR
+  - date: June 8, 2019
+    amount: 20 XMR
+---
+
+
+**Title -** midipoet: represent Monero Outreach at [Oslo Freedom Forum 2019](https://oslofreedomforum.com/events/2019-oslo-freedom-forum)
+
+**What -** Alex Gladstein, from the [Human Rights Foundation](https://hrf.org/) had previously got in touch with Monero Outreach about the possibility of having someone at their [Oslo Freedom Forum](https://oslofreedomforum.com/events/2019-oslo-freedom-forum) event at the end of May 2019. xmrhaelan messaged me and asked would i be interested in going, as he knows i am close (europe based). I subsequently spoke with Alex on the phone, and we agreed that the event would be more of a fringe meetup/workshop, hosted by them in a semi-formal setting. It would probably be one/two hours - perhaps invite only (speakers and attendees) - and would  be a chance to talk and demonstrate Monero to a new audience. Communicating Monero’s ideology, technology, its affordances for censorship resistance, civil liberty, information and financial privacy would be the primary goal. The workshop/event would also include a section where users would start using a mobile wallet, sending and receiving Monero, understanding the backup procedure, and so on. I would also attend the OFF event as a Monero representative. Since that initial conversation we have had contact with [Blockchangers](https://www.blockchangers.com/)  who will be helping coordinate the event alongside Monero in Oslo. I believe this is a chance for some good publicity for Monero, and to also bring the technology to a new, interested, and in need audience. 
+
+**Who -** I hope a few more know me by now, but if not, hello! here is a little blurb. I have been in and around the community for a few years; slowly getting more involved as time goes on. Most of my recent interaction with the community has been through an Information Systems research project being conducted at University College Cork, Ireland. The result of this is now in the peer review process (which is a pain by the way). I will be presenting the findings of the research at Konferenco (https://monerokon.com). Get your tickets now! My latest claim to Monero fame is a talk i gave at TabConf which can be found [here](https://youtu.be/6JIz_H8irAQ). I also recently gave a talk at  at [CryptoFinance Oslo](https://www.reddit.com/r/Monero/comments/9yh9zi/cryptofinance_oslo_2018_report_by_midipoet/). Both of these trips were funded by the community, so thank you! Other than that, i would say i am just a community member and a privacy advocate. I am also a Dr (not a real one); completing my PhD in distributed music systems before shifting over to Information Systems and Financial Technology (don’t ask!). I am really just trying to stay away from the real world as long as possible.
+
+**Why -** Its kind of difficult to say no to this one, as in all honesty i think this is the exact type of event we should be trying to get exposure for Monero at.  
+
+**The Proposal and Milestones -** This is going to be difficult, but i am am going to have to ask for all expenses and costs for this one. The Human Rights Foundation are not in a position to cover anything (though they are providing the venue). This means that my flight, hotel, food expenses, printing material expenses, some food and drinks for the participants (i am thinking some simple vegetarian friendly food and some water/soft drinks), and crucially some XMR to allow people to play around with the tech all need to be covered by the community. 
+I will ask for two payouts for this. One paid out before the event, as soon as the CCS is filled. This will allow me to book flights, pay for hotels, print education material so on and so forth, and the other on my return. i think that is quite fair. I am open to discussing any and all of this proposal if people have any issues.
+
+**Expiration -** June 15th 2019
+
+**Funding details (in EURO) -**
+
+**Hotel:** €175 x 3 nights = €450
+
+**Flight:** €250 (as at 06/05/2019)
+
+**Food for me:** €50 per day for three days  = €150
+
+**Taxis/Trains/Busses/Ubers to and from airport:** €20 per day for three days  = €60
+
+**Printing Costs for Outreach material:** = €200
+
+**Food for the workshop participants:** = €500
+
+Based on an approximate XMR price of **€55 euro per XMR**, this equates to **29.27 XMR**
+
+**Monero for workshop purposes:**  = 0.1XMR per participant approx 100 participants. 10 XMR
+
+**Total Cost:** 39.27 XMR **rounded up to 40 XMR**
+
+**NB:** in a perfect world, i would like someone to be at this event with me. if the community thinks that is wise, i would like to nominate someone and then add this to the ask. I am open to discussion on all of the above. 
\ No newline at end of file

mj-compil-time-reduction.md

+---
+layout: cp
+title: Compilation time reduction and housekeeping
+author: mj
+date: April 15, 2020
+amount: 52.9
+milestones:
+  - name: ccache for CMake (demo)
+    funds: 0 XMR
+    done: 31 December 2020
+    status: finished
+  - name: Dynamic linkage
+    funds: 2% (0.9 XMR)
+    done: 31 December 2020
+    status: finished
+  - name: Automated reports of ClangBuildAnalyser and iwyy
+    funds: 4% (2 XMR)
+    done: 31 December 2020
+    status: finished
+  - name: Automated reports of Valgrind (test bottlenecks)
+    funds: 2% (1 XMR)
+    done: 20 May 2021
+    status: finished  
+  - name: Optional precompiled headers for CMake 3.16
+    funds: 4% (2 XMR)
+    done: 20 May 2021
+    status: unfinished
+  - name: Forward declarations of own classes + interfaces
+    funds: 15% (8 XMR)
+    done: moot
+    status: unfinished
+  - name: One class per header
+    funds: 4% (2 XMR)
+    done: moot
+    status: unfinished
+  - name: Parallel tests (ctest -jN)
+    funds: 9% (5 XMR)
+    done: 20 May 2021
+    status: finished
+  - name: Static methods of the wallet2
+    funds: 8% (4 XMR)
+    done: moot
+    status: unfinished
+  - name: Proper ordering of headers (general last)
+    funds: 6% (3 XMR)
+    done: moot
+    status: unfinished
+  - name: Miscellaneous hourly work @ $40/hr (23.4 XMR remaining)
+    funds: 47% (25 XMR)
+    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: 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.
+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.
+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.
+- upon a request by vtnerd, [I made the ccache optional](https://github.com/monero-project/monero/pull/6501).
+
+# Why
+During all these years I have noticed how important it is to have a quickly compilable code base, which would otherwise put a negative psychological pressure on developers, making them refrain from changing anything for the better, not to mention the obvious reduction of required computational resources.
+For Monero specifically, I have set up the following experiment:
+I have calculated the sizes of header files, summing up the sub headers included by each of them (column 3). Then I have calculated how many times a given header is included by .cpp files (column 4), thus indicating both the approximate compilation time of the header and how many .cpp files would be affected by the change if the header (column 2) and sorted ascending by this value. Below is the list of the greatest 90% of the headers, using this convention:
+
+```
+11% = 10495 = 2099 * 5:	cryptonote_boost_serialization.h	
+12% = 11907 = 1323 * 9:	wallet2_api.h	
+13% = 12393 = 4131 * 3:	cryptonote_core.h	
+13% = 12924 = 718 * 18:	crypto.h	
+16% = 14856 = 4952 * 3:	core_rpc_server.h	
+17% = 15990 = 1599 * 10: rctTypes.h	
+17% = 16500 = 3300 * 5:	blockchain_db.h	
+26% = 24225 = 8075 * 3:	blockchain.h	
+30% = 27979 = 3997 * 7:	core_rpc_server_commands_defs.h	
+61% = 56616 = 2696 * 21: cryptonote_basic.h	
+100% = 92620 = 9262 * 10: wallet2.h
+```
+
+It becomes obvious, that the wallet2.h is the largest "hot spot" of the whole project. While compilation of the project took 30 minutes, touching the wallet2.h and recompiling took entire 6 minutes = one fifth.
+
+# Milestones
+What can be done with this is creating as many wrappers of the boost library as possible and putting as much as implementation code into .cpp files, instead of insisting on writing them inline, when these spots aren't bottlenecks. Putting a trivial method as inline may help, but only when it's called very very frequently, and only if that improvement is a large percentage of other parts of the software, which it usually isn't. Inlining has to be proven by profiling the software, and not being a default policy, since it brings nothing, while costing a lot, not only because multiple recompiles of the code in .cpp files in one session, but recompiles upon changes of the inlined implementation.
+
+I'd like to earn something like 40$/h. It's hard now to assess how much time it will take, so I'm not strict on the concrete values. If I happen to finish ahead of time, thus becoming overpaid, I will admit it. I will be writing the time of work in each of my PRs.
+By assessing the payments, I will now assume a price of XMR of 125$. 
+
+
+## Milestone 1: ccache for CMake (demo)
+Done with quite a success. The Travis CI was relieved and you, as a developer benefit each time you switch a branch.
+Previous text:
+"I'd like the CMake script to automatically pick ccache and clcache, when it can find them in the PATH. This piece of software helps in reducing the compilation time of compilation units (.cpp files and all their included headers), when their content hasn't changed. This means, that the more forward declarations and fewer included headers your headers have, the more the ccache will be able to leverage your discipline. This is especially useful when switching between branches."
+
+## Milestone 2: Dynamic linkage
+Static libraries tend to grow in sizes exponentially and slow down the generation of the final binaries. I would like to enable (opt-in) dynamic linkage in CMake for development purposes. Also whenever you are done writing a new test and would like to just modify the production code and just execute the test, the test binary can be made so, that it doesn't have to relink upon change of the production code's resulting shared library.
+This is quite a low hanging fruit. There are 70 CMakeLists.txt, so multiplying each one by 2 minutes gives 2.33h plus 0.30h for creating some framework for further such changes gives 2.83h, and that equals to 0.9 XMR.
+
+## Milestone 3: Automated reports of ClangBuildAnalyser and iwyy
+Some advanced tools can be employed, that help in dynamic assessment of the quality of the code from many perspectives. For my purpose, I could use (ClangBuildAnalyzer)[https://github.com/aras-p/ClangBuildAnalyzer], which gives an objective truth about which parts of the code take longest time to compile. There's also CLang-based (Include What You Use)[https://include-what-you-use.org/] tool, which not only gives advice how to optimize the bottlenecks, but also tries to do it automatically (however it's better to use it just as a hint).
+And last but not least, there exist tools, which help finding dangerous constructs in the code, which could lead to segmentation faults at runtime.
+I'd like to use my low powered PCs to generate a daily report of the CLang tools and publish them to a dedicated webpage, that I'd manage. I will of course contribute the scripts, that generate the reports into the Monero source tree. Setting up the tools will take some time.
+
+## Milestone 4: Automated reports of Valgrind (test bottlenecks)
+Similar as above, however done weekly, since this will take more time. The context is somewhat different here however. Valgrind is able to perform performance tests, able to catch new bottlenecks by executing the tests. I think it would be benefitial, if such reports were available for the public, since their generation costs plenty of time.
+This task is somewhat easier, but I'd just like to get compensated for the power costs on this one, so I think that 1 XMR should be fair.
+
+## Milestone 5: Optional precompiled headers for latest cmake
+There will surely occur a situation, when a boost header cannot be reasonably wrapped, because it is used in a template code. Such headers are best handled by precompiled headers, reducing the compilation time by up to 50% per precompiled headed. CMake 3.16 is able to generate them natively. Since some users will still be using older versions of CMake, this has to remain optional. I will start with this one before moving the headers away, as this is a low hanging fruit, delivered by CMake devs.
+
+## Milestone 6: Moving boost headers out of own headers 1/3
+If the compilation is to be done faster, all of the 3rd party large headers have to be moved outside from our headers, thus preventing them to be propagated into files, that don't need them and waste time on parsing them. This can be done via forward declarations and careful analysis of the dependency tree.
+My such header analysis shows, that there are currently 369 occurrences of boost headers. Since each compilation costs 8.5 minutes and each change 2.5 minutes, we are at 11/60 * 369 = 67.65h of active work, excluding time of testing and verifying the speed improvement (passive work). This leaves us with 21.6 XMR for the active work. Let's round it up to 25 because of uncertainty and required passive work, as well as power costs. This forces me to split the task into 3 parts for simplicity. But as before, if I'm done earlier that I calculated, I will admit this and will report the work time for each PR.
+
+## Milestone 7: Moving boost headers out of own headers 2/3
+See milestone 6.
+
+## Milestone 8: Moving boost headers out of own headers 3/3
+See milestone 6.
+
+## Milestone 9: Forward declarations of own classes + interfaces
+It will be of a lot help, if abstractions (interfaces) were used instead of concrete implementations. Then you can easily share just the forward declarations of the unused parts of the interface for the client using the i-face, and include only these parts, which are needed. It can be achieved quite easily by creating and returning a unique pointer to an object of an implementation within a static function of the interface.
+There are 358 .cpp files, and definitely more classes than that. If I were to start from the "hottest" 50 classes first, to achieve largest results at the beggining, I'd need 20 hours, assuming 15 minutes of active work on a class and 8.5 minutes of compilation time ((8.5+15)/60 * 50 = 19.58). This would equate to 6.26 XMR. Rounding up for the power costs, let's say 7 XMR.
+
+## Milestone 10: One class per header
+It also helps reducing the probability of having to recompile a large chunk of sources, if the classes are declared one per header. Better segmentation also helps ccache reuse its cache, if there's better granularity.
+Since this is quite a mechanical work, not needing ANY analysis, I'd say 2 XMR would be enough.
+
+## Milestone 11: Parallel tests (ctest -jN)
+Did you know, that ctest allows for running the tests in parallel, just like make does? The problem is, that if they use the same resources during execution, they might (and in our case they do) affect each other. The task here would be to group the tests, which use the same resources and run them sequentially, while running other similar groups in parallel.
+I honestly haven't done any analysis on this one yet (other than proving that it doesn't work yet), as there are other things to do, that's why I'll just shoot in the dark here with 5 XMR, or could leave it for somebody else to do.
+
+## Milestone 12: Static methods of the wallet2
+I'd like to address here the problems mentioned by Endogenic (highlighted at Konferenco)[https://www.youtube.com/watch?v=AsJaMw-3gGE&feature=youtu.be&t=25614] (thanks, Scott Anecito!), namely making the wallet2 as stateless as possible. I propose here 4 XMR, as this is one of the largest classes in the whole project (if not the largest).
+
+## Milestone 13: Proper ordering of headers (general last)
+The order of writing header files is not just a matter of taste. The proper order is local first, and more generic at the bottom, because only this way you could discover hidden dependencies, that you force the client to include manually. This is nicely described (here)[https://blog.knatten.org/2010/07/01/the-order-of-include-directives-matter/] and (here)[https://stackoverflow.com/questions/2762568/c-c-include-header-file-order/2762596#2762596]
+With 358 .cpp files, this will take some time and is so mechanical, that I'd gladly leave it to an undegrad, but there were no takers for this yet.
+Shall we make it 3 XMR?
+
+
+# Expiration date
+1 Jan, 2025

mj-part-time-01.md

+---
+layout: cp
+title: mj part time coding (3 months)
+author: mj
+date: 10 Jan 2021
+amount: 64
+milestones:
+  - name: 1st-month
+    funds: 33% (21 XMR)
+    done: 13 March 2021
+    status: finished
+  - name: 2nd-month
+    funds: 33% (21 XMR)
+    done: 14 April 2021
+    status: finished
+  - name: 3rd-month
+    funds: 33% (22 XMR)
+    done: 17 May 2021
+    status: finished
+payouts:
+  - date: 15 March 2021
+    amount: 21
+  - date: 17 April 2021
+    amount: 21
+  - date: 17 May 2021
+    amount: 22
+---
+
+
+
+# What
+
+I propose to work for 3 months, spending additional 20 hours a week on Monero Core, on topics such as CI fixes, general firefighting, reviewing, and when there’s nothing left to extinguish, fixing compiler warnings and Clang-Tidy findings.
+
+
+# Who
+
+Without repeating too much info from [my previous CCS proposal](https://ccs.getmonero.org/proposals/mj-compil-time-reduction.html), I have now 13 years of experience in IT, a master’s degree in Computer Science and specialize in coding in object oriented languages and support-like tasks. This includes using specialized tools to find causes of problems, instead of relying on a gut feeling.
+
+My achievements so far, are [documented in this post](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/138#note_10583).
+
+
+# Why
+
+After starting my previous work package for Monero, I noticed, that it was hard to follow my fixed plan, because of many tasks, that were arriving in-between. These tasks were mostly CI fixes, that couldn’t have been predicted before. I see, that there’s a strong need for somebody to help fixing them while they arrive. There still exist some prevailing bugs, waiting to be fixed, like the infamous random crash (with about a 65% chance for every build) of the `functional_tests_rpc`.
+
+Another reason for my plan being delayed, is that there seems to be a lack of reviewing power. The team was also super busy doing great job with simulating and fighting off attacks on the network, but because of the lack of man power, [list of my open PRs](https://github.com/issues?q=is%3Apr+is%3Aopen+author%3Amj-xmr) stagnates and I need to spend empty hours on resolving conflicts, while other branches are being merged. I’d like to help in both of those tasks (reviewing and improving security) as much as I can, so that the hands of others are freer.
+
+Thirdly, as a partial, but already usable result of my previous CCS proposal, I started to automatically and regularly generate a report of Monero code base from various perspectives. The report is available for everybody [on this page](http://enjo.hopto.org/pub/monero/).
+
+This helped me discovering, that there’s a lot more work to do on the code base, than my fixed plan assumed. The type of work to do, shown mostly by Clang-Tidy, is a mixture of overreactions (errors of low severity) and serious memory-related bugs, that either sporadically crash the application already or could crash it in the future, when some yet untested parameter combinations are to be used.
+
+
+# Proposal
+
+Realistically I am able to spend 20 hours a week more on the project. If the Community wishes to "hire" me for the mentioned perpetual tasks (not covered by my first proposal), then I’ll arrange it accordingly with my job. The previous proposal is still in place, but for reasons not related to me, it can’t move at the pace, that I initially intended. I’d like to oil this machine in all possible ways.
+
+I propose a wage of 40 $/h for 3 months. The XMR/USD as of 10.01.2021 is at around 150 $. This would make a total of:
+40 ($/h) *  20 (h/week) * 4 (weeks) * 3 (months) / 150 (XMR/USD) = 64 XMR.
+
+Cheers!

mj-part-time-2021-q3.md

+---
+layout: cp
+title: mj part time coding Q3 2021
+author: mj
+date: 30 June 2021
+amount: 45 XMR
+milestones:
+  - name: Month 1
+    funds: 15 XMR
+    done: 1 August 2021
+    status: finished
+  - name: Month 2
+    funds: 15 XMR
+    done: 5 September 2021
+    status: finished
+  - name: Month 3
+    funds: 15 XMR
+    done: 10 October 2021
+    status: finished
+payouts:
+  - date: 6 August 2021
+    amount: 15
+  - date: 10 September 2021
+    amount: 15
+  - date: 11 October 2021
+    amount: 15
+---
+
+
+# What
+
+In the same way as previously, I propose to work for 3 months, spending additional 20 hours a week on Monero Core, specifically on topics such as:
+- CI fixes
+- code reviews
+- addressing user issues (whenever I can help)
+- enabling new developers to submit their patches quicker
+- extending my [Monero health report](http://enjo.hopto.org/pub/monero/)
+- general firefighting, whatever problems we face in near future
+
+When there’s nothing left to extinguish, I'll be fixing compiler warnings and Clang-Tidy findings. Last time, there was so much other work, that I didn’t really even reach this topic, except for compiler warnings.
+
+# Why
+
+During preparation of my last such quarterly proposal, I noticed quite annoying nondeterministic CI failures, that I was able to fix, thanks to your funding and the Team's cooperation through reviews and integration. Please make your own opinion on how valuable my changes were. Due to the lack of a better measure, I propose comparing the number of pages of failed builds per month before and [after](https://github.com/monero-project/monero/actions?page=3&query=is%3Afailure) merging my change on the 30th March. In short, there are only 3 such pages in recent 2 months after, while the previous 2 months, before merging, marked a many as 7 such pages, until [here](https://github.com/monero-project/monero/actions?page=10&query=is%3Afailure)
+
+The ability of improving this weak point of the development process gave me a lot of hope, that the somewhat disruptive, but positive changes are accepted, therefore the development will not come to a halt at some point. I'd like to continue working on such project and bring other similar improvements.
+
+
+The details of the already identified work packages are the following:
+
+## CI
+- In the CI there's still an unresolved issue of FreeBSD not using ccache, thus taking unnecessary time for recompilations. This was left alone, due to the fact, that it's not a critical matter. However having this solved would be a cherry on top of the Monero's CI. I can't promise that it will be possible to fix and I haven't had time yet to look into it in detail, but I do know how to analyze such errors.
+- Recently I noticed, that Unit Tests fail under Mac OSX. It wouldn't hurt to run only the UTs under OSX as one of the CI steps, as they cost only 10 minutes of processing time. Fixing the UTs would also be part of my job here.
+- The CI could use a matrix of all the supported Boost library versions. As [discovered here](https://github.com/monero-project/monero/pull/7735), changes of the boost headers need to be handled with caution, in order not to introduce compilation regressions across still unchecked Boost versions. This is what a CI is for. 
+
+## Enabling new devs
+- The efficient compilation and debugging document, whose value you can measure via [this link](https://github.com/monero-project/monero/blob/master/docs/COMPILING_DEBUGGING_TESTING.md), is where the new developers could read, in order to learn faster how to integrate their patches, avoiding a steep learning curve and waiting times. This document will be continuously extended with setups for various IDEs and other such findings
+- I need to continue the automation of adding all the headers to the IDEs' project files. Both the missing ones and those to be added in the future. The framework for this is already prepared. What's left is some monkey business of simply identifying the gaps and using the framework. Nothing hard, but time consuming. Having this level of order in the IDEs leads to a great reduction of confusion for developers while they change header files.
+
+## Health report
+- I extended my [Monero health report](http://enjo.hopto.org/pub/monero/) with the lcov report lately (Line coverage of tests), but didn't have the time to really integrate the report generation into Monero itself. I only do it locally. Therefore other devs can't generate such a report for themselves yet. The script would be a perfect fit to the collection of other health-related tools in Monero.
+- I have some other handy source analysis tools, that go in the direction of Include What You use, but are not that dependency heavy and deliver less noise. This means, that everybody can run such an evaluation on almost no-time, while the other Clang-based tools take about 1,5 hour each, however complete they are.
+- both of the above scripts, although serve their purpose, are not production ready from the code quality perspective, so I myself wouldn't want to merge this into the official repo in their current preliminary state. This needs some focused work now.
+
+## Small issues
+Some small things that I've flagged as reminders for now:
+- [Adding regression tests](https://github.com/monero-project/monero/issues/7756)
+- [Addressing previous PR comments for documentation](https://github.com/monero-project/monero/issues/7755)
+
+# Previous reports
+I'm sure you've either already read them or simply found them too long anyway, so I'll just link here 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)
+ 
+# Proposal
+
+I am able to realistically spend 20 hours a week more on Monero, additionally to my compilation time reduction efforts, which move at a slow pace. I will start not sooner than from the middle of June, due to current personal workload.
+
+I propose a wage of 40 $/h for 3 months. As of 30.06.2021 (1 day before Q3) the XMR/USD is at around 217 $. This would make a total of:
+40 $/h * 20 h/week * 4 weeks * 3 months / 217 XMR/USD ~ 45 XMR. (3 times 15 XMR)
+
+Cheers!
+
+
+# Expiration date
+15 Sep, 2021

mj-part-time-2021-q4.md

+---
+layout: cp
+title: mj part time coding Q4 2021
+author: mj
+date: Oct 20, 2021
+amount: 72.0 XMR
+milestones:
+  - name: Month 1
+    funds: 24.0 XMR
+    done: 30 November 2021
+    status: finished
+  - name: Month 2
+    funds: 24.0 XMR
+    done: 31 December 2021
+    status: finished
+  - name: Month 3
+    funds: 24.0 XMR
+    done: 29 January 2022
+    status: finished
+payouts:
+  - date: 4 December 2021
+    amount: 24
+  - date: 5 Jan 2022
+    amount: 24
+  - date: 26 February 2022
+    amount: 24
+---
+
+
+# What
+
+In the same way as previously, I propose to work for 3 months, spending 30 hours a week on Monero Core, specifically on topics such as (in this order):
+- statistical simulation (see [Proposal](#Proposal))
+- addressing user issues (whenever I can help)
+- enabling and helping new developers
+- code reviews
+- CI fixes
+- 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
+
+I need to raise the stakes unfortunately, since I'm strongly considering ditching my job, which became a pain in my back. This means, that I will be more dependent on the XMR money. Also, since I live in Western Europe, I pay my bills in EUR, which is seemingly going down against USD in a long term trend.
+I normally hate hearing from people, who I have to hire to do things, which they can do better than me, that "they Have to earn more". I prefer saying first what additional stuff I'll deliver. Since my job will not get into the way as it did before, I will have more mental capacity to learn and read about the internals of Monero (outside of the proposed 30h/w). So far I've been doing (and gaining experience in) a lot of support tasks and I'm happy with the results as far as they can be reviewed and merged by the Maintainers. However there are now also some new challenges in Monero, which deal with statistics. I have some self-taught knowledge the field and I could provide some time series simulations, that would help in verifying if a given statistician's (or my) solution is able to yield the expected results in multiple alternative scenarios, as opposed to relying on a fixed history, which always leads to [overfitting](https://en.wikipedia.org/wiki/Overfitting). Please refer to the wonderful work of [Nassim Nicholas Taleb](https://en.wikipedia.org/wiki/Nassim_Nicholas_Taleb), especially [Fooled by Randomness](https://en.wikipedia.org/wiki/Fooled_by_Randomness) for more background. I already have a working software for such simulations, but it has to be adapted to fit Monero. I'd gladly reuse it for you guys, while you'd only pay for the adaptation itself. I think it's a good deal. I've been working on this software for many years for the purpose of statistical analysis of financial data, and a huge amount of them.
+
+
+Some more details and summaries of other work packages are below:
+
+## Statistical simulator
+
+Here are the most relevant features of the simulator, that I'd adapt for Monero:
+
+- Parallel Monte-Carlo simulation of alternative scenarios. The result of such a simulation are median and standard deviation of all experiments (in other words: the expected value as well as best and worst case scenario)
+- The resulting value(s) are of a unit, defined by whatever objective function that is being fed into the simulator. In my current case of the financial simulation, it's the trading profitability.
+- Smooth interfacing with Python (either via Boost or TCP), as Python is the (reasonable) language of choice for Statisticians. This means, that the Statisticians will not have to immediately rewrite their code to C++, if they want to have them checked by a very fast C++ simulator, compared to an analogous task, performed by Python code.
+- Very fast loading of serialized data
+
+The current visuals of my simulator can be seen below:
+
+### Visualization
+
+The visualization allows to take a closer look at what happens on the lowest level:
+
+![QT](http://cryptog.hopto.org/monero/sim/sim-qt.png)
+
+### Configuration
+
+The current configuration UI, which produces serializable configuration files:
+
+![Cfg](http://cryptog.hopto.org/monero/sim/sim-config.png)
+
+### Evaluation
+
+A console program, which performs the evaluation on larger data in parallel and joins them, plotting the result in the console:
+
+![Test](http://cryptog.hopto.org/monero/sim/sim-test.png)
+
+### Reporting
+
+An HTML report is being generated after each evaluation. Here's how it currently looks:
+
+A compound report, like in the console evaluation:
+![Rep1](http://cryptog.hopto.org/monero/sim/sim-report-whole.png)
+
+An individual report for each component:
+![Rep2](http://cryptog.hopto.org/monero/sim/sim-report-indiv.png)
+
+## CI
+Me and the team were able to fix the prevailing [FreeBSD ccache issue](https://github.com/monero-project/monero/pull/7832). I also [separated the caches](https://github.com/monero-project/monero/pull/7780) based on how often they have to be recreated, which in turn saved space, so that GitHub doesn't have to purge them as often as before. All this together lead to a lot quicker reactions.
+I don't see a potential for improvements of the CI anymore, which makes me happy. We can work relatively efficiently now, offsetting a lot of testing onto the CI without having to wait for a long time, nor having a bad feeling about abusing the service.
+However, as soon as an unpredictable problem appears on the CI, I'm ready to address it.
+
+## Enabling new devs
+I helped in adaptation of Monero for RPi4 in the last month. I found it encouraging to work with people, who know what they want and are able to react lively. I spent some time on introducing new devs into the project, but somehow they gave up. OTOH, many new Monero devs, who didn't give up, to say the least, often message me privately with C++ questions, that I'm always happy to answer. I'd bet a lot of XMR, that it saves them a lot of frustration and time of own research. I'll happily keep doing it all.
+
+## Health report
+- I extended my [Monero health report](http://enjo.hopto.org/pub/monero/) with the Memory consumption (for compilation) report lately uncovering a huge RAM consumption of source files like `wallet2.cpp`. [See here](http://cryptog.hopto.org/monero/health/data/753dc901a/753dc901a-mem-usage-prod.txt).
+- The report will be extended to cover Monero-GUI
+- I will keep adding next tools into Monero codebase itself, whenever I decide, that they will have reached a production-ready state
+
+# Who
+
+mj, I have been contributing to Monero-core since 2020 with 73 merged commits. Here is a list of my previous work:
+
+CLI contributions: https://github.com/pulls?q=is%3Apr+author%3Amj-xmr+archived%3Afalse+is%3Amerged+
+
+## 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 05](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/231#note_11248)
+- [Report 06](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/231#note_11421)
+- [Report 07](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/231#note_11662)
+
+Previous CCS: https://ccs.getmonero.org/proposals/mj-part-time-2021-q3.html
+
+
+# Proposal
+
+In Q4, I am able to realistically spend 30 hours a week on Monero. I arranged everything so, that the Q4 and January will be easy on me, so I won't have to prolong the work (and payment) like I had to do it in Q3. I'd like to start in November.
+
+I propose a wage of 45 €/h for 3 months. As of 20.10.2021 the XMR/EUR is at around 220 €. This would make a total of:
+45 €/h * 30 h/week * 4 weeks * 3 months / 220 XMR/EUR = 73.6 XMR, rounded down to be divisible = 72 XMR
+
+Cheers!
+
+
+# Expiration date
+31 Jan, 2022

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-defcon-27-supplies.md

+---
+layout: cp
+title: Monero Defcon 27 Supplies
+author: ajs
+date: May 22, 2019
+amount: 73
+milestones:
+  - name: contract storage space 
+    funds: 9 XMR
+    done: June 18, 2019
+    status: finished
+  - name: purchase supplies
+    funds: 17 XMR
+    done: June 18, 2019
+    status: finished
+  - name: bring last year supplies
+    funds: 1 XMR
+    done: June 18, 2019
+    status: finished
+  - name: donate extra to General Fund
+    funds: 46 XMR
+    done: June 18, 2019
+    status: finished
+payouts:
+  - date: June 18, 2019
+    amount: 27 XMR
+  - date: June 18, 2019
+    amount: 46 XMR
+---
+
+### Update
+
+Milestones and payouts have changed: https://www.reddit.com/r/Monero/comments/c1stli/status_update_defcon_av_supplies_ccs/
+
+
+### What
+
+Last year the people at Defcon were nice enough to provide us Audio/Video recording for our village, however the quality could have been better as can be seen from the videos here:
+
+- https://www.youtube.com/watch?v=9SuzXZj9FIk
+- https://www.youtube.com/watch?v=LjM3GTBaUvo
+- https://www.youtube.com/watch?v=SAzYkg3wuHs
+
+#### Why did the video suck and how can it be improved?
+
+The main problem with the video quality was lighting. The ISO might have been set too high causing a grainy image with lots of noise. The proposed solution is to use a LED lighting to help lower the ISO and properly light the subject from different angles. I plan to rent a Promaster LED1000B Specialist LED 2 Light Transport Kit from [B&C Camera](https://store.bandccamera.com/pages/rentals).
+
+Another problem with the video, was audio. To improve it, I will rent a Zoom H5 Handy Recorder to record the sound directly from the mixer. After Defcon, I'll import the audio and edit the videos with [Shotcut](https://shotcut.org). In post-production, I'm going to blur the faces of attendees if recorded by accident to protect their privacy. I will then upload the videos to Youtube. This work will be done on an unpaid basis.
+
+In addition, I plan to set up a live video stream with [Elgato Cam Link 4K](https://www.amazon.com/dp/B07K3FN5MR/?coliid=I3V4ALDHDY46MO&colid=33LDRRB08T8TY) and [OBS](https://obsproject.com). The video link will be embedded directly in the [Monero village website](http://monerovillage.org). Stream will be broadcast in 720p/60 fps format and will connect to a [HDMI Switch](https://www.amazon.com/dp/B07GGT7SZD/?coliid=I3M2DJMM8AR4VC&colid=33LDRRB08T8TY) to have 3 feeds to switch from live (projector, [camcorder A](https://www.amazon.com/dp/B07QJ7VPD4/?coliid=IX1PEBMAZGHIA&colid=33LDRRB08T8TY), camcorder B).
+
+The video set up will be as follows:
+
+![video schematic](https://taiga.getmonero.org/media/attachments/6/e/e/c/f98fe471f64647eca9448b805b9f962421f243cf952de69e50dba0da498b/defcon27_video.png)
+
+#### The PA system
+
+Last year, we didn't have a PA system for the first few talks due to difficulties in coordinating with goons. Defcon can be hectic and it is hard getting in contact with the right people. They were able to eventually help us get one set up. It would be much better to have our own PA system set up before the talks. I suggest getting this [Rockville Package PA System](https://www.amazon.com/dp/B01MQMQ53X/?coliid=I2KJ3EO3YN78UM&colid=33LDRRB08T8TY).
+
+The audio set up will be as follows:
+
+![audio schematic](https://taiga.getmonero.org/media/attachments/8/8/8/c/3517ffb2d2bbee898a9be5401f790a5fd8b0defb5b026135ff30797d935b/defcon27.jpg)
+
+#### How do you plan to store all this stuff after Defcon?
+
+Last year, the community [funded the purchase of supplies](https://forum.getmonero.org/8/funding-required/90538/monero-defcon-26-supplies) and a member that lives in Las Vegas helped with receiving packages (an inventory of what we have can be viewed [here](https://taiga.getmonero.org/media/attachments/8/2/2/8/9df754fad4c3c2be89abd76f6bb617b77471219f01950b407f957871231c/inventory.ods)). After Defcon, I packed all the supplies and banners in a large duffle bag and checked in the luggage for my trip back home. I kept the bag in a garage and will take it with me back to Las Vegas this year. If we fund the purchase of Audio/Video equipment, it is not practical to fly stuff back and forth.
+
+I propose leasing a space in Las Vegas in a climate-controlled warehouse. I've received a quote from a logistics company that specializes in expos. We will be able to ship supplies from Amazon directly to the company for storage. A community member plans to rent a SUV during Defcon and has offered to help transport between the warehouse to hotel and back. 
+
+### Who
+
+ I am ajs. I've co-authored the scripts for the [Monero explainer videos](https://github.com/monero-ecosystem/promo-video) and volunteered last year to help with Defcon badges, supplies, and communications direction. This year, I will be response for A/V activities, communications direction, and logistics delivery.
+
+### Proposal & Milestones
+
+- Sign storage lease (1 year, includes package handling charges) - June 15, 2019 ($800)
+- Purchase [A/V equipment](https://taiga.getmonero.org/media/attachments/3/1/0/2/4140a3930a080ed9a68d5da1803e772719346e1dfddbeac656731dd2c3a1/amazon3.pdf) - July 1, 2019 ($1,128.22)
+- Oversized checked baggage (last year's supplies and banners) - August 5, 2019 ($100)
+- Rental equipment August 6, 2019 ($524.56)
+
+```
+Promaster LED1000B Specialist LED 2 Light Transport Kit - Bi-Color
+Qty: 7 Days @ $17.14
+$120.00
+Deposit $300.00
+
+Canon EOS 5D Mark IV Body
+Qty: 7 Days @ $40.71
+$285.00
+Deposit $3000.00
+
+Canon EF 50mm f/1.8 STM
+Qty: 7 Days @ $4.29 
+$30.00
+Deposit $50.00
+
+Benro Mach 3 Legs with Manfrotto MHXPRO-2W 2-Way Pan/Tilt Head
+Qty: 7 Days @ $4.29
+$30.00 
+Deposit $100.00
+
+Canon LP-E6N Battery
+Qty: 7 Days @ $2.14 
+$15.00
+Deposit: $50.00
+
+Zoom H5 Handy Recorder with Interchangeable Microphone System
+Qty: 7 Days @ $8.57
+$60.00
+Deposit: $100.00
+
+Sub-Total:  $480.00
+Tax (8.25%):  $44.55
+Total (USD):  $524.56
+```
+
+Total cost: $2,552.78
+Security deposit: $3,600 (deposit will be returned to core team after the event and saved for next year's rentals)
+Exchange estimate of 1 XMR = 85 USD
+
+## Grand Total: 73 XMR

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.