Merge branch 'OfflineSigningLibrary_XmrSignerToProduction' into 'master'

Offline Signing Library for XmrSigner Production

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

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:

vThorOfflineSigningLibrary_XmrSignerToProduction.md

@@ -0,0 +1,104 @@
+---
+layout: fr
+title: Offline Signing Library for XmrSigner to Production
+date: August 31, 2024
+author: Thor a.k.a. vThor a.k.a DiosDelRayo
+amount: 97
+milestones:
+  - name: Material
+    funds: 1 XMR
+    done:
+    status: unfinished
+  - name: First month
+    funds: 48 XMR
+    done:
+    status: unfinished
+  - name: Second month
+    funds: 48 XMR
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+# Offline Signing Library for XmrSigner Production
+
+## About
+
+This proposal aims to create a minimal library for offline signing on
+air-gapped devices, focusing on essential features:
+
+- Seed phrase generation (including polyseed)
+- Address and key generation
+- Account and sub-address management
+- Address verification
+- Output importing and Key Image exporting (raw and encrypted)*
+- Unsigned transaction handling (description, sanity checks, signing)
+- Block height and date estimation
+
+The library will be implemented in C++ with a C ABI, allowing use in
+multiple languages. It will be based on the current Monero source but
+without relying on wallet2, aiming for minimal external dependencies,
+not inventing the wheel again, nor rolling own crypto.
+
+Key objectives:
+- Comprehensive documentation
+- Quick start guide for offline and hardware wallet developers
+- Documentation of challenges in stripping down and cross-compiling
+- Buildroot package for easy target system integration
+- Python module for library usage
+- Test code
+- Modification of XmrSigner to use this new library
+
+## Who
+
+Thor (vThor/DiosDelRayo), currently completing the [XmrSigner (MoneroSigner Resurrection) proposal](https://ccs.getmonero.org/proposals/%20MoneroSignerResurrection.html).
+
+## Why
+
+[XmrSigner](https://github.com/XmrSigner/xmrsigner), while functional, is currently more of a proof of concept than a
+production-ready tool. This library addresses several key issues:
+
+1. Performance: The current implementation using wallet RPC is slow,
+especially on resource-constrained devices.
+2. Security: Minimizing dependencies and code base improves auditability
+and reduces attack surface.
+3. Flexibility: A dedicated library allows for easier integration into
+various offline signing solutions.
+4. Resource efficiency: Stripping down to essential features enables use on
+lower-power devices.
+
+By creating this library, we can:
+- Bring XmrSigner to production readiness
+- Provide a foundation for future hardware wallet development
+- Explore the viability of using even more resource-constrained devices
+(e.g., MCUs) for offline signing
+
+A proof of concept has been developed to validate this approach:
+[c_abi_for_cpp_code_PoC](https://github.com/DiosDelRayo/c_abi_for_cpp_code_PoC)
+
+This library will significantly improve XmrSigner's performance, security,
+and usability while opening doors for more diverse Monero hardware wallet
+solutions in the future.
+
+## Milestones and Timeline
+
+Given the significant time investment and potential challenges ahead, I
+propose a shift from my usual value-based pricing to an hourly rate for
+this project. 
+
+Proposed terms:
+- 120 hours per month for two months (240 hours total)
+- Compensation: 48 XMR per month (96 XMR total)
+- Additional 1 XMR for printed literature (requested at project start)
+- Total compensation: 97 XMR
+
+Hours worked beyond 120 in the first month will roll over to the second. If
+the project completes before 240 hours, unused funds can be allocated to
+future proposals or returned to the general fund. Should more time be
+needed, I'll submit a new proposal.