Merge branch 'Spirobel-Robust-Modular-Wallet-Library' into 'master'

Spirobel: Robust and modular wallet-rpc library

See merge request monero-project/ccs-proposals!501

MoneroSignerResurrection.md

@@ -1,5 +1,5 @@
 ---
-layout: wip
+layout: cp
 title: "Monero Signer Resurrection: Reviving and Enhancing the Monero Signing Project"
 author: Thor a.k.a vthor a.k.a DiosDelRayo
 date: May 24, 2024
@@ -19,8 +19,8 @@ milestones:
     status: finished
   - name: Monero-GUI integration
     funds: 10 XMR
-    done:
-    status: unfinished
+    done: 27 September 2024
+    status: finished
 payouts:
   - date: 20 June 2024
     amount: 5.38
@@ -28,8 +28,8 @@ payouts:
     amount: 5
   - date: 13 August 2024
     amount: 35
-  - date:
-    amount:
+  - date: 28 September 2024
+    amount: 10
 ---
 # Monero Signer Resurrection: Reviving and Enhancing the Monero Signing Project
 

jeffro256-full-time-2024Q4.md

@@ -0,0 +1,57 @@
+---
+layout: fr
+title: jeffro256 full-time development 2024Q4
+author: jeffro256
+date: September 16, 2024
+amount: 144
+milestones:
+  - name: Month 1
+    funds: 33% (48.0)
+    done:
+    status: unfinished
+  - name: Month 2
+    funds: 33% (48.0)
+    done:
+    status: unfinished
+  - name: Month 3
+    funds: 33% (48.0)
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+## What
+
+The last quarter I began implementing [Jamtis-RCT](https://gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96), as written by tevador. However, with the FCMP++ integration PR opened against master, and upon discussion of the general health of wallet development in the broader ecosystem, it became readily apparent that the way to move forward is to initially support existing Monero addresses in a way that would be indistinguishable on-chain from Jamtis-RCT, adding full Jamtis-RCT support later. As such, I formulated the [Carrot specification](https://github.com/jeffro256/carrot/blob/master/carrot.md), which expanded upon the legacy address section in tevador's original Jamtis-RCT proposal. I contacted and conducted meetings with auditors in regards to auditing this spec, which culminated in several proposals. I also implemented transaction scanning code and transaction construction code for Carrot. I would like to continue this work for the next few months ahead of the hardfork. The main things to work on for Carrot at this point are 1) persistent enote stores for both legacy and Carrot scan types together, 2) integration into the main wallet codepaths, 3) hardware device support, and 4) picking and organizing an auditor to move forward with. Ideally, there should also come a point in the near future where the implementation is reviewed against the audited specification. I wish the development of Carrot generally to be swift, in order not to impede the release date of the FCMP++ consensus protocol. It should be noted that if the current addressing protocol is not modified, then users' transactions will *not* be afforded conditional forward secrecy. This would mean that a potential future adversary with the ability to solve the decisional Diffie-Helman problem (e.g. a usable quantum computer) would be able to retroactively reveal the transaction graph without any obfuscation. Carrot, like Jamtis-RCT, leverages the forward secrecy property of FCMP++ while also tackling other issues like the burning bug, Janus attacks, etc. If all goes well, the adoption of Carrot will seamlessly move Monero users into the full realization of the privacy and security that the FCMP++ proving system has to offer. 
+
+To recap, here is a list of things I will attempt to work on this quarter, in rough order of execution:
+
+- Finalize Carrot spec audit
+- Implement Carrot enote store
+- Implement Carrot hardware device support
+- Integrate Carrot into main wallet codepaths
+- Begin soliciting Carrot implementation audit
+
+P.S. To all the generous supporters of my previous proposals, I apologize that the direction of my work has shifted so significantly and so frequently in the past. So many developments have occurred within the last year that it makes my head spin, which in the end will no doubt be a good thing. So while a lot of previous goals have been abandoned, and a lot of previous work put on ice indefinitely, things seem to be finally solidifying towards a forseeable, readily-achieveable outcome in regards to the upcoming hardfork, thanks to many hard-working contributors. Hopefully, all of the work for this quarter will actually see the light of day in the short to medium term. Thanks for your patience. I am very grateful for it.
+
+## Who
+
+I have been contributing to the Monero core repository for [over two years](https://github.com/monero-project/monero/pulls?page=2&q=is%3Apr+author%3Ajeffro256) with a total of [76 merged commits to master](https://github.com/monero-project/monero/commits?author=jeffro256) thus far, with many open PRs. I also began working on the Seraphis migration project, so you can see some of my contributions [here](https://github.com/seraphis-migration/monero/pulls?q=is%3Apr+author%3Ajeffro256) and [here](https://github.com/UkoeHB/monero/pulls?q=is%3Apr+author%3Ajeffro256). Additionally, as I mentioned, last quarter I wrote up the [Carrot specification](https://github.com/jeffro256/carrot/blob/master/carrot.md) for formal auditing, which will be the main addressing protocol post-FCMP++ if all goes according to plan.
+
+Previous Proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/390
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/421
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/436
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/467
+
+## Payment
+
+I propose to work 40 hours/week for 3 months so `40 (hours/week) * 3 (months) * weeks_per_month = 40 (hours/week) * 3 (months) * (365 / 12 / 7) (weeks/month) = 521` hours total on-paper, though I usually work more than that. The proposal is broken into 3 milestones, one for each month. I am setting my hourly rate at 47 USD/hour (+1 USD/hour higher than last quarter), and at a market price of 170.37 USD/XMR, that makes for a total of 143.7 XMR. Price was calculated as 14-day simple average of opening prices on [CoinGecko](https://www.coingecko.com/en/coins/monero/historical_data) from 2024-09-04 to 2024-09-17 (day of writing), same as last quarter.
+

ofrnxmr-totw3.md

@@ -7,8 +7,8 @@ amount: 168
 milestones:
   - name: Aug 2024
     funds: 14 XMR
-    done:
-    status: unfinished
+    done: 23 September 2024
+    status: finished
   - name: Sep 2024
     funds: 14 XMR
     done:
@@ -53,8 +53,8 @@ milestones:
     funds: 14 XMR
     done:
 payouts:
-  - date:
-    amount:
+  - date: 28 September 2024
+    amount: 14
   - date:
     amount:
   - date:

spirobel_robust_modular_wallet_rpc.md

@@ -0,0 +1,141 @@
+---
+layout: fr
+title: Robust and modular wallet-rpc library
+date: Sep 10, 2024
+author: Spirobel
+amount: 80
+milestones:
+  - name: Deved + prepayment for first month
+    funds: 20 XMR
+    done:
+    status: finished
+  - name: First month
+    funds: 20 XMR
+    done:
+    status: unfinished
+  - name: Second month + value commitment
+    funds: 40 XMR
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+# Robust and modular wallet-rpc library
+
+## Who
+
+**Spirobel**
+
+References:
+
+#### found and reported a "pay what you want" vulnerability in AcceptXMR
+
+https://x.com/spirobel/status/1672479215512588288
+
+https://github.com/busyboredom/acceptxmr/issues/64
+
+#### open sourced a Patreon like tool for Monero
+
+https://x.com/spirobel/status/1595949928634667008
+
+https://github.com/spirobel/monero-discourse-subscriptions
+
+#### open sourced a merchant focused wallet-rpc
+
+https://x.com/spirobel/status/1596299822516285440
+
+https://github.com/spirobel/monerochan-merchant-rpc
+
+
+#### implemented a Monero Browser wallet extension
+
+https://www.youtube.com/watch?app=desktop&v=4DLcsQ45zoE
+
+Contact: twitter.com/spirobel
+
+## What
+
+Result: A robust and modular wallet-rpc library, implemented in Rust with WebAssembly (WASM) as the primary target. This library aims to provide a flexible foundation for Monero wallet functionality. The deliverable for this proposal will be:
+
+1. the first part of the wallet-rpc library that can sync transactions and works reliably with remote nodes.
+2. A checkout flow built with this library. This is meant to be used, not just to demonstrate the features.
+3. Detailed documentation for the library, the relationship between nodes and wallets during the syncing process and a guide on how to use this to implement monero payment gateways.
+
+### Implementation
+
+list of initial tasks:
+
+- create function to turn address and private viewkey into viewpair
+- create function to scan transaction with sub functions
+- verify that there is no timelock present
+- calculate transaction amount
+- clarify responsibility of burning bug prevention for the caller
+
+- implement transaction fetching and storage
+- implement burning bug prevention in the checkout flow
+- write unit tests, document and publish the library
+- implement UI for the checkout flow
+
+this task list is not exhaustive and subject to change
+
+## Why
+
+As discussed as far back as two years ago: https://github.com/seraphis-migration/strategy/issues/2
+The wallet2 Monero library is a 15k lines CPP file. The official monero repo does not contain a deliverable that is easily linkable from other programs. Every project that is a wallet or contains wallet-like functionality (payment processors, hardware wallets, point of sale terminals) needs to implement its own wrapper to expose a C ABI.
+
+This results in collectively wasted hours and headaches. It increases supply chain risk and makes building things with Monero harder. As a result, projects get more expensive, take longer or don't happen at all.
+
+This library aims to counteract the issues and limitations of wallet2.cpp by directly targeting wasm.
+Using wasm as the main target means that this library is forced to be implemented in a way that meets the expectations outlined here: https://github.com/seraphis-migration/strategy/issues/1
+
+The benefits of this approach:
+
+### 1. It will be easily linkable
+
+WASM is a very constrained target. There is no garbage collection and multi threading. Getting code to run there means having to write it in a way that is easy to interact with from any language and in any environment.
+
+### 2. It will be more robust
+
+The current monero wallet-rpc is at times unresponsive, because its concurrency mixes the responses of the local rpc with the network interacting with the node. More details in the [monero-playground repository](https://github.com/spirobel/monero-playground). The WASM target constraints ensure that this library decouples the concurrency and networking from the wallet code. The result will be more robust.
+
+### 3. It will be more flexible and not tied to any platform / target
+
+Wallet code deals with the most sensitive data. It should not have unnecessary dependencies or bloat. To give a practical example: monero currently vendors a 4000 lines of code [logging library](https://github.com/monero-project/monero/blob/master/external/easylogging%2B%2B/easylogging%2B%2B.cc) that introduces a dependency on signals. The WASM target constraint means that things like that can't and wont be introduced into this library.
+
+## Milestones and Timeline
+
+value commitment:
+
+The 3 deliverables outlined in the **What** section are the promised outcome of this proposal. Any time left over from the time commitment will be used to further advance the road map. The value commitment is due for the milestone of the second month.
+
+time commitment:
+
+- 100 hours per month for two months (100 hours total)
+- Compensation: 40 XMR per month (80 XMR total)
+- Total compensation: 80 XMR
+
+## Future Roadmap
+
+The next step on the road map is to add transaction building and signing functionality to the library and migrate [the browser wallet](https://www.youtube.com/watch?v=4DLcsQ45zoE) to it.
+
+My endgame is to **remove all friction from the privacy enabled web shopping experience**. Currently most **Monero shoppers** have to copy and paste addresses from the tor browser into their wallets. This opens the door to unnecessary opsec failures, as it is easy to get confused and intimidated by long strings of random numbers.
+
+**A core part of staying private and safe online is to compartmentalize identities.** Qubes OS made some advancements in improving the UX of this activity by coloring different windows that are tied to different identities in a unique way.
+
+The reality is, that installing a different operating system is a large ask for the average person. At the same time we need to onboard as many people as possible to these habits, so we can operate safely in the crowd.
+
+The other venue of attack is **using the browser for compartimentalization.** And before anybody complains: no this does not involve untrusted javascript frontend code.
+
+There is a big difference between a browser wallet and web wallet. A web wallet is a flawed experiment that is borderline custodial, as it runs wallet code inside the context of a website. This is not to be confused with a browser wallet.
+**A browser wallet runs trusted code as a compartmentalized, constrained program inside of a sandbox.**
+
+There is a massive opportunity here to reduce friction by making it easy to separate online identities. The TOR browser currently enables the use of one separate TOR circuit for each tab. **Imagine we have one monero address per tab that is used for login and to send and receive payments.** It makes it much harder to mess up.
+
+One last concern that comes up is that there might be zero day exploits in the browser, as it exposes a potentially larger attack surface. This can be mitigated by making the wallet a multisignature wallet and **using a second device like an android phone or a monero seedsigner to authorize every transaction.**
+This means two devices need to be compromised to capture funds, which is unlikely.