SNeedlewoods-02_part-time-dev-work.md

+---
+layout: wip
+title: SNeedlewoods-02_part-time dev work
+author: SNeedlewooods
+date: January 27, 2025
+amount: 23
+milestones:
+  - name: M1 - Harden sensitive material in the Wallet API
+    funds: 2.4
+    done:
+    status: unfinished
+  - name: M2 - Replace wallet2 with Wallet API in simplewallet
+    funds: 20.6
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+## What?
+
+Since the feature-complete Wallet API [PR](https://github.com/monero-project/monero/pull/9464) from my previous CCS proposal is finally in "pending review" state (I will give my best to quickly resolve issues coming up during the review, so it hopefully will get merged soon), it's time for the next steps:
+- Harden handling of sensitive material in the Wallet API (Discussions: [#1](https://github.com/monero-project/monero-gui/issues/1537), [#2](https://github.com/feather-wallet/feather/issues/72#issuecomment-1405602142), [#3](https://github.com/monero-project/monero/pull/8619#issuecomment-1632951461)).
+- Replace wallet2 with the Wallet API in simplewallet as proposed [here](https://github.com/seraphis-migration/wallet3/issues/64) in step 2 by @j-berman.
+
+I'll try to spend at least 12 h/week coding.
+
+
+## Who?
+
+This is my second proposal, the previous one can be found here:
+
+- [Proposal 1](https://ccs.getmonero.org/proposals/SNeedlewoods-01_part-time-dev-work-1-month.html)
+
+
+## Milestone
+
+(Disclaimer: I can't promise the estimated times are accurate, but I tried to keep them low and I'll take the risk if a milestone takes longer to complete.)
+
+1. M1 (2.4 XMR): PR to harden handling of sensitive material in the Wallet API is merged to monero-project/monero
+   - Stop caching the password (in Wallet API and GUI)
+   - Use `epee::wipeable_string` instead of `std::string` for secret keys
+   I estimate this can be completed in ~ 2 weeks, which makes:
+   12 (h/week) * 2 (weeks) = 24 (h total M1).
+
+2. M2 (20.6 XMR): PR to replace wallet2 with the Wallet API in simplewallet is merged to monero-project/monero
+   I estimate this can be completed in ~ 4 months, which makes:
+   12 (h/week) * 4.3 (weeks/month) * 4 (months) = 206.4 (h total M2).
+
+
+## Payment
+
+I am setting my rate at 0.1 (XMR/h) regardless of fiat market price (but for reference, that is roughly around 20,50€ or $21.50 per hour, according to the current 7-day range on coingecko: 195,68€-217,73€ or $202.95-$226.65).
+
+M1: 24 (h) * 0.1 (XMR/h) = 2.4 (XMR).
+M2: 206.4 (h) * 0.1 (XMR/h) = 20.64 (XMR).
+
+That makes for a (rounded) total of:
+2.4 (XMR) + 20.64 (XMR) = 23 (XMR total).

The-Monero-Moon-CCS-Proposal-March2022-John-Foss.md

+---
+layout: cp
+title: Funding for The Monero Moon Newsletter - 2022
+author: John Foss
+date: March 2, 2022
+amount: 36
+milestones:
+  - name: Publish issues #34 through #39
+    funds: 12 XMR
+    done: 21 April 2022
+    status: finished
+  - name: Publish issues #40 through #45
+    funds: 12 XMR
+    done: 2 June 2022
+    status: finished
+  - name: Publish issues #46 through #51
+    funds: 12 XMR
+    done: 21 July 2022
+    status: finished
+payouts:
+  - date: 1 September 2022
+    amount: 36
+---
+
+THE MONERO MOON NEWSLETTER - Funding
+
+WHAT: The Monero Moon is a free weekly news publication created in 2018 in an effort to keep the Monero community up to date on all the latest news and developments related to Monero. I aim to achieve this by aggregating all the relevant information into one convenient location in an easy-to-digest format. I sift through the noise so you don’t have to. I also endeavour to cross promote other Monero initiatives as much as possible, while also encouraging others to participate in or support the Monero project.
+
+The Monero Moon is independently published by myself on Medium. I have already published 32  issues. View previous issues 1-32 here. I am in the middle of trialling different newsletter platforms such as Ghost and Substack, however am yet to make the switch to a different platform. 
+
+Weekly readership has been varied, and it has appeared that readership increases the more social media promotion gains traction.
+
+Issues from 2018 regularly had on avg 1.5k views per issue, and issues #12 to #32 have averaged 1.2k views per issue. The number of views appeared to be correlated to the price of XMR, meaning the higher the price or the more upwards trajectory the price showed correlated to view count. The most views a single issue has received was approximately 2.5k views (issues #22 & #27) 
+
+WHO: I am John Foss. Like many of you, I am a firm believer and supporter of the Monero Project. I have previously written Monero articles on Medium, a couple of How To Buy Monero Guides for the Monero.How website, and wrote Your Guide to Monero, and Why It Has Great Potential back in 2018 which I posted to r/cryptocurrency and had over 25k views and received 1.5k upvotes. Besides that, I have been following Monero for a fair while now, generally hanging out on r/xmrtrader and Twitter, and I also occasionally venture over to the IRC channels.
+
+WHY: As Monero continues its journey, I believe it is extremely important for everyone (community members and outsiders looking in) to be able to closely follow along with all the latest news and developments surrounding Monero, whether it's the latest community update from the developers, or if Monero was featured in a large media publication. And I believe The Monero Moon will help bridge that gap. I believe that the Monero Moon will be extremely beneficial for the growth and adoption of Monero as the newsletter will continue to help spread awareness.
+
+THE PROPOSAL AND MILESTONES: As stated in my previous CCS, as Monero grows in popularity, it takes more and more time to put together an issue from start to finish. It currently takes me about 10 hours of work per issue. This involves me researching and collating the information, writing it up, then publishing and promoting it via social media platforms.
+
+I am proposing to publish The Monero Moon for 2 XMR per issue from 16th of March until late July 2022, or whenever the CCS is complete. At the current exchange rate of approximately $163USD per XMR based on the 20 day moving average, that comes out to ~$346 per issue which I believe is fair compensation. For example, 1000 readers is equivalent to ~0.34c per read. The milestones are straightforward, for every 6 issues I publish, payment is released. This comes out to 3 milestones in total.
+
+Milestone 1: Publish issues #34 through #39 - 12 XMR 
+Milestone 2: Publish issues #40 through #45 - 12 XMR 
+Milestone 3: Publish issues #46 through #51 - 12 XMR
+
+There may be periods where I miss a week due to life commitments, however I will endeavour to cover all the recent news in one big bumper newsletter issues, and this will still just count as one issue. The newsletter issues will carry on from previous publications. Additionally, at the end of this period of 18 issues published I will re-evaluate whether I shall continue the newsletter.
+
+Cheers, 
+John Foss
+
+

Translation-getmonero-german.md

 ---
-layout: wip
+layout: cp
 title: Translation of the Moneropedia and User Guides into German
 author: Wobole
 date: September 10, 2020
@@ -11,13 +11,13 @@ milestones:
     status: finished
   - name: Translation of the User Guides
     funds: 19.9
-    done:
-    status: unfinished
+    done: 8 February 2021
+    status: finished
 payouts:
   - date: 12 December 2020
     amount: 8.6
-  - date:
-    amount:
+  - date: 15 February 2021
+    amount: 19.9
 ---
 
 
@@ -42,4 +42,4 @@ For the compensation of words counted by my program which actually aren’t supp
 
 I am giving my best to deliver a high quality translation – not least because I am an apologist of correct orthography and grammar. If this proposal gets funded, I will start to work on the translations immediately; I am expecting to finish the milestones in two months.
 
-Thank you for reading!
\ No newline at end of file
+Thank you for reading!

VOSTOEMISIO-Continuation-of-Core-Monero-Concepts-A-Series-of-Animated-Explainers.md

+---
+layout: cp
+title: Continuation of Core Monero Concepts - A Series of Animated Explainers
+author: VOSTOEMISIO
+date: October 3, 2023
+amount: 37
+milestones:
+  - name: Random X and Understanding the significance of ASIC resistance
+    funds: 18
+    done: 26 June 2024
+    status: finished
+  - name: Nodes and why every Monero enthusiast should consider running one.
+    funds: 18
+    done: 8 April 2024
+    status: unfinished
+payouts:
+  - date: 30 April 2024
+    amount: 18
+  - date: 16 July 2024
+    amount: 18
+---
+
+_Note: this proposal has been awarded 36 XMR from [New Animated Videos](https://ccs.getmonero.org/proposals/savandra-videos-for-monero.html)_
+
+Hey all!
+
+Thank you for the amazing reception and feedback of our first ccs-proposal and the Tail Emission video. We've seen a lot of excitement and engagement with over 7,000 accumulated views in just the initial days.
+
+Our vision is to keep diving deeper into Monero's complex and sometimes tricky and misunderstood features, translating them into short, engaging, and most importantly, understandable animated videos. Here's what we suggest to cover in this proposal:
+
+• Random X: Understanding the significance of ASIC resistance
+
+• Breaking down the how-to and the rationale for P2Pool.
+
+• Nodes: Why every Monero enthusiast should consider running one.
+
+• Fungibility: Explaining its essence in the context of Monero.
+
+Quality & Timeline: 
+
+As we've showcased in our recent work, we promise high-quality output, similar to our Tail Emission video ( https://youtu.be/sRwSqM0YBto?si=vAFA7iRUWAvaV5Wi ). In this proposal, we are committing to an accelerated timeline and we aim to finalize and release one video per month. Therefore, we aim to wrap up the entire series in just 4 months after proposal’s approval. However, acknowledging the potential for unforeseen challenges, we request an additional 2 months as a buffer, making the total proposed timeline 6 months. We estimate each video to be approximately 2 minutes in length.
+
+Budget & Collaboration: 
+
+Given the scope, we propose 18 XMR per video, a total of 72 XMR for the entire series, broken down across milestones. As with our first video, we will collaborate with Xenu, sharing 5 XMR per video of the funds with him. This collaboration ensures the technical soundness of our scripts and storyboards, guaranteeing that each video is not only engaging but also accurate. As always, we are open to adjustments based on feedback and the evolving requirements of the project.
+
+Open Source & Community:
+
+Post-completion, all materials and animations will be open-sourced for the community's further use and reference.
+We're eager to dive deep and clarify these essential Monero concepts with everyone. Your feedback, suggestions, and enthusiasm drive us, and we're all ears for what you have to say.
+
+//VOSTO
+
+ www.vostoemisio.com
+
+2CA8 85AC 923F 07A3 3656 8425 83F1 9CFF 27BE A177
+
+

VOSTOEMISIO-FCMP-Animated-Explainer.md

+---
+layout: cp
+title: "VOSTOEMISIO - FCMP Animated Explainer Video"
+author: VOSTOEMISIO
+date: July 29, 2024
+amount: 20
+milestones:
+  - name: Complete FCMP Video
+    funds: 20
+    done: 16 December 2024
+    status: finished
+payouts:
+  - date: 13 January 2025
+    amount: 20
+---
+
+Hey Everyone,
+
+We are happy to inform you that we have already received private funding for the introductory
+Monero video, and therefore, we have adjusted the proposal accordingly.
+After receiving the community’s feedback, we're now excited to present our revised proposal:
+one explainer video about FCMP (Full-Chain Membership Proofs). This will be our 4th video for
+the Monero CCS.
+
+Our previous videos covering core Monero concepts like Tail Emission, the importance of
+running a node, and RandomX have been informative, engaging, and uploaded on
+Getmonero.org, shared across X and YouTube. We believe that visual learning and breaking
+down complex ideas into digestible formats is highly effective, and we aim to do the same with
+FCMP.
+
+References:
+1. [Youtube - Monero's Tail Emission](https://youtu.be/vjn9l3hG4ME)
+2. [Youtube - Monero Nodes](https://youtu.be/hM6TF3co7lI)
+3. [Youtube - Monero's RandomX](https://youtu.be/RsNOi0lpiyM)
+
+Although we haven't finalized the script yet for the FCMP video, we're committed to delivering a
+high-quality video approximately 2-3 minutes long, or however long it needs to be to effectively
+explain the concept. We're proposing a budget of 20 XMR for this video. This is slightly higher
+than our initial proposal since we agreed to extend the scope to include both dark and light
+backgrounds. As before, Xenu will assist with the script and storyboard, with 5 XMR allocated
+for his contribution. Additionally, we've reached out to kayabaNerve (Luke Parker) for
+fact-checking the script to ensure accuracy, and he's agreed to help us. A big thanks to him for
+his support.
+
+As always, we will open-source our project materials after completion.
+We believe we've done a good job of gathering the community's feedback so far in our previous
+proposals, and we'll continue to do so by posting our script and storyboards on Matrix and here
+in the repo.
+
+If anyone has any questions or suggestions, please feel free to chime in.
+
+Thanks!

VOSTOEMISIO-TailEmission-Concept-Video.md

+---
+layout: cp
+title: VostoEmisio Animated Tail Emission Core Concept Video
+author: VOSTOEMISIO
+date: May 12, 2023
+amount: 9
+milestones:
+  - name: Complete Script
+    funds: 3
+    done: 26 September 2023
+    status: finished
+  - name: Complete Look and feel
+    funds: 3
+    done: 26 September 2023
+    status: finished
+  - name: Complete Video
+    funds: 3
+    done: 26 September 2023
+    status: finished
+payouts:
+  - date: 6 November 2023
+    amount: 9
+---
+
+Hey everyone!
+
+Since this is my first CCS proposal, I thought I'd give you a quick intro to who we are:
+
+I run a marketing company in the traditional space. Here, we work under the name "VostoEmisio,". We've already done some work for Monero and other privacy-centric projects. Our journey began in early 2022 when we helped Rucknium revamp the logo and branding for these two projects:
+https://bchmempool.cash/
+https://beta.redteam.cash/
+
+This year, we won the Monerokon 3 Design Proposal (www.monerokon.com), and we're currently working on brand refreshing and marketing for Firo: https://forum.firo.org/t/fcs-proposal-firo-3-month-trial-marketing-contract/2905/4
+
+However, we haven't had the chance to show off our skills in motion assets and animation yet. As a long-time Monero user, I find it frustrating when browsing crypto-Twitter and seeing basic misconceptions like "infinite supply," "can't scale," and "dynamic block size???" still being spread, particularly by the uninformed "BTC maxis."
+
+So, I propose that we create an animation series featuring short (1 min or so), ELI5-style explainer videos that break down the key concepts of how Monero works in a simple and digestible way that could easily be shared every time we, the community, face misleading comments. I suggest we start with one video and, if the result is satisfactory, create more based on the community's preferred topics.
+
+### Promise and assurances:
+
+- With the budget for this proposal, we're confident we can deliver quality on par with this example: https://www.youtube.com/watch?v=pYOSfEgF32Y&ab_channel=XPLAI
+- Completion expiry date set to 4 months post-approval for this proposal
+- Open-sourcing the project materials after completion
+
+If that sounds good to you all, I'd be happy to jump into the details and start working on the script and storyboard. I would like to start with ( as our name vosto emisio also springs from), the tail emission concept. 
+
+Regarding the budget, we're not sure, but we're willing to try this out for 9 XMR for the first video. We can adjust the amount up or down after we see how the first project goes since this would be our first official collaboration with the community. I believe this project will take about a month to complete, maybe a bit longer since this is our first time working with the community.
+
+Any questions or thoughts?
+
+
+    

acx-monfluo-maintenance-and-further-development.md

+---
+layout: wip
+title: acx part-time work on Monfluo (3 months)
+author: acx
+date: February 28, 2025
+amount: 13.98
+milestones:
+  - name: Month 1
+    funds: 4.66 XMR
+    done:
+    status: unfinished
+  - name: Month 2
+    funds: 4.66 XMR
+    done:
+    status: unfinished
+  - name: Month 3
+    funds: 4.66 XMR
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+## Who
+
+Hi, I am acx.  
+About six months ago I have forked Mysu (an abandoned Android wallet) and continued its development and maintenance.  
+The fork is named Monfluo and is available [here](https://codeberg.org/acx/monfluo)  
+
+Since starting the fork, I did (among other things) the following:  
+
+* Implemented multi-wallet functionality (also wallet renames and deletion)
+* Implemented multi-account functionality
+* Separated wallet password and seed offset (previously you could not set them to different values)
+* Reworked secrets tab, allowing the user to apply seed passpharse offset when saving seed
+* Fixed a bug where sync progress was lost when the wallet was closed before the sync is finished
+* Implemented APK building in the pipeline (making it easier for users to test any commit without waiting for a release)
+* and several other changes, you can check all of them [here](https://codeberg.org/acx/monfluo/compare/b939d526652d174eb6081a0b5e9dd407c409c90a...master)
+
+Monfluo is by design a very simple wallet, and one of the goals is having no "integrations" such as swapping services, sending to other cryptos, fiat on/off-ramps, etc. I do not earn any fees from the wallet.
+
+## What
+
+I will continue maintenance and development of Monfluo. I will be working on the things listed [here](https://codeberg.org/acx/monfluo/issues), among the most important ones:
+
+* Updating to newer Monero versions, when required
+* Setting up a clearnet F-Droid repo together with an onion mirror
+* Setting up translations
+* Issues [#67](https://codeberg.org/acx/monfluo/issues/67) and [#71](https://codeberg.org/acx/monfluo/issues/71)
+* Working on making Monfluo reproducible (I do **not** expect to finish this one during this CCS, but I want to start investigating it)
+
+## Funding
+
+I am asking for 25$/h.  
+With 40 hours a month (~9 hours a week) \* 3 months at ~$215/XMR this makes 25\*40\*3/215 ~= 14 XMR  
+

adrelanos-debian-package.md

 ---
-layout: wip
+layout: cp
 title: "Monero Debian Package Repository for 2 years"
 amount: 73
 author: Patrick Schleizer
@@ -7,23 +7,23 @@ date: 15 April 2020
 milestones:
   - name: "Monero Debian Package Initial Packaging"
     funds: 50% (37 XMR)
-    done:
-    status: unfinished
+    done: 31 December 2020
+    status: finished
   - name: "Monero Debian Package Maintenance 2021"
     funds: 25% (18 XMR)
-    done:
-    status: unfinished
+    done: 31 December 2021
+    status: finished
   - name: "Monero Debian Package Maintenance 2022"
     funds: 25% (18 XMR)
-    done:
-    status: unfinished
+    done: 13 March 2023
+    status: finished
 payouts:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
+  - date: 18 February 2021
+    amount: 37
+  - date: 21 March 2022
+    amount: 18
+  - date: 21 May 2023
+    amount: 18
 ---
 
 ### Importance to the Monero Community

anhdres-monero-garden.md

+---
+layout: wip
+title: Monero Garden
+author: anhdres
+date: September 30, 2022
+amount: 71
+milestones:
+  - name: Texts and structure done
+    funds: 30
+    done: 31 May 2024
+    status: finished
+  - name: Illustrations and animations done
+    funds: 30
+    done:
+    status: unfinished
+  - name: Website up
+    funds: 11
+    done: 31 May 2024
+    status: finished
+payouts:
+  - date: 18 June 2024
+    amount: 41
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+# Monero Garden
+
+## The idea
+
+The Monero Garden would initially be a website available at [monero.garden](https://anhdr.es), that worked as a clean and friendly space to start someone's Monero journey. Is a resource I wished many times existed when I told someone about Monero. The naming has two reasons: it acts as a Monero kindergarten of sorts, the starting point of your education, where you learn without any dread; but also as a real garden, with paths you can graciously take and effortlessly stroll at your own pace while discovering new things on the way.
+
+Its language, both visual and writing, should be approachable for a 11 year old and above. Trying my best to keep it clean of technical wording, yet making it engaging for an adult as well. It's a difficult balance but I think it's worth pursuit it.
+
+I want to try a different approach to the rest of Monero content I've seen so far, kind of a Choose Your Own Adventure book, where the questions that pop inside the reader's head guide the consumption of the material, and not presenting (if possible) information that wasn't felt the need for. The aim is *relevancy*, which should maximize retention and engagement.
+
+I believe that the pre-adolescents are specially important to talk to. They are starting their financial life earlier and earlier, the boundaries of *real money* and *virtual money* are going to be as dilluted as ever, so if they find Monero soon enough, they could be a strong agent of change and help avoid the dystopian version of that merge. Believe it or not, we (I'm older than 40 now) are not the future anymore. Luckily we're still the present, so there's a lot we can do!
+
+## Layout
+
+Overall, it's design should mimic children picture books. Their design is not accidental. They display images and succinct text on almost every page, which don't work in a redundant way, but complement each other. Clean, minimal background and bold, colorful illustrations. A consistent character design and color palette. If needed to reinforce a concept, the illustrations could be short animations.
+
+At the start page, the visitor would be faced with three choices. In my interactions with newcomers, those three I've noticed are the main starting points of everyone's Monero path:
+
+- How to use Monero.
+
+- Why to use Monero.
+
+- How Monero works.
+
+Each choice would take the visitor to a different path, of increasing length. According to my notes, *how to use it* is the shortest and *how it works* the longest. The way I envision it, besides navigation and a general menu, each page would have four elements:
+
+- The illustration
+
+- The short, bold statement.
+
+- A longer, yet brief explanation of the statement above.
+
+- An option to expand the topic if interested, like footnotes or links to outside sources to explore.
+
+## Scope
+
+To me, making it a website is the most effective initial form. It's big and clean, and can be accessed almost everywhere. For obvious reasons to this community, it should also be accesible via Tor and i2p. **So a working, fully functional website with those three content branches is the scope of this proposal.**
+
+The nature of the idea makes it very versatile to use as basis for a book in both physical and electronic forms, a series of animated, narrated videos, or even an app. These formats are outside of the scope of this proposal but if the material is good enough to engage people I think all those mediums would have their merits.
+
+The initial material would be in English, but obviously I see the appeal of having it translated in as many languages as possible, since it's particularly targeted towards newcomers.
+
+## Rights
+
+I plan to release this material with either a [Creative Commons BY-NC-SA  license](https://creativecommons.org/licenses/by-nc-sa/4.0/) that allows anyone to obviously access it for free (it's a website) but also create derivative works, translate it, or distribute it freely, as long as credit is mantained and it's not exploited commercially.
+
+## Budget
+
+Based on my experience, I think this first stage will take roughly 3 months. I plan to allocate 4 hrs per day to this project. At an hourly rate of 40 USD, that's 4 hrs x 60 working days = 9600 USD.
+
+I'd also need help with the technical aspects of setting up the server and different access. For what I could gather, it would take a 20 hours of work, which at the same rate of 40 USD/h amounts to 800 USD.
+
+At the current XMR price of 145 USD/XMR, it would be 71 XMR.
+
+I plan to pay domain, hosting, and other small expenses out of that budget. If the traffic were so big it demanded a considerable investment, I'd consider either open a new request for funds, or looking into other possible solutions that wouldn't cause any extra cost for the community.
+
+## Relevant information about me
+
+I've worked as creative director, illustrator, copywriter, and animator for the past 15 years. You can take a look at some of my commercial work at [Sloop Studio](https://www.sloopstudio.tv/).
+
+In the Monero world, I've been in the community since 2017, since then I've worked alongside with @m2049r and @Baltsar in [Monerujo](https://www.monerujo.io/), doing content, communications, support, and UX. One example would be [the articles explaining features or concepts behind Monero.](https://anhdres.medium.com/)
+
+I've worked alongside @serhack in both [Mastering Monero](https://masteringmonero.com/) and [serhack.me](https://serhack.me/), doing all the illustrations.
+
+Worked with @rehrar on designs for [Cypher Market](https://www.cyphermarket.com/) and [Cypher Stack](https://cypherstack.com/). Also materials for @msvblab's [Monero Devices](https://shop.monerodevices.com/). As well as designs for several Monero-related projects and individuals.
+
+Hosted the short lived [El Monero](https://www.youtube.com/channel/UCNvrbeVzrszpN7vQnMoCTVA/videos) podcast together with @rottenwheel, and gave out a few [public](https://youtu.be/s8RPE5AIB-A) [talks](https://youtu.be/78zcD7yWQ0E) and [interviews](https://youtu.be/Cx7XkZxXOKM) introducing Monero to the Spanish-speaking public.
+
+On a related note, I've made the illustrations for the newest [Tails](https://tails.net) redesign and I keep working closely on their support materials.
+
+That's pretty much all I can think of right now, be sure to ask away!

anon-dev-monero-meme-site.md

+---
+layout: cp
+title: Monero Meme Site | Get Tipped For Monero Memes
+author: AnonDev
+date: June 25th, 2021
+amount: 10 XMR
+milestones:
+  - name: Finish Site and Launch it
+    funds: 5 XMR
+    done: 18 August 2021
+    status: finished
+  - name: Market Website and Get 1st 50 Memes
+    funds: 5 XMR
+    done: 18 August 2021
+    status: finished
+payouts:
+  - date: 21 October 2021
+    amount: 10
+---
+
+My proposal is to develop, design, market, host, and maintain a website for Monero memes. Meme creators will be able to get tips for their hard work. Meme creators will finally be able to quit their jobs and meme full time. The project will be open source and full of memes.
+
+I will complete the proposal. I love Monero and wants to help get it the recognition it deserves. I have 10 years of development experience (including blockchain) and have experience in marketing.
+
+This project is very important to the community because it will increase memes. Memes help Monero with marketing and reaching new audiences. Creators of Monero memes will be able to get paid which will incentivize them to make more memes. Monero is the best project in the space but the marketing could be better.
+
+My milestones are simple. I am asking for 5 XMR once the website is live and project has been completed. I am then asking for the last 5 XMR once 50 memes (original content, not old) have been posted by users.
+
+I am asking for an expiration date of October 15th. The development should take me 1-2 weeks to complete and getting the first 50 posts should take a few months maximum (Hopefully a lot faster).

anon-perfect-peer-to-peer-protocol.md

+---
+layout: wip
+title: "anon: perfect peer to peer protocol from bottom to top"
+author: anon
+date: 24 Jan 2021
+amount: 240.12021
+milestones:
+  - name: Feb.
+    funds: 33% (80.04007 XMR)
+    done: 10 July 2021
+    status: finished
+  - name: Mar.
+    funds: 33% (80.04007 XMR)
+    done:
+    status: unfinished
+  - name: Apr.
+    funds: 33% (80.04007 XMR)
+    done:
+    status: unfinished
+payouts:
+  - date: 11 July 2021
+    amount: 80.04007
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+## What
+
+~~~
+Perfection is not attainable, but if we chase perfection we can catch excellence.
+
+On the way to perfect monero blockchain synchronization daemon
+  which is correct, simple and efficient.
+
+On the way to perfect peer to peer protocol implementation that
+  forbids arbitrary devitation in peers behavior,
+  balances available resources between unsynchronized and synchronized peers,
+  keeps new block propogation latency as low as possible.
+
+All related layers hierarchy:
+     input/output loop
+            v
+          socket
+            v
+        ssl socket
+            v
+        connection
+            v
+     abstract tcp server
+            v
+     levin protocol + portable storage
+            v
+         net node
+            v
+    cryptonote protocol + core rpc server
+            v
+     cryptonote core + crypto
+            v
+      blockchain db + tx pool
+
+The following layers are not correct:
+  ssl socket,
+  connection,
+  abstract tcp server,
+  net node,
+  cryptonote protocol,
+  tx pool.
+
+The following layers are very inefficient:
+  portable storage.
+
+All above layers aren't simple.
+
+There are few critical errors that must be fixed first:
+  segfaults,
+  enormous RAM usage,
+  enormous CPU load,
+  deadlocks,
+  unexpected delays in asynchronous code.
+
+Work will be done in the following order:
+  fix critical errors,
+  simplify,
+  fix incorrect behvaiour,
+  simplify,
+  add new changes,
+  simplify,
+  increase efficiency,
+  simplify.
+
+The above final aim and related scope require much more than 3 months work.
+~~~
+
+## Who
+
+~~~
+anon
+~~~
+
+## Proposal
+
+~~~
+Dedicate at least 3 months (12 hours per each day including weekends) to Monero Project for a total of 240.12021 XMR.
+~~~

avis-moneropedia-userguides.md

 ---
-layout: wip
+layout: cp
 title: "Norwegian translation of User guides and Moneropedia"
 author: Chris Avis
 date: August 4, 2020
@@ -7,17 +7,17 @@ amount: 29.4
 milestones:
   - name: Moneropedia
     funds: 8.7
-    done:
-    status: unfinished
+    done: 15 December 2020
+    status: finished
   - name: User guides
     funds: 20.7
-    done:
-    status: unfinished
+    done: 31 March 2021
+    status: finished
 payouts:
-  - date:
-    amount:
-  - date:
-    amount:
+  - date: 20 January 2020
+    amount: 8.7
+  - date: 1 April 2021
+    amount: 20.7
 ---
 
 This is a proposal to translate Moneropedia (10157 words) & the User guides (24074 words), amounting to 34231 words.
@@ -38,4 +38,4 @@ The translation will consist of two milestones: 1) Translation of Moneropedia +
 I will translate everything myself, and I will start to work full-time on it as soon as it is funded.
 
 Monero's truly,
-Chris
\ No newline at end of file
+Chris

binarybaron-unstoppableswap.md

+---
+layout: cp
+title: "XMR BTC Atomic Swaps Desktop GUI"
+author: binarybaron
+date: October 1, 2021
+amount: 52
+milestones:
+  - name: "Working Prototype of GUI"
+    funds: 45
+    done: 6 February 2022
+    status: finished
+  - name: "Tor & Rendezvous Protocol Integration"
+    funds: 4
+    done: 7 May 2022
+    status: finished
+  - name: "Infrastructure maintenance (October - November)"
+    funds: 1
+    done: 30 November 2021
+    status: finished
+  - name: "Infrastructure maintenance (December - January)"
+    funds: 1
+    done: 31 January 2022
+    status: finished
+  - name: "Infrastructure maintenance (February - March)"
+    funds: 1
+    done: 31 March 2022
+    status: finished
+payouts:
+  - date: 6 December 2021
+    amount: 1
+  - date: 3 February 2022
+    amount: 1
+  - date: 8 February 2022
+    amount: 45
+  - date: 2 April 2022
+    amount: 1
+  - date: 18 May 2022
+    amount: 4
+---
+
+# What
+## GUI for BTC<>XMR Atomic Swaps
+Atomic swaps between BTC and XMR have been one of the most discussed and anticipated developments in the space for quite some time. While Farcaster is still working on the implementation of their protocol, the COMIT team has already delivered an MVP. There are several swap providers active on the mainnet right now. Trustless cross-chain trades are becoming a reality.
+While the swap-cli developed as part of the MVP is usable and indeed works, it is not suitable for use by non-technical people who don't have experience navigating the command line.
+
+For trustless atomic swaps to become widely adopted, the user experience must be dramatically improved. One should not have to manually type commands into a terminal or understand the protocol on a technical level to have the ability to take part.
+For this reason, I would like to spend my time working on a FOSS GUI for BTC<>XMR atomic swaps. The GUI will be built around the swap cli and will empower even non-technical people to swap their BTC for XMR.
+
+# Who
+I binarybaron, the creator of [unstoppableswap.net](https://unstoppableswap.net) ([proof](https://unstoppableswap.net/proof.txt)) and Monero enthusiast. I was excited about Atomic Swaps from the beginning, tested the first versions and even contributed to the project (e.g. https://github.com/comit-network/xmr-btc-swap/pull/585). When the first testnet asb went online, I realized that we would need a better user interface and a platform to compare the different swap providers. I decided to start building [unstoppableswap.net](https://unstoppableswap.net). The interest has been much greater than I could have ever predicted. In the last week alone, the site has been visited more than 150,000 times. The website has become an important entry point for new users.
+
+# Proposal
+I am asking for 45 XMR to develop and deliver the first working prototype of a graphical user interface that will allow users to perform an Atomic Swap, withdraw funds from the internal wallet, compare swap providers, and view their past swap history all without having to use the terminal. I estimate that it will take 3-4 months to complete.
+
+Once this groundwork is in place and the basic functionality is reasonably stable, I will start working on the Rendezvous protocol and Tor integration. I'll require 4 XMR for this to be completed.
+
+In addition, I need 0.5 XMR per month (for 6 months) to operate and maintain the infrastructure of unstoppableswap.net. This includes a rendezvous server where swap providers can register using the libp2p rendezvous protocol. The backend, which indexes the swap providers, provides additional information such as uptime and age about providers, and makes this information available via a publicly available API (http and websocket). And the frontend which will serve as a directory for releases of the GUI and a stripped-down web version of the tool.
+
+# What I want to focus on
+### Port the existing UI of unstoppableswap.net to an Electron app
+I'll use Electron with React and TypeScript as a software stack for developing the frontend as well as the 'backend' (meaning the code that controls the swap-cli).
+- Setup Electron and convert the existing codebase to TypeScript
+- Setup Ci for testing, compilation, and publication of artifacts
+
+### Spawn swap-cli as child process
+- Automatically download the latest version of swap-cli from GitHub and validate checksums
+- Potentially also verify signatures if COMIT decides to sign their releases
+
+### Derive swap state from swap-cli logs
+In order to display instructions and details about the current state of the swap to the user, I need to derive the internal swap state from the log output and from internal database of the of the cli.
+- Decide on the best data structure to represent the state of a running swap
+- Implement using a state management system like redux
+- Potentially open PR upstream to add additional logging statements to cli
+- Requires https://github.com/comit-network/xmr-btc-swap/pull/780
+- Detect updates to the SQLite database and reflect those in the GUI
+
+### Happy-Path
+I will start developing the interface that will navigate the user through the swap procedure. I will initially be focusing on the "happy path", i.e. a scenario where both Alice and Bob follow the defined rules and the swap is completed successfully.
+
+
+### View, resume, cancel swaps
+I will enable users to view, resume and cancel swaps. A user will be able to check the amounts swapped in a particular swap and additional information such as the transactions involved will be displayed.
+- Requires https://github.com/comit-network/xmr-btc-swap/issues/766
+- Requires https://github.com/comit-network/xmr-btc-swap/issues/133
+- Potentially open PR upstream to add additional logging statements to cli
+
+### Refund and punish path
+Will add logic to state management system to derive the state for the refund and punish paths.
+- Consider all the different scenarios and inform the user at all times what is happening
+
+### View balance of internal wallet and allow withdrawal of funds
+Enable end-user to view the balance of the internal bitcoin wallet of the swap-cli and withdraw funds at will.
+- Requires https://github.com/comit-network/xmr-btc-swap/issues/766
+- Enable user to import the keys of the internal wallet into another wallet by computing the seedphrase and displaying it to the user
+
+### Use rendezvous server(s) for asb discovery
+At the very beginning we will use the API of unstoppableswap.net for the asb discovery. It would be ideal if the GUI could also use public [rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README.md) servers (like the one from COMIT) for looking up publicly accessible swap providers.
+- Reimplement rendezvous protocol using js-libp2p
+- Or use swap-cli to connect to a rendezvous server and retrieve the swap providers that have registered with them
+
+### Support for onion routing (rendezvous server, asb connection)
+To not expose the users IP-address to the maker and to improve privacy, all traffic should be routed through tor.
+- Automatically download the latest tor binary official sources
+- Start in the background
+- Validate checksums and possibly signature
+- Configure swap-cli to use tor socks5 proxy
+
+### Education
+We need to educate users on the specific rules they need to follow to avoid losing funds (e.g., not going offline for more than 12 hours after starting a swap).
+- Quiz at first start-up to make sure user understands what rules he needs to follow
+- Link to educational material
+- Documentation
+
+### Release
+- Compile binary for Windows, Linux and macOS
+- Provide download on unstoppableswap.net
+
+Expiration date: November 30, 2021

boog_2_months_cuprate.md

+---
+layout: cp
+title: Boog900 full time work on Cuprate, the Rust Monero node (2 months)   
+author: Boog900
+date: August 03, 2023
+amount: 130
+milestones:
+  - name: Consensus rules up to RingCT
+    funds: 53 XMR
+    done: 27 October 2023
+    status: finished
+  - name: All Consensus rules up to present
+    funds: 53 XMR
+    done: 10 January 2024
+    status: finished
+  - name: Consensus Rules document
+    funds: 24 XMR
+    done: 10 January 2024
+    status: finished
+payouts:
+  - date: 5 November 2023
+    amount: 53
+  - date: 26 January 2024
+    amount: 77
+---
+
+Cuprate is a WIP Rust Monero node that SyntheticBird45 started back in Feburary, I joined the project not 
+long after that, but sadly me and SyntheticBird have not been able to spend much time on it. Even more sad 
+is that recently SyntheticBird decided to stop working on Cuprate for personal reasons that I will not get 
+into here.
+
+This CCS is to support me working on Cuprate full time for the next 2 months, In this time I will complete 
+the transaction/ block verification. While doing this, I will also create a `consensus rules` document, which 
+will document all of Moneros consensus rules from genesis to the current rules.
+
+# Why
+
+Currently, Monero only has one node written in C/C++, many would see this as an issue.
+Having only one implementation makes us more vulnerable to implementation bugs, having
+another node will help us to spot and fix these issues.
+
+monerods code is also a bit of a mess, as many devs who have worked on it would agree. Cuprate
+is a fresh start and is built with modularity in mind which will lead to a cleaner and easier
+to understand codebase.
+
+Having a `consensus rules` document will make it easier for developers to build software to interact
+with Monero. It will also make it easier to spot potential issues with consensus rules.
+
+# Who
+
+I am [Boog900](https://github.com/boog900), the current, and now solo, maintainer of Cuprate.
+
+# Design
+
+For an overview of the design see [here](https://github.com/Cuprate/cuprate/blob/main/misc/DESIGN.md)
+
+# What Has Been Done
+
+## P2P
+
+The peer-to-peer code is mostly complete; I have implemented levin headers, the epee binary format and all p2p messages.
+I have also done the p2p address book, individual peer request routing, handshakes and pruning calculations.
+
+## Blockchain Data
+
+I made a PR to monero-serai adding decoding/encoding/hashing of legacy transactions and blocks so this is complete.
+
+## Consensus Checks
+
+There is still a lot to do here, but monero-serai has already done verifying for bulletproofs(+) and CLSAG.
+My PR to monero-serai also contained an unverified MLSAG verify function and a WIP Borromean range proofs
+function.
+
+## Database
+
+The initial database abstraction is complete, and we have defined the tables (we have copied monerod for
+the moment). We have also created the methods to add and get blocks and transactions from the database.
+
+Still to-do: We need to investigate the database schema for optimizations.
+
+# Tasks
+
+We need to implement/ get ready for production verifying for MLSAG, borromean range proofs and V1 ring signatures, there are other 
+checks we need to do, but these are the big ones. As Monero does not have a protocol document, we will have to go through monerod 
+to find every check it performs and do them in Cuprate.
+
+Cuprates consensus checks will be grouped together in a single location, so they are clear and not spread around the codebase,
+they will also reference the `consensus rules` document at every check. If some checks are done elsewhere, for example some are done at
+deserialization, we will either duplicate the check or, if its expensive, we will put a comment referencing the check and the
+`consensus rules` in the single location.
+
+We also need to create bindings for Moneros legacy CryptoNight POW algorithms and select a Random-X binding. There is a Rust 
+Random-X implementation, which we plan to implement as an option, but we won't enforce it as it lacks review/ usage.
+
+As our P2P/ database code still needs some work, we will be using monerods RPC interface to test the code.
+
+*All code produced for this CCS will be licensed under MIT.*
+
+### Milestones
+
+1. ###### All Consensus rules up to RCT
+   Implement verification for transactions and blocks before RCT.
+2. ###### All Consensus rules up to present
+   Implement verification for all transactions and blocks.
+3. ###### Creation of the `consensus rules` document
+
+
+# Funding
+
+I am asking for $45/hr for 50hrs/week for 2 months at $148/XMR this gives 130 XMR

boog_3_months_cuprate.md

+---
+layout: cp
+title:  Boog900 full time work on Cuprate (3 months)
+author: Boog900
+date: January 27, 2024
+amount: 190
+milestones:
+  - name: The PeerSet + Routing methods excluding D++
+    funds: 54 XMR
+    done: 15 June 2024
+    status: finished
+  - name: D++ Routing method + Network Initialisation
+    funds: 54 XMR
+    done: 15 June 2024
+    status: finished
+  - name: The Block Downloader + Syncer
+    funds: 54 XMR
+    done: 15 June 2024
+    status: finished
+  - name: P2P Documentation
+    funds: 28 XMR
+    done: 18 July 2024
+    status: finished
+payouts:
+  - date: 20 June 2024
+    amount: 162
+  - date: 1 August 2024
+    amount: 28
+---
+
+This proposal is to continue my work on [Cuprate](https://github.com/Cuprate/cuprate), specifically I will be working on
+Cuprate's P2P layer and syncing. While doing this I will also expand [monero-book](https://monero-book.cuprate.org), which I created during my last CCS, 
+with the P2P types, message encoding and message flows (handshakes etc).
+
+# Who
+
+I am [Boog900](https://github.com/Boog900), you can see my last CCS [here](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/405).
+
+# What
+
+As well as continuing to lead coordination of Cuprate, I will also be an active maintainer for monero-rs, during the past few months
+I have been reviewing and merging PRs and have released a new version: [ v0.20.0 ](https://github.com/monero-rs/monero-rs/releases/tag/v0.20.0)
+
+For this CCS I will be working on getting Cuprate's P2P layer into a working state.
+
+Currently Cuprate's P2P has:
+
+- Levin header decoding/ encoding
+- Every P2P message decoding/ encoding
+- Handshakes.
+- Rough individual peer message routing.
+- A P2P address book.
+
+What I will be doing:
+
+## Hardening Individual Peer Message Routing
+
+Individual peer message routing needs to be hardened, currently we don't do any checks the data received is the data we
+asked for, we should be doing these checks in the connection task before handing the message to the rest of Cuprate.
+
+## The PeerSet
+
+The `PeerSet` is the structure that holds all currently connect peers on a certain network, it will have methods to get
+peers by direction (Inbound, Outbound) or by a custom strategy, e.g a load balancing algorithm. This structure is then
+used by the different routing methods.
+
+## All The Routing Methods
+
+The routing methods are how the rest of Cuprates interact with the P2P network. The goal is to have there be one end point
+that the rest of Cuprate can send requests to. This end point will need to be made up of multiple `tower::Services` for the different
+routing methods (broadcast to all, etc).
+
+I will also be creating the Dandelion++ routing method, which will handle keeping the current d++ state, selecting out peers to route to and
+keeping track of stem routes. It won't handle all of D++ as that requires knowledge of the tx-pool, but it will handle all the routing
+side.
+
+## Network Initialisation
+
+I will make the network initialisation code, to start the network and return the end point that requests can be sent to.
+
+## The Block Downloader
+
+The block downloader will be a `futures::Stream` that will handle finding the chain with the most PoW from the `PeerSet` and will download
+this chain from the peer(s), giving the downloaded blocks back to the caller to then verify and add to our chain.
+
+## The Syncer 
+
+The syncer will handle synchronisation after falling behind, it will use [the block downloader](#the-block-downloader) and
+the consensus service I created for my last CCS. It will get the blocks from the downloader, verify them and then
+giving them to the database*.
+
+*the database will not be worked on for this CCS, see [hinto's CCS](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/422).
+
+If this CCS and [hinto's CCS](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/422) are accepted then when both are complete Cuprate will
+be able to sync, verify and store the blockchain.
+
+## Documentation
+
+There are already documents describing the [levin header format](https://github.com/monero-project/monero/blob/master/docs/LEVIN_PROTOCOL.md) and [epee binary format](https://github.com/monero-project/monero/blob/master/docs/PORTABLE_STORAGE.md).
+I will be documenting the format of each P2P message (how they are encoded, the fields) and successful message flows: handshakes, syncing etc. 
+
+# Why
+
+I believe that having an alternative node is needed to help to protect against implementation issues like [this one](https://github.com/monero-project/monero/pull/9013) I found during my
+last CCS.
+
+Having an accessible P2P library and documentation will make it easier for devs to build software that needs to interact with the P2P network.
+
+# Milestones
+
+1. The PeerSet + Routing methods excluding D++
+2. D++ Routing method + Network Initialisation
+3. The Block Downloader + Syncer
+4. Documentation
+
+# Funding
+
+I am asking for $45/hr for 50hrs/week for 3 months at $142/XMR this gives 190 XMR

boog_3_months_cuprate_2.md

+---
+layout: cp
+title:  Boog900 full time work on Cuprate (3 months)
+author: Boog900
+date: June 28, 2024
+amount: 215
+milestones:
+  - name: Month 1
+    funds: 71 XMR
+    done: 4 September 2024
+    status: finished
+  - name: Month 2
+    funds: 72 XMR
+    done: 29 October 2024
+    status: finished
+  - name: Month 3
+    funds: 72 XMR
+    done: 6 January 2025
+    status: finished
+payouts:
+  - date: 27 September 2024
+    amount: 71
+  - date: 10 November 2024
+    amount: 72
+  - date: 21 January 2025
+    amount: 72
+---
+
+This proposal is to continue my work on [Cuprate](https://github.com/Cuprate/cuprate).
+
+# Who
+
+I am [Boog900](https://github.com/Boog900), you can see my last CCS [here](https://ccs.getmonero.org/proposals/boog_3_months_cuprate.html).
+
+# What
+
+Cuprate is very close to having an alpha binary ready. During my last CCS I created a test binary with the components
+we currently have to test a full sync, a full sync with this binary wasn't achieved due to a few issues discovered, which have since
+been fixed, however timings up to the height (~2,300,000) we did reach are promising for Cuprate's performance.
+
+This proposal will be for 3 months work on Cuprate while continuing coordination of the Cuprate project and also being an active maintainer
+for monero-rs.
+
+My main plan is to work towards what is needed to achieve a working alpha binary that can sync, stay synchronized, handle reorgs and
+participate in transaction propagation. 
+
+This will include:
+
+### Blockchain service
+
+The blockchain service is what will keep the blockchain's state, handle incoming blocks, decide when to re-org, etc. It will use
+the consensus and database services created in previous CCS proposals (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/405 & https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/422).
+
+### Tx Pool
+
+The transactions in the txpool will be stored in a separate database from where the blockchain is stored, using the same database abstraction. 
+I will work on the txpool tables and the service that will handle txpool requests from other parts of Cuprate.
+
+Hinto, as apart of their CCS, has already began work here. Although Hinto's CCS includes a small note about completing the persistent transaction 
+pool: `The persistent transaction pool will be finished within this CCS`, I will be taking over from where hinto has left off as the exact 
+transactions pool tables are yet to be decided and the transaction pool service is heavily tied in to other areas I will be working on. 
+
+### Peer Protocol Request Handler
+
+The peer protocol request handler is what is given to `cuprate-p2p`, it is used to handle requests for blocks/transactions and other chain data.
+In our test binary I created a mock request handler that just doesn't respond to requests, this lead to pretty unstable connections, with the other
+components here though I will be able to create a working request handler.
+
+### Other Tasks
+
+There are other smaller things that need to be worked on for Cuprate to be ready for an alpha binary, mainly bug fixes and leftover TODOs.
+
+# Milestones
+
+Unlike my previous CCS proposals, I am basing milestones on hours worked instead of completed work. 
+
+There are a few reasons for this. The exact work needed is likely to change as we get closer to an alpha binary, for example, bugs that need
+fixing may come up. It also brings the proposal closer to the average full-time developer proposal.
+
+Although doing milestones based on time requires more trust, we are doing weekly [Cuprate meetings](https://github.com/monero-project/meta/issues/1028) 
+where I am, and will be reporting progress.
+
+# Funding
+
+I am asking for $55/hr for 50 hrs/week for 3 months at $166/XMR. This gives 215 XMR.
+
+This is a raise over my last CCS ($45 -> $55), I believe this is justified given my past work.  

boog_3_months_cuprate_3.md

+---
+layout: wip
+title:  Boog900 full time work on Cuprate (3 months) + January
+author: Boog900
+date: February 11, 2025
+amount: 160
+milestones:
+  - name: January
+    funds: 40 XMR
+    done:
+    status: unfinished
+  - name: Month 1
+    funds: 40 XMR
+    done:
+    status: unfinished
+  - name: Month 2
+    funds: 40 XMR
+    done:
+    status: unfinished
+  - name: Month 3
+    funds: 40 XMR
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+# Who
+
+I am [Boog900](https://github.com/Boog900), you can see my last CCS [here](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/469).
+
+# What
+
+I will work for 3 months on Cuprate with an initial focus on releasing an alpha `cuprated`, the basic roadmap can be seen here: https://github.com/Cuprate/cuprate/issues/376.
+I plan to work on what I think is best to advance the project.
+
+I am also asking for payment for the hours I worked in January. We had some discussions about changing the way we
+get funded, potentially making a combined "cuprate CCS", however we decided against it, this lead to the delay of this CCS. 
+A list of things I did during January:
+
+- finished the init PR: https://github.com/Cuprate/cuprate/pull/344
+- worked on improving our consensus API: https://github.com/Cuprate/cuprate/pull/366, to prepare for fast-sync.
+- Started working on [issue 174](https://github.com/Cuprate/cuprate/issues/174): https://github.com/Cuprate/cuprate/pull/382
+- Investigated why monerod was syncing the first 100,000 blocks faster than cuprated, which lead to this PR: https://github.com/Cuprate/cuprate/pull/377
+- Started working on changing monero-oxide's tx type to use compressed points: https://github.com/Cuprate/serai/tree/monero-comp-points
+- Started working on fast-sync: https://github.com/Cuprate/cuprate/tree/fast-sync
+
+All the tasks that have been started are pretty much ready just need to be cleaned up, they are all used in the fast-sync branch
+which a few people have tested syncs on, the quickest sync _so far_ was just over 4 hours.
+
+# Funding 
+
+I am asking for 40 XMR for my work in January.
+
+$55/hr for 480 hrs at $220/XMR: 120 XMR
+
+total: 160 XMR

bulletproofs-plus-audit-jp.md

+---
+layout: cp
+title: Bulletproofs+ Audit 2
+author: Justin Ehrenhofer
+date: 28 February 2021
+amount: 67
+milestones:
+  - name: Bulletproofs+ Final Report
+    funds: 67
+    done: 22 March 2021
+    status: finished
+payouts:
+  - date: 24 March 2021
+    amount: 67
+---
+
+I am opening this CCS proposal on behalf of JP Aumasson for a second audit of Bulletproofs+. Payout will be to him directly in XMR. Bulletproofs+ make Monero transactions faster and more efficient.
+
+JP's SoW: https://github.com/monero-project/meta/files/6037185/bpplus-review-sow.pdf
+First audit from ZenGo: https://suyash67.github.io/homepage/assets/pdfs/bulletproofs_plus_audit_report_v1.1.pdf
+
+JP will build upon the previous audit and code changes resulting from it. Audits are critical for Monero's code security. Bulletproofs+ are a drop-in replacement for Bulletproofs, and they will remain useful for future Monero improvements like Triptych.
+
+I would like to thank the companies who submitted a SoW for this second audit. I would also like to thank the other members of the Monero Audit Workgroup, who coordinated an audit with companies entirely on its own for the first time.
+
+JP is available effectively immediately after the CCS funds are raised to begin the audit.
+
+Cost breakdown:
+
+* Audit amount: $12,500
+* Buffer (10%): $1,250
+* Total: $13,750
+* XMR ($205): 67

bulletproofs-plus-audit.md

+---
+layout: cp
+title: "Bulletproofs+ Audit for Monero"
+author: Suyash Bagad
+date: 22 December 2020
+amount: 90.3 
+milestones:
+  - name: Audit Report of Bulletproofs+ Code and the E-print paper 
+    funds: 100% (90.3 XMR)
+    done: 13 February 2021
+    status: finished
+payouts:
+  - date: 14 February 2021
+    amount: 90.3
+---
+
+### Overview
+
+Hello everyone! This CCS proposal is for the audit of the Bulletproofs+ [implementation](https://github.com/SarangNoether/monero/tree/bp-plus) for range proofs in Monero. [Bulletproofs+](https://eprint.iacr.org/2020/735) is a more efficient range proof protocol building on [Bulletproofs](https://eprint.iacr.org/2017/1066.pdf). Bulletproofs+ for Monero has been implemented by Dr. Sarang Noether as per [this](https://charity.gofundme.com/o/en/campaign/dr-sarang-noether-to-implement-bulletproofs-in-monero) proposal. Bulletproofs+ offers at least 5%  proof size reduction and 5-10% speedup in verification[^1]. Refer to our blogs[^2] for in-depth technical differences between Bulletproofs and Bulletproofs+.
+
+### Scope
+
+We aim to perform a cryptographic and security assessment of the Bulletproof+ (referred to as BP+ hereafter) protocol specific to the Monero blockchain. Our goal is to establish the readiness of a specific C++ implementation of BP+ as a drop in replacement to the existing range proof protocol Bulletproofs in Monero. We plan to cover the following points as a part of the audit:
+1. A full peer review of the eprint version ([link](https://eprint.iacr.org/2020/735)) of the paper with focus on the soundness of the scheme. Note that at the time of writing this proposal, the paper is not yet published in a peer-reviewed conference/journal. 
+2. Thorough examination if the BP+ code ([link](https://github.com/SarangNoether/monero/tree/bp-plus)) accurately represents the Bulletproofs+ prove and verify algorithms, in particular
+    - To check if the code allows an attacker to generate a false proof that the verify algorithm deems as correct,
+    - To check if the code leaks any information to an attacker from examining the proof generated by an honest prover, 
+3.  Assess the correctness of the C++ code (~1500 lines of code of BP+ including tests and headers) from a logical and an implementation point of view, including the underlying elliptic curve arithmetic used. We will use an independent Rust [implementation](https://github.com/ZenGo-X/bulletproofs) to provide an extra layer of validation. 
+4. Focus on identifying vulnerabilities related to security and in particular the cryptographic properties. We will do our best effort to offer improvements to the code.  
+
+### About Us
+
+Our team consists of the following members:
+1. [Omer Shlomovits](https://www.omershlomovits.com/): Co-founder of [ZenGoX](https://zengo.com/research/),  [MPC-Alliance](https://www.mpcalliance.org/), [ZK-Tel-Aviv](https://www.meetup.com/Zero-Knowledge-Tel-Aviv/). Vastly [experienced](https://www.omershlomovits.com/work) in Crypto & Blockchain research, implementing complex cryptographic systems. 
+2. [Suyash Bagad](https://suyash67.github.io/homepage/): Cryptography Engineer at Aztec Protocol, ZenGoX Research member, B.Tech and M.Tech from the Indian Institute of Technology, Bombay with thesis primarily on [Privacy-preserving Proofs of Reserves for Monero and Grin](https://suyash67.github.io/homepage/assets/pdfs/suyash-masters-thesis.pdf). First author of 2 papers presented to IEEE S&B, Crypto Valley conferences. Experienced in implementing zero-knowledge proof systems.
+
+Note: We are the same team who had first [proposed](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/156) the implementation of BP+ for Monero.
+
+### Funding Note
+
+We estimate to complete the project in about 1 month in two steps: (i) Full peer review of the paper, (ii) Complete audit of the implementation in form of a well-compiled report. We need a funding of XMR 90.3 (equivalent of $15,000) as per 7-day average price (1 XMR = $166.13) on Kraken. This project will include both Suyash and Omer working as well as academic advisory from [Prof. Claudio Orlandi](https://users-cs.au.dk/orlandi/). 
+
+
+[^1]: Dr. Sarang's blog on Bulletproofs+. Available: https://gist.github.com/SarangNoether/ee6367fa8b5500120b2a4dbe23b71694
+
+[^2]: Comparing Bulletproofs and Bulletproofs+. Available ([Part I](https://suyash67.github.io/homepage/project/2020/07/03/bulletproofs_plus_part1.html), [Part II](https://suyash67.github.io/homepage/project/2020/07/03/bulletproofs_plus_part2.html), [Part III](https://suyash67.github.io/homepage/project/2020/07/03/bulletproofs_plus_part3.html))
+
+

bulletproofs-pp-peer-review.md

+---
+layout: cp
+title: Bulletproofs++ Peer Review
+author: Monero Research Lab
+date: March 22, 2023
+amount: 130
+milestones:
+  - name: Bp++ eprint peer review CCS part
+    funds: 130
+    done: 6 March 2024
+    status: finished
+  - name: Bp++ eprint peer review GenFund part
+    funds: ~$14000
+    done: 29 March 2024
+    status: finished
+payouts:
+  - date: 7 March 2024
+    amount: 130
+  - date: 7 April 2024
+    amount: 101
+---
+
+## Bulletproofs++ Peer Review
+
+This CCS will provide funding for the first step towards Bulletproofs++ implementation in Monero. (and also the planned Seraphis upgrade). Bulletproofs+ were added in the latest [Network Upgrade](https://www.getmonero.org/2022/04/20/network-upgrade-july-2022.html). They reduce the typical transaction size by ~5-7% and improve typical verification performance by ~5-7%, making every transaction lighter and faster. Bulletproofs++ claims to significantly improve upon this (e.g. ~27% smaller than Bp+).
+
+## Scope / Deliverables
+
+A full peer review of the eprint version [[link]](https://eprint.iacr.org/archive/2022/510/20230717:163509)  of the paper. Note that at the time of writing this proposal, the paper is not yet published in a peer-reviewed conference/journal.
+
+The deliverable is a write-up which will include recommendations, notes, weaknesses, and issues (if any) of the BP++ paper touching on:
+- The soundness, completeness, and zero knowledge portions of the paper.
+- Efficiency* Aggregation. ~~Batching. MPC compatibility.~~ 
+- Making sure it fits neatly and completely into the place that BP+ currently sits by checking the correctness of proofs.
+
+## Out of scope
+
+- Multiparty computation. There are no specific protocols presented for this, and no corresponding security model of proofs of security.
+- Batch verification. While the preprint mentions that BP++ supports batch verification, it provides no details on the corresponding algebra.
+- Multi-asset transactions. The preprint discusses multi-asset transactions in the context of its protocols, but these are not required for range proofs.
+- Optimized binary range proofs. The protocol proposed for optimized binary range proofs has only an informal and vague security proof that is insufficient to assert the claims of the corresponding theorem.
+
+## Funding
+
+The latest version of the paper is now greatly expanded. CypherStack has given a new quote for this paper of $32,000. Core will decide how the shortfall is handled.
+
+- Funds are released by Core to a third party and converted. 
+- $32,000 will be paid directly to [CypherStack](https://cypherstack.com/).
+- Excess XMR after conversion will be donated to the next Bp++ CCS.
+- Any shortfalls from volatility will be paid by the Monero General Fund.