17 May 2022
Completed 1 of 3 milestones
I propose to spend 20 hours a week for 3 months working on Monero Core and the Monero GUI. Here are some areas, in tentative order of descending importance/specificity, that I'd work on:
My name is Jeffrey Ryan and I am a senior student at Texas A&M University, currently working on completing a computer science major with a minor in both cybersecurity and mathematics. I have always been fascinated with cryptography and digital privacy, so learning about Monero during the altcoin boom of 2017 was eye-opening and exciting. Soon enough, supporting Monero became a no-brainer for someone who is passionate about digital privacy.
I got my first PR merged on March 18th, and you can see the rest of them here: https://github.com/monero-project/monero/pulls?q=is%3Apr+is%3Amerged+author%3Ajeffro256. So far I have been doing it as a hobby, but I would love to spend more time on this project than I currently am, as I am rather busy with schoolwork and my job. As this is my first CCS proposal, I am very open to criticism and questions, so don't be afraid to ask! I will do my best to respond in the comments below.
As can be seen in this issue, among others, there appear to be malicious node(s) which advertise themselves as public nodes, allow users using the GUI wallet in "simple node" to connect, and respond with insanely high fees. This issue runs even deeper, and this exploit can be used to deanonymize GUI users to a certain degree in simple mode when they send transactions. There's no replacement for running your own node (and double-checking your fee amounts), but for those who choose not to, they should be able to expect at a minimum to not have their funds stolen from them.
Getting SSL right is difficult and nuanced. You can verify with system certificates, user-supplied certificates, accept any connection as long as it is secured, or any combination of these options. You can have certificates which sign other certificates. As it stands, the way the GUI wallet secures connections is not ideal. It more or less accepts any connection, using SSL if its available, but for no specific ccertificate, and there is not a way to specify how to connect with SSL (unlike in the CLI wallet). I want to afford the users two things: the ability to quickly asses the quality of their connections to their nodes via an elegant UI element, and the ability to tweak their SSL settings if so desired.
Unclear protocols cause bugs and choke out emerging projects which wish to incorporate into the ecosystem. Here are a couple recent PRs to fix bugs with the p2p/relay code:
While it would be quite a feat to document ALL of the cryptonote protocol, it could be helpful to more thoroughly document the Levin protocol commands and the expectations surrounding the calls (interface, relay rules, ban criteria, etc). The p2p protocol of Monero is useful not only for nodes, but also for wallets and light wallet servers, especially when using untrusted connections. This was already started in this document, but could certainly be fleshed out.
It's always a nice thing to have your code compile on all your targets. In newer versions of OpenSSL, they have deprecated a large portion of the API, much of which we rely on to secure connections in Monero, particularly RPC.
Currently, we use RSA certificates for RPC SSL, but EC certificates are smaller and thus faster. This could offer speed improvements while syncing, etc. @HYC suggested the idea while I was working on moving certain parts of the codebase to OpenSSL 3.0: https://github.com/monero-project/monero/pull/8335.
All of these points do not directly affect the end-user experience but will ultimately improve the developer experience, reducing friction in the future, contributing to the long-term health of the codebase.
Expiration Date 1 August, 2022
To be paid: 33% (20 XMR)
Completion date: 23 September 2022
To be paid: 33% (20 XMR)
To be paid: 34% (20 XMR)
Funds Awarded: 20
Date: 24 October 2022