Progress on the deliverables of this CCS look solid to me. I think a 50% payout is justified.
Aaron gave a brief progress update in today's MRL meeting:
Yeah, we've identified a number of issues so far. There's a fair amount of notation that's incomplete or incorrect, several points in the proofs that we needed to expand on significantly for correctness, one proof that was incorrect (and even had an incorrect statement) that we rewrote, and another whose validity we're still attempting to verify
This (incomplete) draft corroborates that progress update.
Update 1
188 hours
Full chain membership proofs
./unit_tests --gtest_filter="seraphis_tx.seraphis_squashed_fcmp"
./unit_tests --gtest_filter="seraphis_integration.txtype_squashed_v2"
./performance_tests --filter "test_curve_trees_fcmp"
Async wallet scanner
Nothing to report in this update. I plan to work on completing my draft PR as my next task (starting today), then move back to fcmp work.
Misc.
Work full-time 3 months on:
monerod
instance @selsta spun up, I observed a ~40% speed-up in scanning over the current wallet2 scanner.j-berman on github / jberman on matrix
Past CCS's:
211 XMR
480 hours, 0.16 XMR/hr + $48/hr, $172/XMR from coingecko
Justin Berman (3e2d9667) at 12 Dec 05:30
j-berman full-time 3 months (part 6)
... and 491 more commits
Hours worked: 500+
Hours worked: 342
test_curve_trees
performance test (<build dir>/tests/performance_tests/performance_tests --filter "test_curve_trees"
)./getblocks.bin
RPC endpoint.Update 1
Hours worked: ~250
After a solid review from @rbrunner7 on my wallet background sync PR triggered further discussion on the feature, I ended up making significant changes to the PR which ended up dominating my time. I implemented the core changes discussed and submitted them for review yesterday.
I also moved forwards with the async scanner in the Seraphis wallet lib as explained below.
I expect continuing work on background sync will take up a slice of my time going forward, but I still expect I will be able to continue making progress on the Seraphis wallet lib async scanner, and make initial progress on full chain membership proof integration before my CCS is complete.
Following discussion with @rbrunner7, @valldrac and @sgp, I made significant changes to the background sync PR in order to support devs who want to offer optional auto-background sync without a user needing to manually open their wallet first. With this option, a user's system could have perpetual access to the user's view key and not spend key. Mobile wallets for example could keep a separate randomly generated password stored in the device's secure key store, which can be used to auto-background sync without loading the spend key into memory at any time.
Before this change, the feature did not enable users to grant their system perpetual access to just the user's view key and not spend key, and required the user to open their wallet first (and load their spend key into memory) before background sync could trigger (wiping the spend key from memory at that point). This method of background syncing is still supported (require user open their wallet first -> background sync when user goes inactive); wallet devs have also indicated interest in this form of syncing (@r4v3r23 and @tobtoht here).
See the PR description for a more detailed explanation of how it works.
conn_pool.rpc_command<cryptonote::COMMAND_RPC_GET_VERSION>(sp::mocks::ClientConnectionPool::invoke_http_mode::JON_RPC, "get_version", req_t, resp_t);
Nothing significant to report on this end from me yet.
For the record, I was aware from the start kayaba intended to make a CCS for retroactive funding and I supported kayaba's decision to do so because I figured this endeavor would be a clear demonstration to the community why retroactive funding can be useful and reasonable. When I agreed to kayaba's deal, similar to kayaba, I was also unsure if my work would pan out successfully nor did I know if it would take me a reasonable amount of time, so I wasn't comfortable opening a CCS to do my slice of work at that time. The completion of this work gave me the confidence to include continuing work on it in my latest proactive CCS.
An open-ended bounty would have been a fine alternative. But I generally do believe retroactive funding is a sensible tool the CCS can wield to bring maximum benefit to Monero's code, if used correctly. I understand the view against it as well and how establishing a strong precedent for it can open the CCS for abuse. I think it is like any tool in that it can be used incorrectly. I believe this set of circumstances demonstrates why it's a powerful and useful tool that can be wielded to benefit Monero.
Was requested to make a comment providing feedback. To be clear, I am 100% for this proposal.
On the retroactive nature of this proposal: I think contributions that certainly help move the needle on critically important tech in Monero should be rewarded. People who show up with valuable contributions, including anons with no prior history, should be paid the value of their contribution (if they want to get paid) within reason in my opinion. Establishing a stronger precedent for that I think is a good thing.
On the general work done in this proposal: it was a well sized step toward trustless full chain membership proofs. Specifically toward answering questions:
This work is critically important toward routing a potential major upgrade path. It's therefore critically important work.
On my work done in this proposal: I put in a fairly solid chunk of time to help bring verification time down a significant amount and explored a route where it could be brought down further and which could benefit Monero today (without a fork). The latter work is still potentially worth further exploration to bring verification time down some small % today (I think it's probably closer to a micro optimization though). I figure it is self evident why this work is useful toward helping gauge the efficiency of full chain membership proofs as proposed.
Justin Berman (ebdfb516) at 29 Jul 04:14
Work full-time 3 months on:
monerod
.
monerod
instance @selsta spun up, I observe a ~40% speed-up in scanning over the current wallet2 scanner.j-berman on github / jberman on matrix
Past CCS's:
216 XMR
480 hours, 0.16 XMR/hr + $48/hr, $166/XMR from coingecko
Justin Berman (ebdfb516) at 20 Jul 23:53
j-berman proposal to work 3 months full-time pt. 5
... and 438 more commits
+1
Awesome to see this proposal. I don't think @vtnerd needs much vouching for considering his ample work on Monero speaks for itself, but I will vouch for his excellent work (and critical eye) on Monero over the years anyway. He's a huge asset for Monero and I'm grateful he's opening another CCS.
the API needs to be settled, etc., before any clients will add support
@RealCryptoGrampy can you expand on this? There are clients willing to support it but this issue in particular is what's holding them back? I wasn't aware (or forgot :/), but if so, yea I would definitely say worth including it 100%. Without client-side support on the immediate radar it would seem like unnecessary effort to me.
I've been kicking around this idea of a TUI wallet that uses Term-Ox... but the LWS concept has great value that goes unnoticed because the wallet options are sparse
This sounds cool. I very much so agree with the latter point
I kept that initial PR as "do not merge" for a few reasons:
The problem is that once I add support, MyMonero (or some other wallet) needs to add support too.
I agree this is the most significant issue. Moving forward on the proposed spec is imo the preferred next step to getting it implemented server-side, but without a client that supports the feature, it's hard to see much value in that. Last I spoke with people from MyMonero, subaddress support wasn't a priority for them.
Ah, I see. Thank you for clarifying. In any case, I appreciate the level of discourse you brought to the Seraphis working group yesterday and would definitely appreciate more of it in the future. I still consider it likely you'll be able to see additional ways to benefit upstream through your work. Ideally the Seraphis lib will be easier for devs of all kinds to use optimally than wallet2 is today, so feedback to that end will prove valuable.
Echoing some thoughts previously shared, a skilled and motivated dev implementing wallet2's core functionality from the ground up is a benefit to Monero in my view. I'd wager @valldrac will probably continue to see more things through the process that could benefit upstream. Even if not, while I'm not an Android dev, I can definitely see Android devs appreciating a lightweight and streamlined Android focused SDK without the baggage that comes from binding Monero core; all of @valldrac's arguments for a native Android SDK seem sound to me.
Join the Seraphis Working Group to provide feedback, share design ideas, and review migrations plans for a smooth transition to Seraphis.
A dev with experience re-building wallet2 from the ground up willing to engage and smooth the Seraphis transition is a +1.
@valldrac, one major thing to watch out for while working on this (assuming this comes to fruition) is to avoid fingerprinting transactions created with this SDK. This includes subtle things like including a random payment ID on every tx, using fees identical to wallet2, and a decoy selection algorithm identical to wallet2's (@kayabaNerve can probably comment more on this from their work on monero-serai
which I'm also currently helping with). It's not a trivial task to get this right (and keep it right for the lifetime of the SDK), but if you're sufficiently motivated and willing to put in the effort as it seems you are, I think this SDK could prove very valuable.
Total hours worked: way over 480 (I stopped keeping track at 480).
Since last update, I completed a mock implementation of an optimized wallet scanner that points to a live daemon, using an asynchronous architecture that @koe came up with + wallet utilities from the Seraphis library. When scanning via a remote daemon that @selsta is running, I observed a speedup of ~35-45%. When scanning via a local daemon, I observed a speedup of ~5-10% on my machine (same as in prior updates above). To be clear, this is legacy wallet scanning meaning this scanning code should be usable to see these kinds of speedups today and does not require any changes to Monero's consensus nor have any impact on privacy (though it's not production ready yet).
My code is here: https://github.com/j-berman/monero/tree/1180c8262e405708411d166ef3cb36bd5f98cb92
I wrote a utility program called monero-blockchain-scanner
that anyone can use to benchmark this scanner and compare it to wallet2 (wallet2 contains the scanner most wallets use today [GUI, CLI, RPC, Feather, Monerujo, Cake + I'm sure others]). To run the program, build the code linked above, then from your CLI, cd to the bin
directory and run the following command:
./monero-blockchain-scanner --daemon-address 88.99.173.38:18099 --start-height 2840000
@selsta is running a modified daemon at that address and will likely take it down at some point (thank you @selsta!!!). To use your own node, you can either build the code above and run monerod
from the bin
directory, or you can apply this patch on top of v0.18.2.2.
I'm planning to open a new CCS soon to get this scanner to production ready and continue with Seraphis wallet work.
I made the following deal with @kayabaNerve: if he progresses research into trustless full chain membership proofs for Monero to the point that this research can be handed off and run with, I will do a comparable amount of work on Serai, the cross-chain DEX. He held up his end of the deal and as such, I will do a comparable amount of work on Serai. My CCS work on Monero is still my number 1 priority and will continue to dominate my focus and attention. I figure it's also worth noting that my first task I'm working on for Serai is ensuring that monero-serai
calculates the same fees that wallet2 calculates when constructing a tx, and uses the correct decoy selection algorithm. This is a step toward making monero-serai
a usable library for production wallets today.
Update 2: 382 hours