escapethe3ra-monero-observer-website-2.md

+---
+layout: cp
+title: escapethe3RA Monero Observer maintenance (3 months)
+author: escapethe3RA
+date: November 25, 2021
+amount: 21
+milestones:
+  - name: December
+    funds: 7
+    done: 31 December 2021
+    status: finished
+  - name: January
+    funds: 7
+    done: 31 January 2022
+    status: finished
+  - name: February
+    funds: 7
+    done: 28 February 2021
+    status: finished
+payouts:
+  - date: 16 January 2022
+    amount: 7
+  - date: 16 February 2022
+    amount: 7
+  - date: 20 March 2022
+    amount: 7
+---
+
+# What
+
+I will continue to maintain *Monero Observer* (https://monero.observer) for the next 3 months (winter 21/2022): December, January and February.
+
+Tasks:
+
+- Daily: search, curate, structure and post new reports/stories
+- Daily/As Needed: post new *MO Community Messages*
+- Weekly: publish the *MO XMR TA Report* (technical analysis Monero price report)
+- Monthly: publish the *MO Blitz Report* (includes everything that happened the previous month)
+- As Needed: housekeeping (revise stories to make sure links and content is still relevant)
+- As Needed: outreach (engage with the community on Matrix, Reddit, XMPP, emails)
+- As Needed: make sure the website is live and working as expected (no 404's, domain is paid, etc)
+- Optional: add new features, improvements and website sections
+
+# Who
+
+escapethe3RA, I have started contributing to the Monero ecosystem in August with Monero Observer and other smaller projects:
+
+- published 356 MO stories (https://www.monero.observer/stories)
+- published 11 MO XMR TA reports (https://www.monero.observer/tag/blitz)
+- published 3 MO Blitz reports (https://www.monero.observer/tag/analysis)
+- created several guides on GPG encryption, RSS feeds and Monero contributors (https://www.monero.observer/ultimate-guide-new-monero-contributors/, https://www.monero.observer/gpg-cleartext-signatures/, https://www.monero.observer/gpg-generate-full-keypair/)
+- redesigned *Monero Means Money* website, donated bounty to GF (https://moneromeans.money/, https://github.com/escapethe3RA/monero-means-money/)
+- started MO *Community Messages* initiative (https://www.monero.observer/tag/community)
+- other project improvements (https://www.monero.observer/changelog)
+ 
+# Proposal
+
+I will work for 25 hours per week over 3 months at a rate of 0.07 XMR / hour. At $220 / XMR (10% buffer) this makes 21 XMR (0.07*100*3).
+

escapethe3ra-monero-observer-website.md

+---
+layout: cp
+title: Monero Observer news website
+author: escapethe3RA
+date: August 23, 2021
+amount: 15.99
+milestones:
+  - name: September
+    funds: 5.33
+    done: 30 September 2021
+    status: finished
+  - name: October
+    funds: 5.33
+    done: 31 October 2021
+    status: finished
+  - name: November
+    funds: 5.33
+    done: 30 November 2021
+    status: finished
+payouts:
+  - date: 15 October 2021
+    amount: 5.33
+  - date: 16 November 2021
+    amount: 5.33
+  - date: 15 December 2021
+    amount: 5.33
+---
+
+# WHAT
+
+I will maintain **Monero Observer**[^1] for the next 3 months (autumn 2021): September, October and November.
+
+Essentially:
+
+- DAILY: search, curate, structure and post new content (CHANGELOG available: https://www.monero.observer/changelog/)
+- AS NEEDED: housekeeping (revise stories to make sure links and content is still relevant)
+- AS NEEDED: outreach (engage with the community mainly via email to encourage participation and get new stories/tips faster)
+- AS NEEDED: make sure the website is live and working as expected (no 404's, domain is paid, etc)
+- WEEKLY: publish Monero XMR TA Report, a weekly XMR technical analysis report (reference: https://www.monero.observer/tag/analysis/)
+- MONTHLY: publish Monero Observer Blitz, a monthly report that includes everything that happened the previous month (reference: https://www.monero.observer/tag/blitz/)
+- (BONUS, OPTIONAL) AS NEEDED: publish Monero & privacy/opsec-related guides (reference: https://www.monero.observer/tag/guides/)
+
+# WHO
+
+Myself: escapethe3RA, a Monero enthusiast, a private citizen.
+
+# WHY
+
+I strongly believe that the Monero community would benefit from the existence of the Monero Observer, both right now and in the long run.
+
+While there are a few other places where people can get news and stories from around the Monero community, I am proposing a slightly different and more efficient approach.
+
+Here are some of my thoughts:
+
+- we need a dedicated Monero-only news website that is being run by someone in our community, privately
+- the general writing style should resemble a journalistic approach, based on facts and as little opinion as possible
+- clean, minimalist interface, no bloat, few images
+- references/sources should never be absent from each post; furthermore the author should seek to prioritize privacy-respecting platforms and thus share the links to those if possible (ie. invidio.us instead of youtube.com, nitter.net instead of twitter.com)
+- readers must be allowed unrestricted access to the stories, privately via tor (zero Javascript, no cookies, no tracking or any kind of analytics service, no pop-ups, no newsletters, no CDN, no captchas, no ads whatsoever)
+- smaller stories should also be covered whenever possible, in order to support and encourage community participation in a decentralized way, the Monero way (individual bloggers, small time alt platform video and guide makers, tiny merchants)
+- search engine juice should be allowed to flow to every site in the community and disabled (rel=nofollow) for big tech sites (in the references/src links)
+- advertising should be approached very conservatively and human-to-human contact should be prioritized whenever possible (think: email still works, word of mouth will never die, if you build something they will come so have a strong foundation ready;)
+- stay away from mainstream centralized social media if possible; RSS should be encouraged, it's still the best (IMHO); potentially add decentralized social accounts (ie. federation) in the future 
+
+There's more, but I believe these notes should suffice for now.
+
+I have already taken the liberty to dedicate my past couple of weeks to this project: find a voice and well defined structure for the content, design the website, research and write the posts, add reference links and deploy.
+
+You can visit the website and get a glimpse of my work so far. Before I continue with the project in this direction I need the community's feedback and approval. If you think this would be useful, comment and support my proposal. Thoughts, constructive criticism and discussions are encouraged.
+
+If you wish to contact me you can do so by sending me an email (address on the website's about page, PGP key available for sensitive content).
+
+# MILESTONES
+
+The work hours that I have already put in this month will **not** be counted towards this proposal. First of all I wanted to know approximately how many hours I'd need to put in beforehand and secondly I wanted to show up with a PoC.
+
+I am proposing to maintain Monero Observer for the next three months of autumn: September, October and November at a rate of $15/hour, 80 hours a month. The total is 15.99 XMR at the rate 1 XMR == $225 (~10% buffer from current Kraken price).
+
+Thus, there will be three milestones, 5.33 XMR each, paid on the last day of each month: 30 September, 31 October, 30 November.
+
+If all goes well and the community finds the project useful we can discuss 2022 plans.
+
+Thanks for reading!
+
+Ta-ta,
+**escapethe3RA**
+
+[^1]: https://monero.observer

feather-2020.md

+---
+layout: cp
+title: Feather wallet GUI development
+author: Feather team
+date: 1 September 2020
+amount: 188
+milestones:
+  - name: 1st milestone
+    funds: 94
+    done: 3 September 2020
+    status: finished
+  - name: Alpha release
+    funds: 94
+    done: 20 October 2020
+    status: finished
+payouts:
+  - date: 3 September 2020
+    amount: 94
+  - date: 23 October 2020
+    amount: 94
+---
+
+# What
+
+Feather is an [upcoming open-source desktop Monero wallet](https://www.youtube.com/watch?v=tylbteVtwrw) with some interesting features. It has been in development for over a year. Community reception thus far has been quite positive.
+
+- [/r/Monero/comments/idujx0/feather_free_opensource_monero_desktop_wallet/](https://www.reddit.com/r/Monero/comments/idujx0/feather_free_opensource_monero_desktop_wallet/)
+- https://twitter.com/xmrdsc/status/1297275505704685568
+- https://twitter.com/xmrdsc/status/1297620436184899585
+- https://twitter.com/xmrdsc/status/1297906498899775490
+
+A lot of work has gone into the project. The Feather team is excited about what has been developed and could use funding to support the cause of releasing this FOSS application, as there is still a couple of months left to bridge before release.
+
+## TO-DO
+
+We have most functionality working, the challenges ahead are:
+
+1. Static builds for Windows and Mac OS
+2. Upstreaming various patches to `src/wallet/api/wallet2_api.h` (CLI - that libwalletqt (GUI) can use, mostly additions).
+3. Creating and hosting a dedicated static website.
+4. Hosting both high performance clearnet and Tor remote nodes.
+5. Hooking up buildbots to our git for nightly builds
+6. Node switching inside the application.
+7. Testing to ensure the wallet is stable and robust
+8. Fixing platform-specific bugs
+
+## CCS
+
+Previously, dsc_ made [a proposal](https://ccs.getmonero.org/proposals/dsc-2019-q2.html) for Monero GUI development for which he has completed 1 out of 3 milestones. We believe it would be beneficial if those funds could be used to support finishing our Feather wallet project instead, as both proposals are regarding GUI work, we feel Feather is more important/impactful to the community.
+
+We would like to use the remainder of the 2 milestones, the first being distributed **now**, to support ourselves while working on Feather, and the second milestone will be reached in (hopefully) October, when we go into alpha. 
+
+Feather will:
+
+- Release code under the Monero License.
+- Self-host the website/issue-tracker/git-repositories (and also make it available through Tor).
+- [dsc__](https://www.reddit.com/user/dsc__) and [tobtoht](https://www.reddit.com/user/tobtoht) will maintain future releases.
+- Upstream wallet2 changes so that the Official GUI may borrow functionality.
+- Deliver something great to the Monero community.
+
+## What can we expect during alpha relase?
+
+It will include most functionality - Linux and Mac OS.
+
+1. Our repositories (Feather, websocket back-end (Python)) will be opened to the public
+2. The community has the ability to test and give suggestions, create PRs
+3. Static Linux builds via Docker (Qt 5.15.0) on an Ubuntu 18 base image
+4. Self compilation required (we will not distribute static binaries)
+
+We are targetting October.
+
+The alpha version takes place on stagenet and it'll be an opportunity to test integration with various Linux distros. Bugs can be reported and managed on our self-hosted issue tracker. People running Mac OS are free to participate in the testing, but our focus will largely be on Linux.
+
+## What can we expect on release?
+
+1. Linux / Mac OS static binaries
+2. A website with pgp signed binaries and documentation
+3. Upstreaming of wallet2 changes
+4. The features described in our [announcement post](https://www.reddit.com/r/Monero/comments/idujx0/feather_free_opensource_monero_desktop_wallet/) and [video](https://www.youtube.com/watch?v=tylbteVtwrw)
+5. A robust/fast Linux/Mac OS Monero wallet.
+
+We believe a full release in December is realistic.
+
+## What can we expect after release?
+
+- Windows support (Q1 or Q2 2021, [cross compilation attempts here](https://git.wownero.com/feather/mxe/commit/a6ed6f3c323c301dcdeed3fc685fce4b993d8900))
+- Multi-sig (Still exploring the various options, [more info here](https://www.reddit.com/r/Monero/comments/ikiv8t/what_we_need_for_adoption_is_trivial_multisig/g3l7os6/))
+- Debian package
+- Wallet refresh over clearnet, transaction submission over Tor
+- Feather as a websocket server (to be announced)
+
+We will continue to maintain Feather after release, however any **significant** feature updates (such as multisig) may require additional funding through a separate CCS depending on the time and effort required to implement them.
+
+## Ending note
+
+We have been careful to make certain promises on timelines and features in this CCS proposal - mostly due to the complexity of the project. We target deadlines but delays may occur. However, we've already got a lot finished (as can be seen in [our video](https://www.youtube.com/watch?v=tylbteVtwrw)).
+
+If we are not able to raise funding, it will be delayed notably as we will have to find ways to support ourselves. In that case the application will of course still *eventually* release under an open-source license, somewhere in 2021.
+
+

h4sh3d-atomic-swap-implementation.md

+---
+layout: wip
+title: Monero Atomic Swaps implementation funding
+author: h4sh3d et al.
+date: September, 2020
+amount: 2727
+milestones:
+  - name: M1.A.1 User-facing
+    funds: 7% (190.89 XMR)
+    done: 31 March 2021
+    status: finished
+  - name: M1.A.2 Service internals
+    funds: 3.25% (88.6275 XMR)
+    done: 31 March 2021
+    status: finished
+  - name: M1.B.1 External specification of swap-lib
+    funds: 3.25% (88.6275 XMR)
+    done: 31 March 2021
+    status: finished
+  - name: M1.B.2 Internal specification of swap-lib
+    funds: 3.25% (88.6275 XMR)
+    done: 31 March 2021
+    status: finished
+  - name: M1.C Specification of chain-syncer
+    funds: 3.25% (88.6275 XMR)
+    done: 31 March 2021
+    status: finished
+  - name: M2.A. Cryptographic libraries
+    funds: 3.375% (92.03625 XMR)
+    done: 15 December 2021
+    status: finished
+  - name: M2.B. swap-lib
+    funds: 11.25% (306.7875 XMR)
+    done: 15 December 2021
+    status: finished
+  - name: M2.C. swap-client
+    funds: 5.625% (153.39375 XMR)
+    done: 15 December 2021
+    status: finished
+  - name: M2.D. swap-daemon
+    funds: 13.5% (368.145 XMR)
+    done: 15 December 2021
+    status: finished
+  - name: M2.E. chain-syncers
+    funds: 11.25% (306.7875 XMR)
+    done: 15 December 2021
+    status: finished
+  - name: M3.A.1 xgroup-dleq-lib
+    funds: 8.75% (238.6125 XMR)
+    done:
+    status: unfinished
+  - name: M3.A.2 ecdsa-adaptor-sig
+    funds: 8.75% (238.6125 XMR)
+    done:
+    status: unfinished
+  - name: M3.B. chain-syncer
+    funds: 5.25% (143.1675 XMR)
+    done:
+    status: unfinished
+  - name: M3.C.1 swap-cli
+    funds: 3.5% (95.445 XMR)
+    done:
+    status: unfinished
+  - name: M3.C.2 swap-gui
+    funds: 5.25% (143.1675 XMR)
+    done:
+    status: unfinished
+  - name: M3.D. swap-daemon
+    funds: 3.5% (95.445 XMR)
+    done:
+    status: unfinished
+payouts:
+  - date: 23 April 2021
+    amount: 190.89
+  - date: 25 April 2021
+    amount: 354.51
+  - date: 22 December 2021
+    amount: 1227.15
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+:warning: *DIFFERENT CCS RULES ARE IN PLACE FOR THIS PROPOSAL! PLEASE READ THE FOLLOWING!* :warning:
+
+```
+As a trial, this CCS proposal is going to operate on slightly different rules
+given the unprecedented scope and duration of this proposal. For this proposal
+ONLY, refunds will be issued in the event that the funding is not satisfactory
+or the milestones are not completed. This differs from the standard of excess or
+unused funds going to the general fund.
+
+To qualify for a refund, the donator must send their tx ID, amount, and return
+XMR address to luigi1111@getmonero.org (PGP fingerprint:
+FE6D D72A 19CD C5FC 6CB9  1696 BA18 1389 4EDD 58B9, full PGP key at
+github.com/monero-project/monero/blob/master/utils/gpg_keys/luigi1111.asc) NO
+LATER than ONE WEEK after their donation is made. Any remaining unclaimed funds
+(in the event that the proposal is not completed) will be sent to the general
+fund as usual. If refunds are to be issued, the funds will be returned via the
+provided XMR address.
+
+In summary, the funds can be either:
+
+Unclaimed, leading to the general fund receiving them in the case of a failed
+proposal.
+
+Claimed within one week of the donation, leading to a refund in the case of a
+failed proposal.
+
+Note: The hope is that the refunds will not be needed, and the proposal will get
+funded and completed. In the event of proposal completion, refunds will NOT be
+issued. It is only if the proposal is not completed or funded to satisfaction,
+and ONLY for this proposal.
+```
+
+# Monero Atomic Swap implementation funding
+
+Previous CCS: [Monero Atomic Swaps research funding](https://ccs.getmonero.org/proposals/h4sh3d-atomic-swap-research.html)
+
+Hi everyone,
+
+Three months ago, I posted a CCS for continuing my research on Monero Atomic Swaps. That research is now complete and the results can be found [here](https://www.reddit.com/r/Monero/comments/i1fknt/ccs_results_monero_atomic_swaps_research/). The resulting protocol is implementable today; no more missing crypto! So much so that a PoC was implemented in no time; thank you, kayabaNerve and PlasmaPower! Thus I am reaching out to propose getting a team to work on implementing this protocol, with the end goal of creating a production-ready client/daemon for swapping Bitcoin and Monero. Our design enables to seamlessly extend support for more cryptocurrencies to swap with Monero. It would be very exciting to build that.
+
+You can find the whitepaper that describes the full protocol [here](https://github.com/h4sh3d/xmr-btc-atomic-swap).
+
+A ready-to-use implementation requires a lot of engineering work. Here, my colleagues and I attempt to break down the project into manageable parts, describing the dependencies that have to be fulfilled, and the general roadmap of the project.
+
+## Motivation
+
+Trustless technologies are now emerging, creating the option of refusing to accept counter-party risk. You can make trades with your enemy, as they can't cheat on you. If you don't have to trust, you don't have to know who they are, either.
+
+It is very unlikely that Monero will get banned by all centralized exchanges, but by having an open source atomic swap implementation, such banning mechanism is inefective, as Monero would still be available to anyone who could acquire Bitcoin, which is ubiquitous, and swap the coins online anonymously, trustlessly, with a random peer. Monero will be more robust than ever.
+
+Bitcoin is traceable. This is used to recognize dirty coins, but also for untargeted surveillance and censorship. Bitcoiners, in need of strong privacy, might recognize the utility of a trustless path with low resistance to convert their bitcoin into monero, and become Monero users. 
+
+However, with power comes responsibility, atomic swaps enable users to exchange coins directly with each other. At the same time, if transacted value is significant, honest users MUST carry out their due diligence regarding the origin of the counterparty funds and possibly other anti-money laundering countermeasures, in order to comply with regulations. Trustlessness and no counter-party risk are narrowly defined terms of the atomic-swap literature, that ignores the context whereby the technology is deployed. Bitcoins accumulate dirt in their lifetimes, so swap your monero responsibly, because trustlessly receiving tainted bitcoins is a real counterparty-risk. The counterparties of a swap generate private and blockchain notarized cryptographic proofs of their private agreement, but the court of your jurisdiction might not like that explanation so much. 
+
+The crypto-ecosystem is rapidly moving towards interoperability. Atomic swaps unleash interoperability between Monero and other blockchains. Whether a user needs to open a lighting channel from the monero-bitcoin swap or wants to fund an arbitrary bitcoin contract, the swap protocol exposes the interop socket.
+
+This project will also, as a beneficial side-effect, extend the Monero ecosystem in Rust. Multiple libraries are needed to support the full protocol. Most of them are related to cryptography, for example the "Discrete logarithm equality across groups" algorithm described in the [MRL-0010](https://www.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf) technical note by Sarang Noether (originally proposed by Andrew Poelstra), or directly at the Monero protocol level in the [Monero Rust Library](https://github.com/monero-rs/monero-rs).
+
+Our motivation to build this software is to empower individuals and businesses, who *want* to or *need* to exchange within a strong security and privacy context using P2P, trustless technologies. 
+
+This project has the potential of increasing Monero's liquidity and enabling Monero to get into the hands of more people.
+
+We deem it critical to build this in a manner that fully aligns with the interests of the community. Thus we're reaching out to raise community money, to build this with the community, for the community, enabling the community to preserve its own interests.
+
+### What are we building?
+We aim to build a collection of programs---similar to programs you are familiar with, such as the Monero daemon, wallet CLI, or wallet GUI---that have limited functionality individually but as a collection, serve the functions an end-user requires. One can launch these swap programs to exchange coins with a counterparty. We call those programs: swap clients (CLI or GUI), the swap daemon (like the Monero daemon), and chain-syncers (connected to full nodes). In the default configuration, this will mean opening the swap client and letting it launch and manage all other programs involved.
+
+For example, if you, as an end-user, want to acquire monero and have bitcoin, you'll launch a swap client that connects to a swap daemon, and connects to a counterparty that has monero and is looking to trade them for bitcoin at an agreed upon price. The swap client will give you an address where to move your bitcoin and, at the end of the swap, the swap client will display the monero key-pair to import into your wallet. You now own monero. If at some point the swap is canceled for any reason, your bitcoin will be refunded at the address you chose, making this exchange trustless.
+
+Connecting to a counterparty will require knowledge of their daemon's address, and the amounts traded (i.e. the price and quantity). Creating a platform such as a DEX, allowing people to find each other and "auto" connect with the correct arguments or negotiate the price, is out-of-scope for this project. Industry standards for such interfaces are yet to emerge.
+
+## Overview
+
+R&D Institution: Cryp GmbH
+
+Funding: Monero CCS
+
+Duration: 7 months
+
+Job completion: by Q2 2021
+
+Contributors:
+
+ * h4sh3d
+ * kayabaNerve
+ * lederstrumpf
+ * the charlatan
+ * zkao
+
+Licenses: The license for the code will be decided based on community feedback. Our current preference is LGPL-3.0. The specification will be released under CC-BY-4.0. 
+
+__Expiration date:__
+Funding will remain open until __31.12.2020__. If materially underfunded until __31.12.2020__, we'll either (1) agree with the community to deliver a subset of the deliverables and collect the funds, or (2) discuss how to re-allocate the funds with the community.
+
+## Architecture
+The core project will be built in Rust. Rust's good coverage of cryptographic libraries and blockchain protocols, type safety, and language design makes it a very good candidate for such applications (and the prototype is also written in Rust, for the same reasons).
+
+Here we present an overview of the project's architecture. More details of the individual components will be described in a forthcoming section under [Deliverables](#Libraries-and-Components).
+
+#### The figure represents the general architecture of the swap components and their interactions.
+
+![](https://codimd.s3.shivering-isles.com/demo/uploads/upload_3d490af9aeffe7082babf7087ea404f5.png)
+
+
+#### The following table summarizes different aspects of each component.
+
+|                 | `swap-client`                    | `swap-daemon`                                        | `chain-syncer`     |
+|-----------------|----------------------------------|------------------------------------------------------|--------------------|
+| definition   | a program that controls the daemon and display the current state | a program that executes the core protocol in a state machine | a program that talks with a specific blockchain |
+| cryptographic keys & secrets | private & public    | public only                                          | public only        |
+| client/user  | end-user                         | `swap-client`, counterparty `swap-daemon`                | `swap-daemon`        |
+| availability          | present at the start and to sign | mostly online, channel of communication between parties | always online      |
+| communicates with | `swap-daemon`                      | `swap-client`, `chain-syncer`, counterparty `swap-daemon` | `swap-daemon`, blockchain |
+| transactions    | signs                            | creates all transactions, verifies signatures        | listens for and publishes transactions  |
+| protocol-state  | doesn't understand protocol, but can represent its state              | understands the protocol, but can't sign             | doesn't understand protocol |
+
+
+### Client/daemon segregation rationale
+
+The rationale behind segregating the client and the daemon is not for security reasons at the moment (the client signs the transactions received from the daemon blindly, implying full trust), but for the flexibility and extensibility added.
+
+Other clients can be created: mobile applications (that also run the daemon in background), heavy or light desktop GUIs, or even scripted/automated backends (e.g. in a business environment).
+
+### Future extensibility
+The atomic swap protocol is just the first instantiation of a more generic interface to other systems---we aim to build this construction abstractly enough to allow clean extension [^1] to future protocols.
+
+## Deliverables
+Below is a complete list of our deliverables.
+
+### Specifications
+  * Specification of `swap-lib`:
+Specify the interface and the requirements for adding support for a new chain, for one or both templates (Bitcoin-like and Monero-like).
+  * Specification of `swap-daemon`:
+Specify messages passed between `swap-daemon` and: `swap-client` and `swap-daemon`. These include protocol messages exchanged between swap participants, but also specify the medium of communication of `swap-daemon` and those components.
+  * Specification of `chain-syncer`:
+Specify the functionality and interface `chain-syncer` has to expose in order to permit the `swap-daemon` to carry out swaps. Specify the type of jobs a `chain-syncer` has to implement in order to support executing both templates.
+
+### Libraries and Components
+  * `swap-lib`: includes stateless libraries that implement the core protocol, without runtime, disk, nor network implementation. Knows how to create and verify all the transactions involved in the protocol: it understands and handles the crypto verification, including adaptor signatures and DLEQ proofs across groups, and contains two templates for the pair of exchanging chains (Bitcoin-like and Monero-like). The goal of `swap-lib` is to facilitate integration of the base protocol logic of all pairs of chains that implement the two templates, such that adding a new pair, e.g., Litecoin/Monero, only requires implementing Litecoin for the Bitcoin-like template and an `ltc-chain-syncer` (see below).
+    * `btc-swap-lib`: an implementation for Bitcoin-like template exchanging bitcoin for monero.
+    * `xmr-swap-lib`: an implementation for Monero-like template exchanging monero for bitcoin.
+
+  * `swap-daemon`: implements a daemon, based on `swap-lib`, uses `chain-syncer` as interface to the blockchain world, has the full picture of the state of the cross-chain-swap, as it's aware of the events on both chains and of exchange counterparty protocol messages, it fully understands the protocol, and contains the state machine to execute its respective role in the protocol.
+
+  * `swap-client`: used by the end-user to enter into the protocol, has access to secret keys, uses the `swap-daemon` to execute the protocol, and signs transactions when needed. `swap-client` trusts the daemon completely to execute the protocol on its behalf and to exchange protocol messages with the swap counterparty.
+    * `swap-cli`: end-user CLI client that binds to the daemon for executing swaps and reporting the state of an ongoing swap.
+    * `swap-gui`: minimal end-user GUI client that binds to the daemon for executing swaps and reporting the state of an ongoing swap.
+
+  * `chain-syncer`: connects and synchronizes the protocol universe to the blockchain universe by following its client's commands (`swap-daemon`). `chain-syncer` knows the transactions of interest based on what its client subscribes to and informs the client in case one of its transactions gets reorged away from the main chain. `chain-syncer` must guarantee to be online during the entire execution of the protocol, and carry out actions on behalf of its clients. It has the ability to play a job and respond with events.
+    * `btc-chain-syncer`: a `chain-syncer` connected to a Bitcoin full node, it takes jobs such as listening for transaction confirmation or event-driven transaction broadcast.
+    * `xmr-chain-syncer`: a `chain-syncer` connected to a Monero full node, it takes jobs such as listening for transaction confirmation.
+
+  * `xgroup-dleq-lib`: a cryptographic library implementing the [MRL-0010](https://www.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf) technical note. This library must support at least `secp256k1` and `ed25519` curves. `secp256kfun` will be used at first to speed-up the development and will later be replaced by a fork of `libsecp256k1` and `rust-secp256k1`. `dalek-cryptography` will be used for `ed25519` cryptography.
+
+  * `ecdsa-adaptor-sig`: a cryptographic library implementing ECDSA One-time VES over `secp256k1`. We are looking forward to how ["Add ecdsa_adaptor module"](https://github.com/jonasnick/secp256k1/pull/14) evolves and wait on this to add support in `rust-secp256k1`.
+
+Disclaimer: those cryptographic libraries will require review for being considered as safe-to-use in production.
+
+We're currently in discussions with potential academic collaborators to extend the formal coverage of the protocol and its publication. We're also in the process of publishing a preprint of the swap paper on the Cryptology ePrint Archive.
+
+The code will be released mainly under the `monero-rs` and `swap-rs` Github organisations.
+
+## Dependencies
+
+We describe here a list of cryptographic and protocol dependencies likely needed for achieving a complete implementation (some dependencies are readily available, others will have to be extended or newly developed):
+
+ * Monero library for block parsing and for transaction parsing, manipulation, and verification logic
+ * Bitcoin library for block parsing and for transaction parsing, signing, manipulation and verification logic
+ * RPC and ZMQ libraries for listening to bitcoin and monero nodes; allow reacting and broadcasting transactions depending on the protocol execution
+ * Discrete logarithm equality across `secp256k1` and `ed25519` groups library, as described in [MRL-0010](https://www.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf) technical note
+ * ECDSA One-time VES over `secp256k1` library as described in [One-Time Verifiably Encrypted Signatures A.K.A. Adaptor Signatures](https://github.com/LLFourn/one-time-VES/blob/master/main.pdf), for signing some parts of the bitcoin transactions
+ * ECDSA signing over `secp256k1` library, for signing bitcoin transactions
+
+**Currently available Monero dependencies:**
+  * monero (https://github.com/monero-project/monero)
+  * monero-rs (https://github.com/monero-rs/monero-rs)
+  * monero-rpc-rs (https://github.com/monero-ecosystem/monero-rpc-rs)
+
+**Currently available Bitcoin dependencies:**
+  * bitcoin-core (https://github.com/bitcoin/bitcoin)
+  * rust-bitcoin (https://github.com/rust-bitcoin/rust-bitcoin)
+  * rust-bitcoincore-rpc (https://github.com/rust-bitcoin/rust-bitcoincore-rpc)
+  * libsecp256k1 (https://github.com/bitcoin-core/secp256k1)
+  * rust-secp256k1 (https://github.com/rust-bitcoin/rust-secp256k1)
+  * secp256kfun (https://github.com/LLFourn/secp256kfun); for ECDSA One-time VES over `secp256k1` signing implementation and prototyping DLEQ proofs
+
+**Currently available general dependencies:**
+  * rust-zmq (https://github.com/erickt/rust-zmq)
+  * rust-libp2p (https://github.com/libp2p/rust-libp2p); as an option for daemon peer-to-peer communication
+  * dalek-cryptography (https://github.com/dalek-cryptography); for `ed25519` arithmetic/curve operations
+
+## Milestones
+
+We split the principal milestones (1, 2, and 3) into unordered sub-milestones, each releasing a fraction of the total funds for their principal milestone.
+
+The goal is to share the advance of each individual sub-milestones in biweekly progress reports.
+
+![Milestone structure](https://codimd.s3.shivering-isles.com/demo/uploads/upload_7e18990edf9fa4fbf3ddbe0125e8d105.png)
+
+### Milestone 1 (specs): 20% [6 weeks]
+
+ * **Technical specifications:** a list of specifications that covers all aspects of the protocol, resembling specifications such as BOLT for Lightning network or Cryptonote.
+ 
+The specifications will demarcate which functionality falls in scope of the implementation in Milestone 2, and which functionality will be postponed to Milestone 3.
+ 
+
+#### A. Specification of `swap-daemon`
+Detailed description and specification of the `swap-daemon`, internal and external.
+
+#### A.1 User-facing [35% of M1] [2 weeks]
+* Specify `swap-daemon`'s outer API layer of user interaction (`swap-client`s & counterparty `swap-daemon`) first to guide design of inner dependencies (`swap-lib` & `chain-syncer`) to match desired UX. This includes protocol messages exchanged between swap participants, that is: interactions with the counterparty `swap-daemon`.
+* Specify the API that `swap-cli` and `swap-gui` consume from `swap-daemon`.
+* Specify the networking stack between `swap-daemon` and: `swap-daemon` counterparty and `swap-client`s.
+
+#### A.2 Service internals [16.25% of M1] [1 week]
+Specify links between `swap-daemon` and the other deliverables it requires to facilitate a swap, but that are not user-facing, i.e. `swap-lib` and `chain-syncer`s:
+* Specify the subset of `swap-lib`'s API strictly required for `swap-daemon`'s operation
+* Specify API and network stack for `swap-daemon`'s required calls to `chain-syncer`s
+
+#### B. Specification of `swap-lib` (core protocol)
+Detailed description and specification of all the libraries that, in conjunction, form `swap-lib`, including stateless transaction construction libraries, crypto-libraries and their wrappers, and state-machine libraries for executing the protocol.
+
+#### B.1 External specification of `swap-lib` [16.25% of M1] [1 week]
+* Specify `swap-lib`'s public API to be consumed by `swap-daemon` only.
+Preliminarily, covers `InitTx()`, `VrfyTx()`, `Vrfy()`, and `EncVrfy()` from the whitepaper.
+* Specify `swap-lib`'s public API to be consumed by `swap-client`s only.
+Preliminarily, covers `Sign()`, `EncSign()`, `DecSig()`, `RecKey()`, and `Rec()` from the whitepaper.
+* Specify `swap-lib`'s public API to be consumed by both `swap-daemon` and `swap-client`s.
+
+#### B.2 Internal specification of `swap-lib` [16.25% of M1] [1 week]
+* Specify internal function calls of `swap-lib`.
+* Specify a concrete implementation to support a chain, including all cryptographic primitives that must be supported.
+
+#### C. Specification of `chain-syncer` [16.25% of M1] [1 week]
+* Specify the functionality and interface `chain-syncer` has to expose in order to permit the `swap-daemon` to carry out swaps. Describe what jobs are, and what jobs must be supported.
+* Specify the networking stack between `swap-daemon` and `chain-syncer`s.
+
+A core goal of the spec-writing process is to ensure that the deliverables are compatible and functional in the sum of their parts. This process in Milestone 1 thus aims to identify limitations of the architecture presented in this proposal, which can impact the structure of Milestones 2 and 3. In case changes are consequently required, we will propose them to the community at the completion of Milestone 1, and we will ensure that the same final functionality as set out in this proposal will be delivered.
+
+### Milestone 2 (implementation of core architecture): 45% [14 weeks]
+
+ * **Minimal functionality:** at completion-time of milestone 2, all components for executing atomic swaps successfully are implemented using our libraries as proposed in the presented architecture.
+ * **BETA STATE:** the software released is considered to be beta software and not ready for deployment.
+
+This milestone achieves the initial implementation of all the components (without GUI client) interacting with each other. It implements only the minimally required functionalities specified in the specifications (Milestone 1).
+
+
+#### A. Cryptographic libraries [7.5% of M2] [1 week]
+For milestone 2 we intend to use Lloyd's experimental library for ECSA adaptor signatures (`ecdsa-adaptor-sig`) and DLEQ proofs (`xgroup-dleq-lib`).
+
+We postpone the integration of a production-grade ECDSA adaptor signatures to the end of the project, namely milestone 3, as it is highly complex, and this gives tooling more time to mature. In case Bitcoin incorporates Schnorr signatures soon (BIP 340), ECDSA adaptor signatures may also not be needed and would then be replaced with Schnorr adaptor signatures.
+
+At completion, we provide generic cryptographic libraries that expose a high level API, comparable to how `rust-secp256k1` exposes a high level API for ECDSA signatures over `secp256k1`.
+
+#### A.1 `xgroup-dleq-lib`
+Experimental discrete-log equality across groups library using secp256kfun. At completion, this library enables zk-proving discrete log equality across groups `secp256k1` and `ed25519` for arbitrary private keys.
+
+#### A.2 `ecdsa-adaptor-sig`
+Experimental ecdsa-adaptor signature library using secp256kfun. At completion, this library enables producing and verifying ecdsa-adaptor signatures, and extracting secrets from clear and encrypted signatures.
+
+#### B. `swap-lib` [25% of M2] [4 weeks]
+`swap-lib` is the core for adding support for a new chain, either via the Bitcoin-like template or the Monero-like template. At completion, this library is an interface for enforcing the requirements of `swap-daemon` and `swap-client` for a selected chain, and the requirements for each `chain-syncer` type.
+
+#### B.1 `xmr-swap-lib`
+A concrete implementation of `swap-lib` that allows the creation of a `swap-daemon` and a `swap-client` for exchanging monero for bitcoin.
+
+#### B.2 `btc-swap-lib`
+A concrete implementation of `swap-lib` that allows the creation of a `swap-daemon` and a `swap-client` for exchanging bitcoin for monero.
+
+#### C. `swap-client`s [12.5% of M2] [2 weeks]
+At completion of Milestone 2, we provide only the `swap-cli` client.
+
+#### C.1 `swap-cli`
+A CLI client utilizing `swap-daemon`'s API for executing swaps. At completion, a minimal CLI client for running Bitcoin and Monero swaps will be delivered.
+* `swap-cli` can initialize a `swap-daemon` with parameters for a swap (swap-pair, swap-direction, counterparty daemon address, swap-amount, exchange-rate).
+* `swap-cli` can sign transactions the `swap-daemon` provides.
+* `swap-cli` sends signed transactions back to the `swap-daemon`.
+
+#### D. `swap-daemon` [30% of M2] [4 weeks]
+At completion, `swap-daemon` enables `swap-client` to successfully swap bitcoin for monero. 
+
+It coordinates all aspects of the swap by communicating with `swap-client`, `chain-syncer`s and the counterparty's `swap-daemon`. It exposes an RPC server for client interaction. 
+
+At this stage:
+  - `swap-daemon` understands the semantics of all the public keys, unsigned, signed and partially-signed transactions, hash pre-images, and encrypted signatures involved in the protocol.
+  - has the full picture of the state of the cross-chain-swap, as it's aware of the events on both chains; each `chain-syncer` only has a partial view. `swap-daemon` knows the off-chain events as well.
+  - protocol implemented in 2 varieties: (1) one for executing btc-sender/xmr-receiver protocol (`btc->xmr`) and (2) another for xmr-sender/btc-receiver protocol (`xmr->btc`). In conjunction these 2 protocols cover the full protocol. 
+  - at run-time, each `swap-daemon` instantiates a state-machine of only one of the varieties: either `xmr->btc` or `btc->xmr`.
+  - at run-time, the daemon can start in a master or slave mode. In master mode, `swap-daemon` accepts entering connections, in slave mode `swap-daemon` tries to connect to a counterparty daemon.
+  - reveals a high level API that lets `swap-client`s run the protocol.
+
+#### E. `chain-syncer`s [25% of M2] [3 weeks]
+At completion, `chain-syncer` exposes enough functionality to permit the `swap-daemon` to carry out swaps between Monero and Bitcoin. It does not publish transactions on behalf of its client yet (e.g. `do X once Y`), just listens to transactions of interest and blocks, process them and push events to the `swap-daemon` (i.e. `chain-syncer`'s client). It also exposes functionality for clients to publish transactions to the blockchain, if needed.
+
+All `chain-syncer`s implement the base functionality:
+* interface to `swap-daemon`
+* read transactions (arriving in the mempool, or with a number of confirmations)
+* read new blocks
+* detect block re-orgs
+
+#### E.1 `btc-chain-syncer`
+A bitcoin concrete implementation of the `chain-syncer`.
+In addition to the base functionality, `btc-chain-syncer`:
+* connects to bitcoin full-node
+* broadcasts transactions
+
+#### E.2 `xmr-chain-syncer`
+A monero concrete implementation of the `chain-syncer`.
+In addition to the base functionality, `xmr-chain-syncer`:
+* connects to monero full-node
+
+### Milestone 3 (minimum viable product): 35% [12 weeks]
+
+ * **Full integration of individual components:** the entire functionality as defined in the specs is now implemented.
+ * **MVP STATE:** the software released is considered as stable for a minimum viable product.
+
+At this stage, we replace/finish some components of Milestone 2 with MVP grade components, meaning all features specified in Milestone 1 are implemented.
+
+#### A. Cryptographic libraries
+At completion of this task, cryptographic libraries should benefit from more reviewed and more stable codebases.
+
+#### A.1 `xgroup-dleq-lib` [25% of M3] [3 weeks]
+We upgrade `xgroup-dleq-lib` to use `rust-secp256k1` (fork or mainstream) and dalek. The goal is to implement in C in `libsecp256k1` the high level API needed for cross group discrete logarithm equality proofs with `secp256k1` curve and update `rust-secp256k1` bindings (fork or mainstream).
+
+#### A.2 `ecdsa-adaptor-sig` [25% of M3] [3 weeks]
+We upgrade `ecdsa-adaptor-sig` to use `rust-secp256k1` (fork or mainstream), based of the C implementation in `libsecp256k1` currently in progress [here](https://github.com/jonasnick/secp256k1/pull/14).
+
+#### B. `chain-syncer` [15% of M3] [2 week]
+We upgrade the `chain-syncer`s to enable pattern such as: `do X if Y`. This allows other daemon requirements to be supported, i.e. a daemon can be written such that going offline for a small amount of time is not problematic, allowing e.g. mobile daemons.
+* `swap-daemon` can queue tasks such as `execute refund path at block height X` with a `chain-syncer`.
+
+#### C. `swap-client`s
+We improve `swap-cli` and release a new web-based GUI client, `swap-gui`.
+
+#### C.1 `swap-cli` [10% of M3] [1 week]
+`swap-cli` exposes additional functionality and better UI/UX:
+* during a swap, `swap-daemon` relays to `swap-cli` what actions are currently available to `swap-cli`, and future actions that will become available after `n` blocks.
+* `swap-daemon` pushes updates to `swap-cli`, in lieu of the `swap-cli` pulling from the `swap-daemon`.
+* `swap-cli` can schedule actions to be performed by `chain-syncer`s, as via the upgrade specified in M3.B.
+
+#### C.2 `swap-gui` [15% of M3] [2 weeks]
+A minimal web-based GUI client, `swap-gui`. Cryptographic requirements will be fulfilled with WASM or might be embedded as native libraries on an Electron webapp.
+* `swap-gui` covers the functionality of `swap-cli` as implemented at the end of M2.
+* web-based GUI that interacts with `swap-daemon` API.
+
+#### D. `swap-daemon` [10% of M3] [1 weeks]
+Implements all features defined in the specification for `swap-daemon`.
+
+## Cost
+We ask for 2727 XMR from CCS.
+
+For further information on our crowdfunding, please visit https://cryp.ee/crowdfund or write to us at crowdfund@cryp.ee (PGP fingerprint `A873 CF81 AAFE C016 EC1A  14BB D889 86F7 A3F7 37C4`[^2]).
+
+## Feedback
+Due to the size of this project and the funding required for it, questions, comments, and feedback regarding this request are very welcome.
+
+### Communication channel
+Besides the MR comments on GitLab and the Monero IRC channels such as `#monero-community` and `#monero-research-lab`, we opened the `#monero-swap` IRC channel for crowdfunding questions, project updates, and work management during the development time-frame.
+
+We commit to make ourselves highly available for the community of researchers and developers, such as participating in MRL meetings, sharing progress, incorporating/giving feedback from/to the community in general, and responding to general inquiries, if they fall under our expertise.
+
+[^1]: A plausible extension path towards a generic interface is to initialize the daemon with a Petri net representation of a protocol, together with a set of places that the client is in control of - in lieu of them choosing a role from n-ary options.
+[^2]: Full PGP key for crowdfund@cryp.ee:  
+`-----BEGIN PGP PUBLIC KEY BLOCK-----`  
+`Version: OpenPGP.js v4.10.8`  
+`Comment: https://openpgpjs.org`  
+`xjMEX4G6hRYJKwYBBAHaRw8BAQdAyb5mTWxnbmIqpRExJbZPg6McQK/nTFF0`  
+`kgLd20WRMlbNJWNyb3dkZnVuZEBjcnlwLmVlIDxjcm93ZGZ1bmRAY3J5cC5l`  
+`ZT7CjwQQFgoAIAUCX4G6hQYLCQcIAwIEFQgKAgQWAgEAAhkBAhsDAh4BACEJ`  
+`EF+QaJfwBcaZFiEE55TK0pvlX5ijxFP+X5Bol/AFxpldtgEAlNrZjg5XRDdl`  
+`SmPFZQWvCenIgRXnxe9G4BD529yz5zsA/0/xmq7N19VfpjOecoKl+vyxBBsq`  
+`HiZ6zTNGzeBhr7gEzjgEX4G6hRIKKwYBBAGXVQEFAQEHQL5lk0xlsP59tESA`  
+`h9L8GhCAt5xdOFbYLf7jGyUpjLp3AwEIB8J4BBgWCAAJBQJfgbqFAhsMACEJ`  
+`EF+QaJfwBcaZFiEE55TK0pvlX5ijxFP+X5Bol/AFxpncCwEAm9hTDBjRgOIC`  
+`nZs+2mgmDH0kCAsgwNCLmILfeZ1vbHwBAOwIZgrS74gFKsaeToDoizbF8ecW`  
+`YqxRx7GzcX0NYoUK`  
+`=oDUJ`  
+`-----END PGP PUBLIC KEY BLOCK-----`

h4sh3d-atomic-swap-research.md

+---
+layout: cp
+title: "Monero Atomic Swaps research funding"
+author: h4sh3d
+date: 19 May 2020
+amount: 18
+milestones:
+  - name: Work is done
+    funds: 100% (18 XMR)
+    done: 26 August 2020
+    status: finished
+payouts:
+  - date: 27 August 2020
+    amount: 18
+---
+
+# Monero Atomic Swaps research funding
+
+From [https://github.com/h4sh3d/xmr-btc-atomic-swap](https://github.com/h4sh3d/xmr-btc-atomic-swap):
+
+> In blockchains where hashed timelock contracts are doable atomic swaps are already deployed, but when one blockchain doesn't have this capability it becomes a challenge. This protocol describes how to achieve atomic swaps between Bitcoin and Monero with two transactions per chain without trusting any central authority, servers, nor the other swap participant.
+
+## Motivation:
+
+Two years ago (Dec 2017), I published a draft to swap between Bitcoin and Monero.
+
+In March 2019 I rewrote the protocol in more details, specifying what kind of zero-knowledge proofs were needed to guarantee the "trustlessness" of the protocol and the known limitations of the scheme, funded by my previous employer.
+
+zkao and I presented the protocol at 36C3 in December 2019 ([link here](https://www.youtube.com/watch?v=G-v6hDnzpds)). After discussing it during March and April on #monero-research-lab IRC, andytoshi's idea of using "discrete logarithm equality across groups" that sarang has a write-up [here](https://web.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf), I changed the zero-knowledge requirements by adapting the protocol, but the protocol, thus on-paper complete, was still not implementable as it used an inactive bitcoin op-code: `OP_AND`.
+
+Recently I learned some new cryptographic tricks with ECDSA that should make the protocol complete and implementable with today's tools without requiring hash pre-image zero knowledge proofs.
+
+**This research will update the draft protocol to completely remove hash pre-image zero-knowledge proof requirement.**
+
+So far, I've carried out the latest research on my spare time. I can now use part of my working time to continue. My company has an internal budget for doing research, and because it's my first funding request, it will match the raised funds. Thus I will request 1/2 week of funding from the community, and will spend 1 week working on this project.
+
+## Overview:
+
+R & D Institution: Cryp GmbH (I work and own part of the company)
+
+Funding: Monero CCS
+
+Duration: 40 hours of research (of which 20h paid by community)
+
+Job completion: Within 2 months after successful funding
+
+Contributors:
+
+ * Principal researcher: h4sh3d
+ * Supervisor: zkao
+
+Licences: All work will released under CC-BY-4.0
+
+Expiration date: If not funded or completed until July 31, 2020 funds can be released
+
+## Project Roadmap:
+
+One week of research and writing.
+
+### Deliverable:
+
+ * **Revised version of "Bitcoin--Monero Cross-chain Atomic Swap":** new version with updated cryptographic primitives and protocol variation
+
+## Cost
+
+I ask for the equivalent of 1200 USD from CCS.
+
+Therefore, using a 7-day EMA of 66.21 USD/XMR from Kraken the request total is __18.~~12~~ XMR__.
+
+## Feedback
+
+First CCS, so questions, comments, and feedback regarding this request are very welcome.

haveno-frontend.md

+---
+layout: fr
+title: Haveno frontend development
+author: Haveno
+date: Mar 16, 2022
+amount: 755 XMR
+milestones:
+  - name: Month 0
+    funds: 151 XMR
+    done:
+    status: unfinished
+  - name: Month 1
+    funds: 151 XMR
+    done:
+    status: unfinished
+  - name: Month 2
+    funds: 151 XMR
+    done:
+    status: unfinished
+  - name: Month 3
+    funds: 151 XMR
+    done:
+    status: unfinished
+  - name: Month 4
+    funds: 151 XMR
+    done:
+    status: unfinished
+  
+payouts:
+  - date:
+    amount:
+---
+
+Hello again everyone. As promised, after improving Haveno's structure, we come back with a new (much cheaper) CCS proposal.
+
+For a complete picture and all details, [see our initial proposal](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/284), which assumed the old structure with centralized operators.
+
+This is the blog post announcing Haveno's improved structure: https://haveno.exchange/2022/02/02/haveno-structure.html.
+
+## The new structure
+
+For details about Haveno's structure, please read carefully the blog post linked above. For convenience, here is a short summary:
+
+- No more third party entity that will run the exchange. Everything will be managed by non-legal entity for more robustness and decentralization
+
+- All fees paid on Haveno will be sent to 'Engine', a CCS-like structure that will fund Haveno and Monero development. It will work similarly to the CCS managed by the Monero Core Team (MCT), but instead of generous donors, the funds will be provided by the fees sent to Engine by Haveno.
+
+- The funds of Engine will be managed by an entity called 'Engine Council', formed by 5 trusted long term contributors of the dev community, including one member appointed by the Haveno Core Team (HCT) and one member of the MCT[1]. The remaining 3 members will be chosen from a pull of candidates by the Haveno and Monero communities.
+
+- The HCT will request monthly 50% of the funds sent to Engine.
+
+- To avoid liabilities and legal structures, the members of Council will vote anonymously [using ring signatures](https://github.com/monero-project/urs) to ensure plausible deniability.
+
+- Arbitrators will be chosen using Engine and will not be picked by the HCT. This allows to open a market of arbitrators, where Monero and Haveno community members can propose themselves for the role. There will be security mechanisms in place to avoid arbitrators colluding with traders, but that's out of scope for this CCS.
+
+[1] We already contacted the Monero Core Team about this structure and they say they are happy with Haveno's model and are willing to have one of their members join the Engine Council. They point out that this individual should not be interpreted as representing the views of the Core Team directly and if direct MCT input is required, they will discuss internally.
+
+## How much and for what
+
+We are asking for **154k USD in XMR**. The money will be used **entirely to pay for the frontend development of Haveno**. This is the estimated cost to complete the frontend. We are already in contact with a team of three devs, which will start working on Haveno as soon as this CCS is accepted.
+
+The cost is lower than in the past proposal, because the team will develop only the frontend as requested, so extra work (in case of changed or additional requirements) is not included. The HCT will be deeply involved, trying to keep costs as low as possible, but the support of our dev community will be greatly appreciated.
+
+## Milestones and terms
+
+Payments to the frontend team will be every completed sprint. Every sprint will be a task that will take about 2 weeks to complete. For simplicity, we ask the funds to be sent to us every month for 4 months, with the first reward being sent as soon as our proposal is funded. The community will be able to follow the development in the public GitHub repository and on the community channels.
+
+To recap:
+
+- 1st payment: As soon as the proposal is moved to the "In progress" phase.
+- 2nd payment: 1 month after the first payment
+- 3rd payment: 1 month after the second payment
+- 4th payment: 1 month after the third payment
+- 5th payment: 1 month after the 4th payment. Last payment.
+
+The community will be able to follow progresses on Github and on our matrix/irc chatrooms. We hope the development of the frontend will be finished within 4-6 months.
+
+Haveno Core Team  
+[haveno.exchange](https://haveno.exchange)

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

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

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

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

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

+---
+layout: cp
+title: Translation of GUI Wallet, monero-site, Monero Means Money (subtitles), Sound Money, Safe Mode (subtitles) to Polish.
+author: janowitz
+date: November 30, 2020
+amount: 22
+milestones:
+  - name: Milestone 1 - Completion of GUI Wallet, monero-site Translation to Polish
+    funds: 4 XMR
+    done: 20 April 2021
+    status: finished
+  - name: Milestone 2 - Completion of Monero Means Money (subtitles) Translation to Polish
+    funds: 9 XMR
+    done: 15 July 2021
+    status: finished
+  - name: Milestone 3 - Completion of Sound Money, Safe Mode (subtitles) Translation to Polish
+    funds: 9 XMR
+    done: 25 August 2021
+    status: finished
+payouts:
+  - date: 26 August 2021
+    amount: 22
+---
+
+# About this Proposal
+
+Translation of the [GUI Wallet](https://translate.getmonero.org/projects/monero/gui-wallet/), [monero-site](https://translate.getmonero.org/projects/getmonero/monero-site/), [Monero Means Money (subtitles)](https://translate.getmonero.org/projects/community/monero-means-money/) and [Sound Money, Safe Mode (subtitles)](https://translate.getmonero.org/projects/community/sound-money-safe-mode-subtitles/) to Polish.
+
+# About Me
+
+Hey, I'm Paul Janowitz and have been around in the Bitcoin space from 2012, came into Monero in 2016, some will recognise me from Twitter, Reddit, IRC or moderating the Telegram groups (where I had to step down unfortunately due to lack of time).
+
+I have already contributed lots of translations into Polish and German (where I'm both native speaker) on the old system and also on Weblate in my free time whenever possible. The GUI translation into Polish doesn't need much work any more, but the website still does. If the proposal will not get fully funded, I will proceed according to the milestones listed below, since the subtitles are a nice to have but I don't see them as crucial like the GUI and website.
+
+I am submitting this proposal since I think to bring both the experience and already have proven to be willing to contribute my time to the project.
+
+### Links
+
+- [Monero Project Translations (Weblate)](https://translate.getmonero.org/user/janowitz/)
+- [Monero's GitLab](https://repo.getmonero.org/janowitz)
+- [Twitter profile](https://twitter.com/janowitz)
+- [Reddit profile](https://www.reddit.com/user/pebx)
+
+# Milestones and Projected Timeline
+
+## Milestone 1 - Completion of GUI Wallet, monero-site Translation to Polish
+
+Complete translation of the [GUI Wallet](https://translate.getmonero.org/projects/monero/gui-wallet/) and [monero-site](https://translate.getmonero.org/projects/getmonero/monero-site/).
+
+Comprises of 5,943 words, which equals to 5 XMR.
+
+Timeline: 14/12/2020 - 27/12/2020
+
+## Milestone 2 - Completion of Monero Means Money (subtitles) Translation to Polish
+
+Complete translation of the [Monero Means Money (subtitles)](https://translate.getmonero.org/projects/community/monero-means-money/)
+
+Comprises of 11,689 words, which equals to 11 XMR.
+
+Timeline: 28/12/2020 - 10/01/2021
+
+## Milestone 3 - Completion of Sound Money, Safe Mode (subtitles) Translation to Polish
+
+Complete translation of the [Sound Money, Safe Mode (subtitles)](https://translate.getmonero.org/projects/community/sound-money-safe-mode-subtitles/)
+
+Comprises of 12,404 words, which equals to 12 XMR.
+
+Timeline: 11/01/2021 - 24/01/2021
+
+**Proposal Expiration Date**: 14/12/2020

john-foss-the-monero-moon.md

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

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

 ---
-layout: fr
+layout: cp
 title: knueffelbund GUI design for Q2 2019
 author: knueffelbund
 date: 3 April 2019
 amount: 37
 milestones:
-  - april:
+  - name: April
     funds: 33% (12 XMR)
-    done:
-    status: unfinished
-  - may:
+    done: 30 April 2019
+    status: finished
+  - name: May
     funds: 33% (12 XMR)
-    done:
-    status: unfinished
-  - june:
+    done: 13 May 2019
+    status: finished
+  - name: June
     funds: 33% (13 XMR)
-    done:
-    status: unfinished
+    done: 30 June 2019
+    status: finished
 payouts:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
+  - date: 8 August 2019
+    amount: 37
 
 
 ---

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

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: wip
+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:
+    status: unfinished
+  - name: Milestone 2 - Translation and proofreading of the GUI and CLI wallets
+    funds: 41.67% (5 XMR)
+    done:
+    status: unfinished
+  - name: Milestone 3 - Translation and proofreading of the user guides
+    funds: 25% (3 XMR)
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+## 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-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