CCS Proposals merge requestshttps://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests2024-03-29T09:27:18Zhttps://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/440CCS Coordinator2024-03-29T09:27:18ZplowsoffCCS Coordinator# 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...# 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), 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.
# Funding
20hr/week - 40 eur/hr with XMR at 126EUR (MA20 @ Kraken) gives 20 * 13 * (40/126) = 80.5 but i like 80.07 better so 26.69 XMR/milestone bringing the total requested amount to 80.07XMR. Maximum of 1 milestone can be claimed per month. Price fluctuation after moving to funding will have no effect.
Consider this proposal expired in the event of my untimely death / unheard of for >5 months / have not claimed all payouts in 12 months. If expired - all remaining unclaimed funds are to be donated to other CCS proposals.https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/439Rucknium Statistical Research2024-03-29T09:37:46ZRuckniumRucknium Statistical Research
## What
I propose to carry out statistical research to improve Monero's privacy, guide protocol decisions, and respond to Monero developer requests for statistical analysis of code changes where needed. In the short term I will complet...
## What
I propose to carry out statistical research to improve Monero's privacy, guide protocol decisions, and respond to Monero developer requests for statistical analysis of code changes where needed. In the short term I will complete in-progress analysis of the suspected transaction spam attack to provide a comprehensive view of the options to defeat this attack and possible future ones. This involves producing a Monero Research Lab research bulletin from the draft of ["March 2024 Suspected Black Marble Flooding Against Monero: Privacy, User Experience, and Countermeasures"](https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-flood.pdf). I will work with ArticMine to evaluate changes to ring size, fees, and block size scaling parameters to balance privacy, usability, and decentralization. Some items to complete the draft research bulletin:
- Derive the tradeoff function between ring size and transaction fees, i.e. how does a marginal increase in each variable affect the cost to a potential attacker?
- Simulate the combined block marble attack and Dulmage-Mendelsohn decomposition from Vijayakumaran (2023) to evaluate vulnerability to chain reaction analysis.
- Estimate any changes in the real spend age distribution during the spam incident using OSPEAD techniques. Movement toward more recent outputs suggests more evidence for the spam hypothesis.
- Create a node network crawler that seeks the source of large transaction volumes. Possibly combine the crawler with statistical analysis techniques of Sharma, Gosain, & Diaz (2023).
- Finish the research literature review.
Once the black marble flood analysis is completed, I would move to other research priorities:
- PocketChange privacy evaluation
- Ring member binning
- Fee discretization and fee prediction
- Safety of adjusting the 10 block lock
- Preparation of a paper describing OSPEAD for peer review and research journal publication
- EAE/EABE attack and churning
- Network privacy through steganography
I will not be able to complete all of these projects during this work period. Research priorities can be modified at Monero Research Lab meetings due to new events or findings.
I am nearing completion of [the OSPEAD improvement to Monero's decoy selection algorithm](https://ccs.getmonero.org/proposals/Rucknium-OSPEAD-Fortifying-Monero-Against-Statistical-Attack.html). OSPEAD probably can only be safely implemented at a hard fork boundary because multiple decoy selection algorithms being used at the same time is [a potential threat to user privacy](https://github.com/Rucknium/misc-research/blob/main/Monero-Fungibility-Defect-Classifier/pdf). In the short them, analysis of the suspected flood attack is a higher priority. After, I will put hours into finishing the OSPEAD CCS proposal. Then after OSPEAD I will return to putting hours into this CCS proposal.
## Who
I am an empirical microeconomist. My recent contributions to Monero include:
- [Discovery of a mining pool misconfiguration. Sped up average time to first transaction confirmation by 60 seconds.](https://reddit.com/r/Monero/comments/11nu4aj/monero_transaction_confirmations_are_now_60/)
- [Privacy vulnerability report to Exodus Wallet about nonstandard fees. Successfully resolved.](https://reddit.com/r/Monero/comments/176e1zr/privacy_advisory_exodus_desktop_users_update_to/)
- ["Discussion Note: Formula for Accuracy of Guessing Monero Real Spends Using Fungibility Defects"](https://github.com/Rucknium/misc-research/blob/main/Monero-Fungibility-Defect-Classifier/pdf)
- [Identification of privacy-reducing nonstandard transaction fees](https://github.com/Rucknium/misc-research/tree/main/Monero-Nonstandard-Fees)
- [Analysis of the privacy impact of Mordinals (Monero NFTs)](https://reddit.com/r/Monero/comments/12kv5m0/empirical_privacy_impact_of_mordinals_monero_nfts/)
- [Monerotopia 2023 presentation: "A Statistical Research Agenda for Monero"](https://github.com/Rucknium/presentations/blob/main/Rucknium-Monerotopia-2023-Slides.pdf)
- [Statistical privacy analysis of P2Pool coinbase outputs in ring signatures](https://github.com/monero-project/research-lab/issues/109)
- ["Closed-form Expression of Monero's wallet2 Decoy Selection Algorithm"](https://github.com/Rucknium/misc-research/tree/main/Monero-Decoy-Selection-Closed-Form/pdf)
Pull requests reviewed for statistical issues:
- [wallet: mitigate statistical dependence for decoy selection within rings](https://github.com/monero-project/monero/pull/9023#issuecomment-1802593848)
- [wallet2: prevent duplicate outs](https://github.com/monero-project/monero/pull/8047#issuecomment-967113046)
- [monero-serai: fix decoy selection algo and add test for latest spendable](https://github.com/serai-dex/serai/pull/384#issuecomment-1870597406)
## Budget
I will work 20 hours/week for three months (13 weeks). My fiat-equivalent labour rate is the same as my previous proposal, adjusted for the lower purchasing power of the USD today: 110 USD/hour. The average daily opening USD/XMR exchange rate for the last 14 days (2024-03-15 to 2024-03-28) according to CoinGecko was 139.49.
The above numbers compute to `20 * 13 * (110/139.49) = 205.0179`. Rounding down to get whole numbers for the three milestones sets the total budget for this proposal to 204 XMR paid in three milestones of 68 XMR each. This proposal expires on January 1, 2025.
## References
Sharma, P. K., Gosain, D., & Diaz, C. (2023). "On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies." Proceedings 2023 Network and Distributed System Security Symposium.
Vijayakumaran, S. (2023). "Analysis of CryptoNote Transaction Graphs using the Dulmage-Mendelsohn Decomposition." 5th Conference on Advances in Financial Technologies (AFT 2023), volume 282 of Leibniz International Proceedings in Informatics (LIPIcs).https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/437Unnamed Monero Wallet development2024-03-29T09:30:26ZCzarek NakamotoUnnamed Monero Wallet developmentHello! I'm mrcyjanek and I'm currently working on the Unnamed Monero Wallet (short: xmruw) that aims to be as portable as possible and as close to `wallet2_api.h` as it is reasonably possible.
However, this project got much bigger than ...Hello! I'm mrcyjanek and I'm currently working on the Unnamed Monero Wallet (short: xmruw) that aims to be as portable as possible and as close to `wallet2_api.h` as it is reasonably possible.
However, this project got much bigger than I initially expected and resulted in a project that is huge in size, but also has really large portability capabilities (not only the wallet but also the underlying libraries - more on that later), after fighting for a couple days with Wayland implementation on SailfishOS I (with the help from Mister_Magister and NotKit) managed to run the first cryptocurrency wallet natively on SFOS ([that is available on the app store of that os](https://openrepos.net/content/mrcyjanek/unnamed-monero-wallet-xmruw)). More details and the origin story can be found in a [blog post announcing the wallet](https://www.mrcyjanek.net/p/xmruw-monero-wallet/).
I'm developing `xmruw` with a few critical points in mind:
- There should be no database responsible for any of the monero-releated functions - so I won't accidentally do something that shouldn't be done.
- The app should be as close to `wallet2_api.h` as possible to eliminate things like overly complex state management as something that causes issues.
- Privacy should be prioritized - no external services are contacted in the app, and if there ever happens to be some external feature it will be opt-in in settings with an option to route entire traffic through Tor.
- Security is also prioritized - not only by minimizing the attack surface but also by providing features such as stealth mode (inspired by Samourai wallet)
- UX is the most critical of them all in my opinion - without the right UX, not many users are going to use a wallet, so it is my responsibility as a developer to make the wallet available on all platforms and to be appealing to users.
- As a mobile Linux enthusiast I'll also do my best to offer secure monero wallet solutions for owners of non-Android and non-iOS mobile devices
# About
I've decided to take the simplest path from `wallet2_api.h` to the actual wallet UI, so instead of forking m2049r/cake implementation I've decided to use `dart:ffi` to call the native functions - this made a lot of code unnecessary, and the part that was still required was mostly generated - so I call that a huge win. But not without it's own cost - I had to write a wrapper for `wallet2_api.h` that would provide C headers instead of C++ - which meant [writing a bunch of boilerplate code](https://git.mrcyjanek.net/mrcyjanek/monero_c/src/commit/abaa3a2d165577a79ce0c3fe5382b68fa260ecc1/libbridge/src/main/cpp/wallet2_api_c.cpp#L1549), that gave birth to the foundation of the wallet:
## monero_c
monero_c focuses on two things
- providing a simpler C API for the official wallet without adding any extra code.
- compiling it for a variety of platforms in a reproducible and static way.
[Gitea](https://git.mrcyjanek.net/mrcyjanek/monero_c), [GitHub](https://github.com/mrcyjanek/monero_c)
Monero_c is not only useful in this context, but it opens a way to use monero code directly in many programming languages (such as Kotlin, Golang, and Dart) by using native FFI plugins.
## monero.dart
Written to solve the issue of having to care about freeing memory/converting dart `String`s to `const char*`, most of the code is generated. Thanks to the `monero_c` header file LSP provides suggestions for the code, so any kind of error should result in a warning in IDE and compile-time error.
[Gitea](https://git.mrcyjanek.net/mrcyjanek/monero.dart), [GitHub](https://github.com/mrcyjanek/monero.dart), [Pub](https://git.mrcyjanek.net/mrcyjanek/-/packages/pub/monero/)
## Bytewords
Implementation of bcr-2020-012-bytewords that is being used for offline functionality (both in Qubes and Offline/Online mobile wallet setups)
[Gitea](https://git.mrcyjanek.net/mrcyjanek/bytewords), [GitHub](https://github.com/mrcyjanek/bytewords), [Pub](https://git.mrcyjanek.net/mrcyjanek/-/packages/pub/bytewords/)
## offline_market_data
It is critical (in my opinion, and the opinion of my friends) to have our local currency calculator in a wallet, otherwise, we need to check the price on our own externally. The `offline_market_data` package offers historical offline data and an API to get historically accurate prices for monero in a few fiat currencies.
[Gitea](https://git.mrcyjanek.net/mrcyjanek/offline_market_data), [GitHub](https://github.com/mrcyjanek/offline_market_data), [Pub](https://git.mrcyjanek.net/mrcyjanek/-/packages/pub/offline_market_data/)
## libstealth_calculator
Different approach to stealth mode, heavily inspired by Samourai wallet implementation, [details are quite technical](https://git.mrcyjanek.net/mrcyjanek/libstealth_calculator). This library should make it trivial to implement stealth mode in any monero wallet written in Flutter.
[Gitea](https://git.mrcyjanek.net/mrcyjanek/libstealth_calculator), [GitHub](https://github.com/mrcyjanek/libstealth_calculator), [Pub](https://git.mrcyjanek.net/mrcyjanek/-/packages/pub/libstealth_calculator/)
## openalias_server
This is an experiment, but I think that it is worth mentioning. I want to offer an easy way for users to obtain and register a custom OpenAlias subdomain. This is just a not-really-working PoC that I'd like to make as a tool to make OpenAlias adoption much wider.
[Gitea](https://git.mrcyjanek.net/mrcyjanek/openalias_server), [GitHub](https://github.com/mrcyjanek/openalias_server)
## Unnamed Monero Wallet (xmruw)
After putting all those libraries in place I went ahead and implemented a wallet
[Website](https://xmruw.net), [Gitea](https://git.mrcyjanek.net/mrcyjanek/unnamed_monero_wallet), [GitHub](https://github.com/mrcyjanek/unnamed_monero_wallet), [Downloads](https://download.xmruw.net/)
Features of the wallet include:
- Sending/Receiving monero
- Online/Offline wallet modes
- With URQR and file exports for Android/iOS
- With clipboard-based exports for QubesOS
- Embedded Tor support
- (soon) Embedded i2p support [^1]
- Stealth mode (fake calculator app that opens wallet if the correct pin is provided)
- Multiple account support
- Coin control
- Signing / Verifying of messages
- Custom themes
- Advanced settings
- Performance analysis tool for the `wallet2_api.h` functions called
- Debug information that makes development easier
- Configuration options to opt-in to experimental features (such as [background sync](https://github.com/monero-project/monero/pull/8619))
- OpenAlias resolving
- Backup/Restore
- Historically accurate currency conversion done fully offline
- And all of the "obvious" features such as transaction list, subaddress list, wallet locking, QR code scanning, etc.
## Plans
My plans are:
- Expanding compatibility of `monero_c` to all platforms that I have access to (Linux (glibc+musl), FreeBSD, iOS, MacOS, Windows) in an easily-reproducible way (single makefile and a docker environment)
- Making `xmruw` available for all platforms (and I do mean all platforms) and in app stores (including play store, self-hosted f-droid repository, apple app store, .deb, and .rpm repository).
- Fix issues that were made along the way
- Bytewords entering an infinite loop when incorrect text is passed in
- No compatibility with Feather / ANONERO in offline mode due to lack of CBOR encoding
- Not cross-platform QR scanner
- Bad UI on desktop (not that it's bad, it is just mobile-first)
- Implementing features desired by users
# Payment
I'm proposing to work for 20 hours/week for `20$/hour` at a rate of `~125,14$/XMR` (according to open prices between 2024-02-17 and 2024-03-01 (date of writing) via [CoinGecko](https://www.coingecko.com/en/coins/monero/historical_data)) for 12 weeks, summing up to a total of `~38.34` XMR split into 3 payments of `12.78` XMR every 4 weeks.
At the end of each week, I'll comment a summary of what happened along the way and what tasks were done. Also, I'd love to work full-time on xmruw but this is sadly not an option for the next 3 months.