Spirobel: Robust and modular wallet-rpc library
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:
- the first part of the wallet-rpc library that can sync transactions and works reliably with remote nodes.
- A checkout flow built with this library. This is meant to be used, not just to demonstrate the features.
- 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. 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 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: 50 XMR per month (100 XMR total)
- Total compensation: 100 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 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.
Merge request reports
Activity
added 1 commit
- 65380b60 - kaya suggested adding a section on implementation details - here it is :D
Resolved by spirobelhttps://www.youtube.com/watch?app=desktop&v=4DLcsQ45zoE - implemented a Monero Browser wallet extension
Don't think that serves as proof of work, especially considering CCS rule on making all crafted code open source. Why not open a CCS to deliver that instead?
- Last reply by spirobel
- Resolved by spirobel
My main concern with this is that it's going to produce a new Rust crate that will need to have it's low-level cryptography reviewed and audited. That's a non-trivial task fraught with danger for the reviewer/auditor in question. In that sense it would make a lot more sense to me to leverage a lower-level package such as monero-wallet (soon to be monero-oxide), which has already seen use, been reviewed and (partially) audited, and is under active development and maintenance. Low-level math and cryptography do not need to be redone... that'd be more akin to reinventing the engine rather than the wheel.
Wallet code is critical code and a huge opening for attacks so the entirety of this project will need to be subjected to close scrutiny. Not just the code but also the devops of building and deploying any relevant binaries will be a critical component of guaranteeing user safety. I'm interested in how you plan to actually deliver the final WASM to the browser. Of course users should be able to build from source themselves, but what's the workflow for an actual user?
I echo concerns that time spent on an RPC wrapper would be better invested into an already-existing monero-wallet-rpc-handling crate. I encourage reusing existing work in order to ultimately reduce the amount of new code that needs to be reviewed and audited. I'd like to see more investigation into how existing crates could be leveraged to do some of the heavy lifting required for this proposal or else a compelling argument for why any existing work is insufficient for this use case, or else we'll have to accept that additional work is going to be required from outside to review any new code.
Although this is opposite of and in large part in response to wallet2 issues, these same concerns I raise with this proposal explain why I have been so excited to watch MrCyjaneK's work on wrapping wallet2 for use by Dart/Flutter and now Typescript & monero-ts. Although we can all admit that wallet2 is behemoth and a frequent stumbling-block, it's been reviewed to death: it might be clunky, but it works and it's safe. Auditing and reviewing low-level crypto is a time- and brain-intensive task and there's a serious reason why in some instances it's preferable to leverage what exists into a newer, easier to use format, rather than making some new project which duplicates not just the original coding effort but then also balloons review requirements etc. If your project is intentionally eschewing wallet2 itself, are you also going to refuse to support its API? What API do you plan to provide? Will it be bespoke, designed as you see fit/best, or will it share any semblances with existing wallet code? I expect that you will not make it wallet2-compatible--is that the case?
- Last reply by spirobel
- Resolved by spirobel
After thinking about this today, I think I'd prefer to have more Monero Rust crates than less overall, so I'd probably prefer that this work be contributed to Monero rather than just not be done because of any concerns--however valid... or invalid! :) but I'd still like to hear your answers to those questions above and I'd definitely like to see critical portions reuse code wherever possible.
If you want to do your whole own thing, that's fine, but I'd like to see CCS funds contribute to reusable projects which are interoperable with the rest of the state of the Rust art out there for Monero.
- Last reply by spirobel
Resolved by spirobelWhile the implementation details of this proposal are beyond my understanding, I do want to voice a demand for an improved monero WASM experience.
Just out of curiosity, in regards to re-using audited code, how would that work? Like copy paste from the audited project? Do I understand correctly you will start a new code base from scratch and add to it? Or do you plan on using an existing codebase and strip away functionality?
In my opinion there is a huge potential for the vision of a simpler Monero experience in the browser.
- Last reply by spirobel
- Resolved by spirobel
I may not have read text thoruoughly enough or my lack of sleep is getting to me. What kind of library will the end-result be? What is the difference to https://github.com/woodser/monero-ts?
Edited by binarybaron - Last reply by spirobel
- Resolved by spirobel
I wonder quite a bit how you arrive at an estimate of merely 2 work months to implement all the things in the What section. Frankly, my immediate first gut feeling reading this was "Isn't that estimate totally unrealistic? How about half a year of fulltime work, or even more?"
Can you maybe detail a bit where you can start with this? E.g. what code is already there and can be copied / modified instead of written from scratch, to hopefully clarify how you want to build this in merely 2 months.
- Last reply by spirobel
-
<@m-relay:monero.social> <plowsof> Spirobel how much of the extra 30xmr is for ccs bureaucracy spirobel so that every proposer can add this to their ccs. We can call this the CCS Added Tax (CAT)
spirobel: lets just stay professional. I would rather write code and do something productive. What is the ETA on the merging for this proposal? do you need any addtional information from me ?
...like deliver something to build rapport with the CCS? None of the X links have an actual deliverable, just teasers. The I'm not getting paid excuse doesn't fly: plenty other contributors volunteered work hours and delivered something as proof of work and then they ran their CCS projects.
Not to bring up the unnecessary social media conundrums over failed Afghanistan virtue signaling stunt, Cake Wallet x Justin VP resignation and conspiracy theories about feds, mocking of downvoting bot in subreddit. Quite the portfolio. Now we gotta add the response above.
Edited by rottenwheel added 1 commit
- a71dd4b8 - add direct links to the github repositories of my open source work ( months of...
