monero-ccs-proposals/vtnerd-2024-q3.md
2024-10-26 14:18:07 +00:00

4.3 KiB

layout title author date amount milestones payouts
wip vtnerd full-time 2024 q3 Lee Clagett (vtnerd) July 11, 2024 208.12 XMR
name funds done status
Month 1 (160 hours) 69 XMR 24 August 2024 finished
name funds done status
Month 2 (320 hours) 69 XMR 03 October 2024 unfinished
name funds done status
Month 3 (480 hours) 70.12 unfinished
date amount
4 September 2024 69
date amount
26 October 2024 69
date amount

3-Months full-time software development on monero "core" components in 2024 q3.

What

Work primarily on the monerod, wallet, and monero-lws. Some of the work to be attempted or investigated:

  • Code reviews of monero core PRs
  • Optimization work in monero core (work with the new stressnet team)
  • Add socks5 support to wallet and monerod (which adds IPv6 support to proxies)
  • Add support for torspec/control-spec. This is similar to the SAM proposal for I2P
  • Get new serialization routine merged (continue work on piecemeal PRs for reviewers sake)
  • Complete work necessary to merge DANE/TLSA in wallet2/epee.
  • Adding trust-on-first-use support to wallet2
  • Add msgpack support to monerod-ZMQ (requires merging of new serialization system)
  • monero-lws work:
    • Complete LWS frontend (using wallet_api.h as interface) so that wallets can begin using LWS API easily. This is separate from woodser et al working on LWS API within wallet2 which may be deprecated.
    • Perform apache-benchmark test on REST api to determine effects of blocking ZMQ calls
    • Cache some ZMQ calls performed during REST api responses to reduce burden on monerod and improve REST throughput
    • Add concurrency to REST API responses - remove blocking ZMQ calls which starve valuable REST thread resources
      • A switchover to boost asio/beast/azmq from epee/zmq to handle async http responses will be needed
      • get_random_outs endpoint has blocking ZMQ calls that cannot be cached, thus the potential need for async-zmq
    • Add a "scale" factor to remote scanning load balancing - send more accounts to systems with faster single thread performance
    • Add 64-bit ed25519 code for faster arm64 scanning
    • Provide official LWS docker-image
    • Provide pre-built binaries
    • (Unlikely) - reproducible builds so community members can verify+sign the binary hashes

There is intentionally more work than time allows - to ensure there is always something to work on in the proposal.

Who

Lee Clagett (vtnerd). I've had four CCS proposals (last one), and one Magic Grant.

Some of my biggest features in monero core repo are Dandelion++, adding supercop ASM speedups to wallet code, ZeroMQ Pub Support for new blocks and transactions, and SSL support to p2p.

I've also made a functional LWS wallet scanner under CCS/Magic - which now has a MyMonero compatible REST API, admin REST API, LMDB storage, subaddress support, webhook/zmq/rmq publishing (new receives, spends, and accounts), multi-machine scanning with (primitive) load-balancing, and an untrusted daemon mode that verifies PoW is valid (whereas normal wallets trust monerod responses entirely).

Proposal

Work on the various tasks outlined above for 40 hours/week over the next 3 months after potential funding. I already use time-tracking software for work; if the hours dip in a given month unexpectedly, the update/milestone will be at the completion of the hours listed above.

The funds were calculated with 65 USD/hour with ~157.41 USD/XMR which is the 9-day exponential moving average on Kraken through 2024/07/11. The rate is up a bit: (1) inflation, (2) volatility protection, and (3) closer in hourly compensation to 2 other contributors.