avis-translation-fixed.md

+---
+layout: fr
+title: "Norwegian translation of webplate, footers, nav menu"
+author: Chris Avis
+amount: 6
+milestones:
+  - name: Translation of all words
+    funds: 6
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+---
+
+
+This is a proposal to translate the core part of the website (7615 words), navigation menu (147 words), footer 1 (142 words) & 
+footer 2 (5 words) to Norwegian, amounting to 7909 words. I think that those Norwegians who are not as sturdy in English will 
+appreciate being able to learn what Monero is about in their native language. I would like to help facilitate this and to 
+make sure they understand Monero better by providing a solid translation.
+
+About one month ago I translated the GUI wallet to Norwegian. I spent quite some time on this translation as I 
+wanted everything to be right, and it seems that the reviewers were pleased with my work. I previously asked for 
+3 XMR to translate the GUI wallet (3489 words). Given the same XMR/word ratio, this equates to just below 7 XMR.
+
+To compensate for values that should not have been counted in my text editor, I suggest deducting 1 XMR for this, so I 
+ask for a final amount of 6 XMR. The translation will consist of one milestone – the translation of all 7909 words. I will translate 
+the content and I expect to use 3-4 days on translating this.
\ No newline at end of file

avis-web-norwegian.md

+---
+layout: fr
+title: "Norwegian web translation"
+author: Chris Avis
+amount: 6
+milestones:
+  - name: Translation of all words
+    funds: 6
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+---
+
+This is a proposal to translate the core part of the website (7615 words), navigation menu (147 words), footer 1 (142 words) & 
+footer 2 (5 words) to Norwegian, amounting to 7909 words. I think that those Norwegians who are not as sturdy in English will 
+appreciate being able to learn what Monero is about in their native language. I would like to help facilitate this and to 
+make sure they understand Monero better by providing a solid translation.
+
+About one month ago I translated the GUI wallet to Norwegian. I spent quite some time on this translation as I 
+wanted everything to be right, and it seems that the reviewers were pleased with my work. I previously asked for 
+3 XMR to translate the GUI wallet (3489 words). Given the same XMR/word ratio, this equates to just below 7 XMR.
+
+To compensate for values that should not have been counted in my text editor, I suggest deducting 1 XMR for this, so I 
+ask for a final amount of 6 XMR. The translation will consist of one milestone – the translation of all 7909 words. I will translate 
+the content and I expect to use 3-4 days on translating this.
\ No newline at end of file

binarybaron-unstoppableswap.md

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

boog_2_months_cuprate.md

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

boog_3_months_cuprate.md

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

boog_3_months_cuprate_2.md

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

boog_3_months_cuprate_3.md

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

bulletproofs-plus-audit-jp.md

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

bulletproofs-plus-audit.md

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

bulletproofs-pp-peer-review.md

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

busyboredom-standalone-acceptxmr.md

