16:58:09 <m-relay> <r​brunner7:monero.social> Meeting in 1 hour
18:00:02 <m-relay> <r​brunner7:monero.social> Meeting time. Hello! https://github.com/monero-project/meta/issues/1210
18:00:21 <m-relay> <s​needlewoods_xmr:matrix.org> hi
18:00:28 <m-relay> <j​berman:monero.social> *waves*
18:01:19 <m-relay> <j​effro256:monero.social> Howdy
18:01:37 <m-relay> <r​brunner7:monero.social> Alright, on to the reports about last week
18:02:08 <m-relay> <s​needlewoods_xmr:matrix.org> made `--generate-from-[view-key/spend-key/keys]` work, also started facing more complex stuff like e.g. how to handle `tools::wallet_keys_unlocker` in `SCOPED_WALLET_UNLOCK_ON_BAD_PASSWORD` [src](https://github.com/monero-project/monero/blob/125622d5bdc42cf552be5c25009bd9ab52c0a7ca/src/simplewallet/simplewallet.cpp#L116-L120)
18:02:16 <m-relay> <j​berman:monero.social> implemented FCMP++ scan_tx & an RPC endpoint to fetch paths in the tree by output ID: https://github.com/seraphis-migration/monero/pull/49
18:03:15 <m-relay> <j​berman:monero.social> and now working on making sure all tests passing. Once that's complete I'm going to draft a checklist for implemented features / TODO's for remaining FCMP++ / Carrot tasks
18:04:01 <m-relay> <r​brunner7:monero.social> Seems you also found some "long-hanging fruit" how to improve good old wallet2 sync speed, at least under some constellations
18:05:01 <m-relay> <r​brunner7:monero.social> with PR #9936
18:05:57 <m-relay> <j​berman:monero.social> yep that was a good push from jeffro to kick that off
18:06:35 <m-relay> <j​effro256:monero.social> I'm still working on hot/cold wallet flow for Carrot
18:06:58 <m-relay> <j​berman:monero.social> I'm not sure what issue MrCyjaneK is running into in 9936 though, have asked plows to see if they can repro too
18:07:04 <m-relay> <r​brunner7:monero.social> What you did way back for Seraphis scanning had a totally different management for threads, right?
18:08:14 <m-relay> <j​berman:monero.social> Yep the Seraphis async scanner didn't have this issue, and has additional optimizations compared to wallet2 (faster downloading and better CPU utilization)
18:08:52 <m-relay> <j​berman:monero.social> It was using koe's threadpool implementation
18:09:07 <m-relay> <r​brunner7:monero.social> Ok. By the way, maybe asked before, but I forgot the answer: How well will FCMP++ transactions prune? Will we have similar blockchain savings as today?
18:09:39 <m-relay> <j​effro256:monero.social> Lol thanks for the credit but that was all jberman
18:09:59 <m-relay> <j​berman:monero.social> all in all pretty much the same maybe even slightly better because key_offsets are empty, though Carrot outs have a little more data
18:10:32 <m-relay> <j​berman:monero.social> well there is also the tree
18:10:45 <m-relay> <j​berman:monero.social> I'd say comparable
18:10:54 <m-relay> <r​brunner7:monero.social> Good to hear. Maybe pruning will become even more important, with the blockchain growing quite a bit faster probably with FCMP++
18:11:10 <m-relay> <j​effro256:monero.social> We save at least 16 bytes per input, keep an additional 18 per output
18:12:07 <m-relay> <r​brunner7:monero.social> But a 5 kB unpruned transaction will still be 2 kB or so after pruning?
18:12:29 <m-relay> <r​brunner7:monero.social> Give or take
18:13:02 <m-relay> <j​effro256:monero.social> Should be significantly smaller than 2kb
18:13:25 <m-relay> <r​brunner7:monero.social> That would of course be very nice
18:14:05 <m-relay> <j​effro256:monero.social> The reason the chain is ~30% of the size of the real chain is that the node keeps 1/8 full blocks as well as all the normal cache tables
18:14:22 <m-relay> <r​brunner7:monero.social> Maybe some patience is needed until we hold actual numbers after implementing. But for now, if somebody asks, e.g. on Reddit, we can say that pruning has a future with FCMP++ as well
18:15:00 <m-relay> <j​berman:monero.social> the huge FCMP++ proofs can be pruned
18:15:02 <m-relay> <j​effro256:monero.social> So a pruned tx will be <10% of a full tx, but the pruned node database might still be ~30% the size of a full node
18:15:38 <m-relay> <r​brunner7:monero.social> Yeah, because so much different stuff is in there, now with extra added "tree" or however that's called :)
18:16:52 <m-relay> <r​brunner7:monero.social> Alright. Do we have something in particular to discuss today beside reports?
18:17:24 <m-relay> <r​brunner7:monero.social> Seems pretty smooth sailing on the implementation front, in comparison with the bumpy Divisor road ...
18:18:33 <m-relay> <r​brunner7:monero.social> Maybe we will hear more in the coming MRL meeting, might get interesting
18:19:05 <m-relay> <r​brunner7:monero.social> Alright, looks like we can close for today. Thanks everybody for attending, read you again next week!
18:19:18 <m-relay> <s​needlewoods_xmr:matrix.org> thank you
18:21:26 <m-relay> <r​ucknium:monero.social> The time saved in this NWLB meeting will be added to the MRL meeting this week.
18:21:27 <m-relay> <r​ucknium:monero.social> You have been warned...
18:22:08 <m-relay> <r​brunner7:monero.social> Oh come on :)
18:22:25 <m-relay> <r​ucknium:monero.social> :P