+---
+layout: wip
+title: Standalone AcceptXMR
+author: busyboredom
+date: February 31, 2023
+amount: 44
+milestones:
+  - name: Dockerize AcceptXMR
+    funds: 14
+    done: 5 July 2024
+    status: finished
+  - name: Wordpress Plugin
+    funds: 10
+    done:
+    status: unfinished
+  - name: Maintenance 1 year
+    funds: 20
+    done:
+    status: unfinished
+payouts:
+  - date: 19 July 2024
+    amount: 14
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+_Note: this proposal has been awarded 30 XMR from [xmrSale](https://ccs.getmonero.org/proposals/xmrsale-2021.html)_
+
+# Standalone AcceptXMR
+Another payment gateway CCS proposal.
+
+## Summary
+I would like to create a standalone, dockerized, AcceptXMR-based payment gateway with wordpress
+support.
+
+AcceptXMR ([demo](https://busyboredom.com/projects/acceptxmr),
+[docs](https://docs.rs/acceptxmr/latest/acceptxmr/),
+[repo](https://github.com/busyboredom/acceptxmr/)) is a payment gateway library (or crate, in rust
+lingo) I wrote as a hobby project and have made available to the community. While my library serves
+its purpose well, I understand that most merchants are not programmers therefor cannot use
+AcceptXMR.
+
+This proposal aims to make AcceptXMR usable for anyone capable running a docker container and
+installing a wordpress plugin.
+
+## Why AcceptXMR
+Lots of reasons!
+* View pair only, no hot wallet.
+* Subaddress based (as opposed to the older integrated addresses).
+* Pending invoices can be stored persistently, enabling recovery from power loss.
+* Ignores transactions with non-zero timelocks.
+* Zero-conf works out of the box.
+* No local node, wallet RPC, or block explorer needed. Just pick a public remote node.
+
+And of course, I am already intimately familiar with it.
+
+## How It'll Happen
+I will dedicate a portion of my weekends (you can expect about 10 hours a week on average) to
+completing the following milestones. There will be some weeks with more progress and others with
+less, but that's the average I'll be aiming for.
+
+### Dockerize AcceptXMR
+_14 XMR from xmrSale's abandoned funding._
+
+This is the largest milestone. I'll be taking the webserver and frontend work you see in my demo,
+cleaning it up significantly to bring it up to production standards and dockerizing it for easy
+setup. I will also provide documentation on how to perform that setup.
+
+### Wordpress Plugin
+_10 XMR from xmrSale's abandoned funding._
+
+Wordpress is popular, and it has a plugin system that supports custom payment gateways. I will write
+a wordpress plugin for the freshly dockerized AcceptXMR implementation. I will also provide
+documentation on how to use the plugin.
+
+### Maintenance for 1 Year
+_20 XMR total, with 6 XMR coming from xmrSale's abandoned funding and the remaining 14 XMR coming
+from this CCS proposal._
+
+Both rust and monero have rapidly changing ecosystems. Left alone, my work would likely be out of
+date by the end of the year due to breaking changes in my library's dependencies if nothing else.
+Keeping AcceptXMR up-to-date and functional is something I currently do for free, but building out a
+full standalone gateway adds overhead. For this reason, I've bookmarked 20 XMR for maintenance for 1
+year from the funding date.
+
+I am hesitant to provide target dates for first  two milestones above, but I have been maintaining
+AcceptXMR for over a year now and I don't plan on ghosting on it now.
+
+## Stretch Goals / Future work
+I'm not promising any of the following happens, but I'm putting it here to let the community know
+it's on my radar and I want to do it if I get the opportunity:
+* TOR support for the daemon RPC connection.
+* A no-JS frontend. I have an example with this implemented on github, but I'll have to clean it up
+a bit and integrate it into the new dockerized setup.
+* ZMQ support as a more performant alternative to polling the remote node.
+
+## Prerequisites
+Before I start work on this CCS, I'll need to wrap up changes I'm making with v0.12.0 of AcceptXMR.
+I'm not charging for that work, I'm just disclosing here that I need to resolve the issues in that
+milestone before I start work on this CCS.
+
+## License
+AcceptXMR is dual-licensed under the MIT and Apache 2.0 licenses. I am not planning on changing the
+license. It will always be under a permissive license.
+
+## About Me
+Busyboredom is _not_ an anonymous alias, you can see my minimally-redacted resume on my personal
+website [busyboredom.com](https://busyboredom.com).
+
+Proposal Expiration: January 1st, 2025.
+
+Note: This CCS was originally intended to be funded entirely by the 30 XMR leftover from the abanoned
+xmrSale project. At the request of the community, I have extended my maintenance commitment and
+increased the maintenance budget by 14 XMR. This change allows CCS donors to act as a final check on
+whether this proposal goes forward.

ccs-coordinator-5-plowsof.md

+---
+layout: wip
+title: CCS Coordinator
+author: plowsof
+date: September 14, 2024
+amount: 99.0
+milestones:
+  - name: Month 1
+    funds: 33.0
+    status: finished
+    done: 22 November 2024
+  - name: Month 2
+    funds: 33.0
+    status: finished
+    done: 16 February 2025
+  - name: Month 3
+    funds: 33.0
+    status: unfinished
+    done:
+payouts:
+  - date: 6 December 2024
+    amount: 33.0
+  - date: 26 February 2025
+    amount: 33.0
+  - date:
+    amount: 33.0
+---
+
+# Who?
+
+Hello, plowsof here, I show up and try to be helpful. My [previous](https://ccs.getmonero.org/proposals/plowsof-com-rel.html) [proposals](https://ccs.getmonero.org/proposals/plowsof-ccs-coordinator-2.html) [happened](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/418), [previously](https://ccs.getmonero.org/proposals/plowsof-ccs-coordinator-4.html). I would like to make it happen again, and do more of the same things.
+
+# What?
+
+- Gather consensus for CCS proposals. (feedback from GitLab/IRC/Reddit).
+- Organise bi-weekly meetings to discuss proposals / current events (more if necessary).
+- Provide decisions in 1 month or less (Yes/No to being funded or if something has to be changed with the proposal to satisfy our community).
+- Be impartial when communicating with CCS proposers - everyone gets a fair shake.
+- Checking up on the WIP list to find / fix problems early (e.g. payments overdue or proposers AWOL).
+- Take responsibility for the entire CCS process - It's my fault when 'things go wrong'.
+- Someone who is online for several hours a day / 7 days a week that knows what's going on.
+- Act as a liaison to Core - keep them informed of whats happening / poke them when required / handle their requests.
+    - As part of this CCS, you will also be sponsoring my work when quality assurance testing new features/bug fixes each release cycle in the GUI, CLI, and RPC wallets.
+    - And Getmonero.org contributions.
+- Consultancy before / during / after the idea stage.
+- Secretarial tasks for https://bounties.monero.social/ (requesting payouts upon completion of bounties and such)
+
+# Funding
+
+Work for 25 hours per week over the next 3 months (from September to end of November 2024) at a rate of 45€ / hour. At 147.94€ / XMR (90-day EMA) this makes ~99.0 XMR.

ccs_test_update.md

+---
+layout: cp
+title: "Do they know its CCSmas time again?"
+author: plowsof
+date: December 25th 2023
+amount: 0.069
+milestones:
+  - name: 3+ months of transaction fees
+    funds: 0.069 XMR
+    done: 28 December 2023
+    status: finished
+payouts:
+  - date:
+    amount: 0.069
+---
+
+## Update 
+
+We're back! here is a brief summary of events before we get testing:
+
+- After the [CCS wallet was drained](https://github.com/monero-project/meta/issues/916) a Vote was held to determine if luigi [should continue as an escrow](https://github.com/monero-project/meta/issues/935).
+- Feedback obtained from the community determined how the new CCS wallet would be created/used in a secure manner;
+    - A new, single-purpose, air-gapped laptop was purchased (bluetooth/wifi disabled).
+    - The OS is Debian, and FeatherWallet will be used to sign and transport transaction files (via QR codes)
+	- Special thanks to tobtoht of FeatherWallet who worked tirelessly to push out a new version with convenient air-gapped signing capabilities, and every community member who offered feedback on how to best move forward.
+- The exact amount stolen + 21 XMR extra was sent to the General Fund ([X](https://twitter.com/WatchFund/status/1732391070216908886) / [nitter](https://nitter.net/WatchFund/status/1732391070216908886))
+- The machine where the drained wallet resided is being [forensically anaylised](https://github.com/monero-project/meta/issues/923) to determine if it was compromised. 
+- Luigi will escrow a temporary wallet until the [31st March 2024](https://github.com/monero-project/meta/issues/935#issuecomment-1867257410). 
+
+We must now begin to prepare for a 'post March 31st CCS' and wish everyone a merry RandomX'mas and a happy new year! 
+
+## Milestone 1
+
+Lets test the new CCS wallet by raising approx ~$12.16 / 0.069XMR to subsidise transaction fees for several hundred consolidations/payouts for the next 3 months. 

clsag-audit-take2.md

+---
+layout: cp
+title: CLSAG Audit
+author: Monero Audit Workgroup
+date: 4 June 2020
+amount: 179
+milestones:
+  - name: Audit amount
+    funds: 100% (179 XMR)
+    done: 15 June 2020
+    status: finished
+payouts:
+  - date: 15 June 2020
+    amount: 172.09664848
+  - date: 15 June 2020
+    amount: 6.90335152
+---
+
+This is the funding request for Monero Research Lab's Concise Linkable Ring Signatures (CLSAG) research. CLSAG promises to provide more efficient Monero transactions without sacrificing privacy. CLSAG improves Monero transactions with no meaningful disadvantages. It's a drop-in improvement for MLSAG like Bulletproofs was. CLSAGs require a hardfork to implement.
+
+The Monero Audit Workgroup cooperated with [OSTIF](https://ostif.org/) to create [this SoW](https://ia601504.us.archive.org/24/items/jp-ostif-clsag-signed/JP%20OSTIF%20CLSAG%20SIGNED.pdf) with [Teserakt](https://teserakt.io/). The Monero community has cooperated with OSTIF for the past [Bulletproofs](https://ostif.org/the-ostif-and-quarkslab-audit-of-monero-bulletproofs-is-complete-critical-bug-patched/) [audits](https://ostif.org/the-quarkslab-and-kudelski-security-audits-of-monero-bulletproofs-are-complete/) and [RandomX audits](https://ostif.org/four-audits-of-randomx-for-monero-and-arweave-have-been-completed-results/).
+
+The workgroup consists of the following members. They do not receive compensation:
+
+* ArticMine
+* binaryFate
+* Justin Ehrenhofer
+* Sarang Noether (abstained)
+* SerHack
+
+Cost breakdown:
+
+* Audit amount: $14,400
+* OSTIF fee (10%): $1,440
+* OSTIF audit credit: ($4,800)
+* Subtotal: $11,040
+* Buffer (10%): $1,104
+* Total: $12,144
+* XMR ($68): 179
+
+The credit is from excess from the last audit with OSTIF, and from a ~~$1650~~ $3,300 donation from Sweetwater Digital Asset Consulting, LLC.
+
+Teserakt has already begun working on this audit by their own decision.
+
+Any excess or shortfalls from volatility will be donated to or paid by the Monero General Fund.
\ No newline at end of file

clsag-audit.md

+---
+layout: fr
+title: CLSAG Audit
+author: Monero Audit Workgroup
+date: 4 June 2020
+amount: 
+milestones:
+  - name: Audit amount
+    funds: 100% (206 XMR)
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+---
+
+This is the funding request for Monero Research Lab's Concise Linkable Ring Signatures (CLSAG) research. CLSAG promises to provide more efficient Monero transactions without sacrificing privacy. CLSAG improves Monero transactions with no meaningful disadvantages. It's a drop-in improvement for MLSAG like Bulletproofs was. CLSAGs require a hardfork to implement.
+
+The Monero Audit Workgroup cooperated with [OSTIF](https://ostif.org/) to create [this SoW](https://ia601504.us.archive.org/24/items/jp-ostif-clsag-signed/JP%20OSTIF%20CLSAG%20SIGNED.pdf) with [Teserakt](https://teserakt.io/). The Monero community has cooperated with OSTIF for the past [Bulletproofs](https://ostif.org/the-ostif-and-quarkslab-audit-of-monero-bulletproofs-is-complete-critical-bug-patched/) [audits](https://ostif.org/the-quarkslab-and-kudelski-security-audits-of-monero-bulletproofs-are-complete/) and [RandomX audits](https://ostif.org/four-audits-of-randomx-for-monero-and-arweave-have-been-completed-results/).
+
+The workgroup consists of the following members. They do not receive compensation:
+
+* ArticMine
+* binaryFate
+* Justin Ehrenhofer
+* Sarang Noether (abstained)
+* SerHack
+
+Cost breakdown:
+
+* Audit amount: $14,400
+* OSTIF fee (10%): $1,440
+* OSTIF audit credit: ($3,150)
+* Subtotal: $12,690
+* Buffer (10%): $1,269
+* Total: $13,959
+* XMR ($68): 206
+
+Teserakt has already begun working on this audit by their own decision.
+
+Any excess or shortfalls from volatility will be donated to or paid by Core.
\ No newline at end of file

cont-funding-surae-sep-nov-2018.md

+---
+layout: cp
+title: "Continued funding for Surae for another quarter, September October November 2018"
+author: suraeNoether
+date: August 26, 2018
+amount: 280
+milestones:
+  - name: Milestone 1 - September
+    funds: 33.33% (93.33 XMR)
+    done:
+    status: finished
+  - name: Milestone 2 - October
+    funds: 33.33% (93.33 XMR)
+    done:
+    status: finished
+  - name: Milestone 3 - November
+    funds: 33.33% (93.33 XMR)
+    done:
+    status: finished
+payouts:
+  - date: November 20, 2018
+    amount: 186.66 XMR
+  - date: December 6, 2018
+    amount: 93.34 XMR
+---
+**WHO** My name is Brandon Goodell. I am Monero Research Lab’s first postdoctoral researcher into cryptocurrency. I have a Ph.D. in Mathematical Sciences from Clemson University, a M.Sc. in Mathematics from North Dakota State University, and a B.S. in Mathematics from Colorado State University. I taught as a graduate student for 9 years at the university level, and I have participated in the Monero community under the pseudonym Surae Noether on-and-off 2014-2016, and I have worked at MRL full-time since June 2017.
+
+**WHAT** I am requesting a continuation of funding for my next quarter, of Sept-Nov. The overall lab-wide goals for MRL in the 2018/2019 year are described here, with completed tasks since the last update described. Most notably: we are waiting to hear from IACR about the multi-sig paper. In the last quarter, I said "contributors can expect in the next quarter: the beginning of the expansion of the document Zero to Monero into the Monero Standards, the literature review component of the roadmap to make progress as Sarang and I continue to read and take notes on current literature, a technical report on churn and linkability heuristics, and the (still in preparation) technical report on multisignatures (see below)." In regards to finishing these tasks, we have made significant progress on every front except for converting Zero-to-Monero into the Monero Standards: the literature review component of multi-signatures made it's way into the paper, and we have made some quantitative progress on the churn/linkability analysis, although we do not yet have a first draft of the churn heuristics. We have had some discussion about whether Monero Standards are even necessary now that Zero to Monero has been completed by contributor Ukoe.
+
+In the next quarter, contributors can expect: a draft of a document describing cross-chain atomic swaps with ring confidential transactions, more literature review components, a draft of a document describing our churn/linkability results, and a draft of recommended best practices for Monero.
+
+**WHY** Monero Research Lab has communicated with researchers all over the cryptocurrency industry, cryptographers, computer scientists, and computer engineers. In the past year, we have traveled internationally to conferences to learn and participate in the dissemination of results, contributed to several published technical notes on the technology underlying Monero, helped read and review papers for other researchers, participated in the cryptocurrency community more broadly, and learned quite a bit about decentralized payment infrastructures. We have submitted one paper for peer review and we have published a handful of whitepapers. Our work into multisig revealed a lot of dangerous territory in the multi-signature world. We ended up not needing to abandon the Musig protocol; we merely needed to insert a commit-and-reveal step. Taking great care in the construction of multi-signatures is going to be one foundational piece of off-chain scaling for Monero.
+
+**HOW MUCH TOTAL** ~~376 XMR~~ 280 XMR. I am asking for 9000$ USD/month; this is in line with market rates for a Ph.D. scientist and mathematician (accounting for the tax implications of working outside a traditional employer), and represents my assessment of fair compensation. ~~I am asking at 71.88 USD/XMR as my baseline exchange rate.~~ The market has changed somewhat from my initial posting, so I am asking at approximately 96 USD/XMR Why? ~~I am modifying my rule of estimating my XMR exchange rate: in an objectively bear market (we have had around a 40-50% contraction in price over June, July, and August), I'll take the lower bound of the 30-day Bollinger Band with 1.9599 standard deviations, and during an objectively bull market, I'll take the upper bound.~~ I am modifying my rule of estimating my XMR exchange rate: in a bear market, I will split the difference between the 30 day EMA and the lower Bollinger band, otherwise in a bull market I will split the difference between the 30 day EMA and the upper Bollinger band. ~~If the change in the market on the 3-month scale is under 10% or so, I'm not going to sweat it and just go with the 30 day EMA.~~ The market has changed enough for me to re-adjust my request. The last two funding periods, I was using the 30 day EMA to estimate the Monero exchange rate, but this always leads to an over-estimate of price during a bear market.
+
+**Thank you, Monero Community!** Let's get Monero's lightning technology rollin! We at MRL strongly value community input into the funding process, and welcome discussions regarding my funding proposal. Thank you again to the entire community, whether you've donated to me or not... you guys are absolutely running the show, and you all kick some major butt. I hope by making Monero better, we're all a little better off.
\ No newline at end of file

cryptogrampy-hotshop-dev.md

+---
+layout: cp
+title: HotShop Point of Sale
+author: cryptogrampy
+date: April 7, 2022
+amount: 18
+milestones:
+  - name: Milestone 1 - Create and publish payment code, perform basic payment generation and verification on deployed webapp
+    funds: 0
+    done: 29 May 2022
+    status: finished
+  - name: Milestone 2 - Create and publish draft Point of Sale user interface for feedback
+    funds: 8
+    done: 29 May 2022
+    status: finished
+  - name: Milestone 3 - Create finalized Point of Sale interface, create install and deployment instructions, publish freely available version
+    funds: 10
+    done: 27 May 2023
+    status: finished
+payouts:
+  - date: 1 June 2022
+    amount: 8
+  - date: 7 June 2023
+    amount: 10
+---
+
+HotShop - a browser-based, ephemeral, no-server point of sale
+
+**who**
+Hello, it's me, your great-grandfather CryptoGrampy.  You might know me on Twitter as @CryptoGrampy or from my work on the Monerod-on-Termux Android script, the Android PocketNode(tm), the Monero Drag n' Drop Electron app or from Friday morning bridge club in the cafeteria.
+
+**what is this**
+Monero is really lacking in the physical Point of Sale department. Let's fix that. 
+
+The HotShop will be a simple to use webapp with a simple aesthetic and UI similar to Kasisto (RIP) and POS.cash that can be accessed from just about any web browser (on mobile or desktop) with a slight amount of user customization (company name/image, etc). 
+
+You will be able to hit HotShop.cryptogrampy.com, enter your payment details, type in the desired XMR (optionally USD if you allow that API request) amount... a QR code and address will display, and the UI will update (payment confirmation progress as well) immediately when someone has paid the correct amount. 
+
+No hosting, private spend keys, personal servers/VPS's or payment gateways will be required. The app will be able to be added to any free web host- Github pages, etc and available for anyone to use because the magic happens in your browser (you'll be able to self-host it if you want) Users will need provide the app with their primary and view keys (no spend key involved!) on the client side (this info does NOT get sent to the server) and they will specify a remote Monero node of their choice.
+
+The tech stack will be something like: Monero-Javascript, Vue3, and Typescript.
+
+You'll be able to set this up at a garage sale, coffee shop, with your friends, etc and generate fresh/unused payment addresses displayed as QR codes.  In the settings, you'll set your desired number of confirmations (or do zero conf!), point it at a remote Monero node of your choice, and be able to collect payments and immediately validate that they were received/watch them as they get confirmed.  
+
+You'll be able to bookmark a link on your phone/browsers that contain all of the credentials necessary to start up the POS or have a QR code on a card containing a special link in your wallet... Just scan it with any device- your friend's phone, the library computer, the ipad at your store, and Boom! you have an instant Point of Sale.
+
+**Who does this benefit? Why do I need this when I can just use a mobile wallet?**
+- I think the physical Point of Sale situation is still pretty lacking in Monero
+- No existing wallets have good Point of Sale tech or UI
+- Perhaps you're in a situation where you can't have a wallet app on your phone/desktop but want to receive/validate payment
+- Perhaps you're in a situation where you want to be able to accept payments, but are worried about someone stealing your device or spend key wallet
+- An ephemeral point of sale that sort of lives on a QR code or bookmark in your phone sounds really cool
+- Maybe your mobile wallet is 1000000 blocks behind and want to IMMEDIATELY accept and verify a payment
+- Don't you want to make 100% sure your buddy at the bar *actually* sent those funds?  It's better than a static payment address.
+
+Also... Need yet another payment gateway?  The code for this will be written in a clean way that could be used in a NodeJS server or as a different front end implementation via simple exposed methods for instantiating the gateway, creating new payment requests and verifying payments.  If I have enough time, I will publish this portion of the code separately, and ideally as an npm library.  
+
+**what does this not do**
+- It's not going to keep track of payments that occurred before you hit the website (it's not going to be a full wallet).  It will sync at the latest block height to have the ability to immediately begin accepting payments
+- It's not going to keep track of prices, photos and items you have for sale in your store
+
+**potential reach ideas**
+- CSV export of tx's that occur in a session
+- Vending machine exploration
+- Pin code lock/unlock
+- Display past tx's within the session in a pleasant way
+- Local browser storage of user data
+- Importing prices/items via github repo json files
+- TOR support
+- Payment completion callback (provide a POST endpoint to receive completed payment data)
+
+**milestones**
+1st milestone - Coding up the basic payment portion in a nice/clean way, publishing a mostly bug-free, minimal version for testing user setting import and payments
+2nd milestone - Publish first draft of the POS interface (will be responsive), getting feedback from testers
+3rd milestone - Publish functioning POS to Github pages, etc, create documentation/video demo for use and self-hosting  
+
+**amount**
+I estimate that this will take about 4 to 5 weeks of mostly full time work and I am asking for 18 XMR. 
+
+**expiration**
+I will be working on this in the evenings and weekends but expect to have this complete within 4-8 months.

cypherstack-carrot-spec-review.md

+---
+layout: wip
+title: Carrot Spec Peer Review
+author: Monero Research Lab
+date: October 11, 2024
+amount: 126
+milestones:
+  - name: Carrot spec peer review
+    funds:
+    done:
+    status: unfinished
+payouts:
+  - date: 24 October 2024
+    amount: 126
+---
+
+## Carrot Peer Review
+
+This CCS will provide funding for the first step towards a Carrot implementation in Monero. Carrot is a specification for a backwards-compatible addressing protocol, as well as a new wallet key hierarchy for the upcoming FCMP++ consensus upgrade. This peer review will be over the specification, not any specific implementation. CypherStack was chosen for this audit from among several firms during the Monero Resarch Lab meetings the last couple weeks.
+
+## Scope / Deliverables
+
+A full peer review of the spec document [[link](https://github.com/jeffro256/carrot/blob/master/carrot.md)]. Note that at the time of writing this proposal, the paper is not yet published in a peer-reviewed conference/journal.
+
+The deliverable is a write-up which will include security proofs for all properties listed in section 9. It will also include notes on weaknesses, issues, or recommendations (if any). In the case that a security proof is not possible, a note will be included describing why that proof is not possible. In the case that CypherStack requires more funds to complete the security proofs, an MRL meeting will be held and a new CCS may be opened.
+
+## Out of scope
+
+- Multiparty computation. There are no specific protocols presented for this, and no corresponding security model of proofs of security.
+- Collaborative construction. For the same reason as multiparty computation.
+
+## Funding
+
+Because CypherStack has had a long successful history with Monero, has agreed to accept the XMR directly, wishes to mitigate volatility risks, and has received upfront payment for reviews before, the 126 XMR for this review is to be paid out in full to Cypherstack immediately upon reaching the funding goal.

cypherstack-gbp-security-proofs.md

+---
+layout: cp
+title: Generalized Bulletproofs Security Proofs
+author: Cypher Stack
+date: April 4, 2024
+amount: 200
+milestones:
+  - name: Funded
+    funds: 200
+    done: 11 April 2024
+    status: finished
+  - name: Completed
+    funds: 0
+    done: May 6th, 2024
+    status: finished
+payouts:
+  - date: 11 April 2024
+    amount: 200
+---
+
+Hello everyone, Diego "rehrar" Salazar here on behalf of [Cypher Stack](https://cypherstack.com/). We've recently [made a proposal to review the general Seraphis paper](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/441). After some discussion with MRL, including at an official MRL meeting, it was decided that while all parties do want this done eventually, there are perhaps some more immediate wins available for Monero's privacy tech, particularly in the form of Generalized Bulletproofs (GBP).
+
+To summarize what it is, why it's important, and what work will be done, I post a blurb from Dr. Aaron Feickert, Cypher Stack's on-staff cryptographer:
+
+```
+"Full-chain membership proofs are a construction being proposed for future Monero protocol upgrades. These proofs can be used to replace ring signatures (used in the current Monero protocol) and membership proofs (used in the proposed Seraphis protocol) to improve privacy.
+
+The proofs use a technique called curve trees that in turn rely on a Bulletproofs arithmetic circuit protocol. However, to meet technical requirements, the arithmetic circuit protocol needs to be modified to handle Pedersen vector commitments in a specific way. The modification, called generalized Bulletproofs, was informally described, but completely implemented, in a curve trees proof-of-concept implementation by one of its authors.
+
+In collaboration with Firo and Luke Parker, we've already done a more thorough documentation of generalized Bulletproofs to aid future implementation. To our knowledge, however, the technique has never been proven secure.
+
+Cypher Stack proposes to develop security proofs for generalized Bulletproofs. The goal is to produce a modified Bulletproofs arithmetic circuit protocol security proof that accommodates the generalized Bulletproofs technique and shows the required properties of perfect completeness, perfect special honest-verifier zero knowledge, and computational witness-extended emulation. This will mirror the existing proof of Theorem 4 in the Bulletproofs preprint.
+
+We stress that it is not known if the generalized Bulletproofs technique readily admits such a security proof. As such, this is a research proposal that has a nontrivial risk of failure. Should the research be successful, Cypher Stack will produce a report containing the proof. Should it fail, Cypher Stack will produce a report containing any relevant information that may be useful for other researchers."
+```
+
+A few things I (rehrar) want to emphasize on this quote.
+
+1. There is a non-negligible chance of failure to produce a satisfying proof. If this happens, the proposal is not considered a failure, and our deliverable changes to a report for future research.
+2. Much of this work will be directly applicable and cross-over with Seraphis in the future. So it's not a distraction that will delay things, in that sense.
+
+Cypher Stack asks for a total of 200 XMR to complete the review. We add a 10% volatility buffer, bringing the total up to 220 XMR. We aim to complete the review within 1.5 calendar (actual hours are not 1.5 months of man hours, but we have other work for other clients as well) months of the proposal being funded.
+
+EDIT: We have been asked during the community and MRL meetings to remove the volatility buffer and receive the entirety of the money up front to simplify things and get this merged faster. The original proposal above remains in its original state for posterity purposes, but the proposal has changed to reflect the new terms. The new total is 200 XMR to be paid out as soon as the proposal is merged and fully funded.

cypherstack-sarang-triptych-research.md

+---
+layout: cp
+title: Triptych research and optimizations
+author: Cypher Stack
+date: April 8, 2021
+amount: 22.86
+milestones:
+  - name: First 20 hours complete
+    funds: 6.325
+    done: 28 June 2021
+    status: finished
+  - name: Second 20 hours complete
+    funds: 6.325
+    done: 28 July 2021
+    status: finished
+  - name: Third 20 hours complete
+    funds: 6.325
+    done:
+    status: unfinished
+  - name: Fourth 20 hours complete
+    funds: 6.325
+    done:
+    status: unfinished
+payouts:
+  - date: 28 June 2021
+    amount: 6.325
+  - date: 28 July 2021
+    amount: 6.325
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+### Proposal closed
+
+The remaining funds (12.65XMR) have been donated to the General Fund.
+
+THIS PROPOSAL HAS BEEN CHANGED FROM TRIPTYCH RESEARCH OPTIMIZATIONS TO TRIPTYCH MULTISIG RESEARCH AFTER A MEETING WITH THE MONERO DEVS ON APRIL 21, 2021.
+
+## Brief Intro
+
+As of April 12th, 2021, Aaron "Sarang Noether" Feickert has joined Cypher Stack LLC as a resident researcher.
+
+Cypher Stack is a for-profit LLC owned by Diego "rehrar" Salazar. It started as a design firm but has since expanded to include blockchain consultancy and digital utilities and infrastructure hosting. They already donate to the Monero Project in the form of employing Dan "pigeons" Miller as a system administrator, who is responsible for running and securing much of Monero's infrastructure including Taiga, Matrix, and other key infrastructure in conjunction with the core team.
+
+Sarang himself needs no introduction. A previous full-time researcher of MRL paid for by the CCS, he wants to continue doing research into next-gen privacy with Monero (particularly in Triptych), hence this proposal.
+
+## The scope
+
+Sarang Noether and collaborators created the Triptych and Arcturus privacy protocols, which, if implemented in Monero, could allow ring sizes of greater than 100 with similar size transactions to present ones (though verification times would increase linearly).
+
+Work is already underway to include Triptych into Monero's codebase, but one of the big question marks shrouding the new protocol is multisig. The Monero ecosystem is maturing in such a way that Monero's multisig feature is being used in more and more applications, and moving to Triptych would break the current implementation. This could potentially stop Triptych's implementation in its tracks.
+
+The goal of this proposal would be to do further research into Triptych's multisig options. Some research has already been done, and a path forward is already known, but the details and specifics need to be ironed out. Sarang would conduct this research to see if multisig is possible, and how a migration from the old to the new might be conducted in a way that is safe, private, and efficient.
+
+## The structure, milestones, and price.
+
+This proposal is structured to be paid out along time-based milestones, but the time will not be consecutive. Each milestone will be paid out at intervals of 20 hours.
+
+In other words, after 20 hours-worth of work is complete, a payout will be made to the completed milestone, but it may take one month or more to complete this 20 hours depending on time, availability, and other concurrent projects.
+
+We are putting in a request for 80 hours (one cumulative month worth) of work. We are requesting $100/hour for this highly specialized work, which comes out to $8,000. At the exchange rate of $350/XMR we reach 22.86 XMR. We round it up to 23 and add a 10% buffer, which brings us to 25.3 requested XMR.
+
+## The Deliverables
+
+Deliverables to the community: Sarang will give an update every calendar month on his progress to the Monero community in the form of a Reddit post in the Monero subreddit. Other update platforms can be explored as well. Keep in mind, because of the structure of the proposal, some updates may have little to no progress as a result of other work. These reports would say as much.
+
+Deliverables to the devs: Sarang will provide write-ups, documentation, or proof-of-concept code to the developers as applicable based on research progress and results, toward the goal of a potential future Triptych release that meets the needs of the community.
+
+## Risks
+
+A risk of this research is that multisig may not be possible with Triptych after all. If this is ascertained early on, further research on Triptych may be unnecessary as it will not be fit for our use given the importance of multisig in the Monero ecosystem. This means the research will stop immediately, and any partially completed milestones will be paid out to the extent of hours fulfilled. Remaining funds can be dispersed amongst other active fundraising proposals or however Core sees fit. The funds should NOT be rolled into the general fund as usual due to a conflict of interest, which is outlined below.
+
+It is also possible that the work is finished early. If this occurs, the remaining funds from milestones will be utilized in the same manner as previously stated in the event that Triptych multisig can not be used.
+
+## Conflict of interest
+
+After some discussion on IRC I have added this section at the end to clarify that I, Diego Salazar, owner of Cypher Stack and employer of Sarang Noether, am also paid by the general fund to work for the Core Team. I have powers to merge in the CCS but only do so with permission from luigi1111, who oversees the whole CCS system. I recuse myself from any sort of merging or moving processes with this CCS proposal due to the conflict of interest.
+
+Cypher Stack also has another active research contract with privacy coin Firo, and Sarang works on this project.