<r​brunner7:monero.social> Meeting in a bit less than 1 hour

<r​brunner7:monero.social> Meeting time. Hello! monero-project/meta #1279

<j​berman:monero.social> *waves*

<s​needlewoods_xmr:matrix.org> Hey

<j​effro256:monero.social> Howdy

<v​tnerd:monero.social> hi

<r​brunner7:monero.social> Alright, I think we can already start with the reports from last week

<r​brunner7:monero.social> I can soon make a film out of the FCMP++ GitHub repo mails that I receive, starting with 24 pieces per second :)

<s​needlewoods_xmr:matrix.org> made a [PR](monero-project/monero #10165) for the issue where estimated block height is above actual block height

<s​needlewoods_xmr:matrix.org> also made a little progress on the CLI, `sweep_single` should be done, `m_wallet` count is down to 15

<s​needlewoods_xmr:matrix.org> ~30 TODO comments left, an incomplete list of some of the things:

<s​needlewoods_xmr:matrix.org> - `cold_sign_tx()`

<s​needlewoods_xmr:matrix.org> - `--restore-multisig-wallet`, `--generate-from-json`

<s​needlewoods_xmr:matrix.org> - handling of some exceptions and error messages (e.g. [handle_transfer_exception](github.com/monero-project/monero/bl…/simplewallet/simplewallet.cpp#L617))

<s​needlewoods_xmr:matrix.org> And I want to mention that I received an offer from binarybaron to spend some hours reviewing their wallet code. That could be a good incentive to learn rust. Of course my CCS would have priority, I'd aim to spend 20h/week (12h/week were advertised and the total is already exceeded, though I really want to finish it) on that and only work on eigenwallet if I have time beyond that,<clip

<s​needlewoods_xmr:matrix.org> but I think I'm relatively close to getting into review phase for the CLI (hopefully not more than a month until a PR is made) and if I don't have enough CCS work by then, I'd spend more time on the eigenwallet review.

<s​needlewoods_xmr:matrix.org> Any thoughts/opinions?

<v​tnerd:monero.social> I got carrot subaddresses working lws, but I had to modify make_carrot_subaddress_v1 (used in unit test), and tweak the relevant carrot spec. Eagerly waiting to get feedback on whether my tweak was valid

<j​berman:monero.social> me: almost exclusively worked on stressnet issues, made a number of PR's fixing some connectivity issues and wallet slowness, continuing investigating different issues

<s​needlewoods_xmr:matrix.org> btw it was jbermans suggestion to use recent hard fork height from `hardforks.cpp`, which I think was a great idea

<j​effro256:monero.social> Where is the tweak at?

<v​tnerd:monero.social> I just PR’ed something to your carrot repo

<v​tnerd:monero.social> ~15 mins ago

<v​tnerd:monero.social> it was pretty minor as all of the unit tests still pass, but it affected the make_carrot_subaddress_v1 function which I was using in a lws unit test

<j​effro256:monero.social> Okay responding to that now

<r​brunner7:monero.social> SNeedlewoods: IMHO such a course of action regarding your work hours, as you described it here, would be ok. How do other people here see this?

<r​brunner7:monero.social> I think there were times also where jberman distributed time to his Monero CCS and some Rust / Serai work. As long as it's done in good faith, and in the open, I don't see a problem.

<j​berman:monero.social> IIUC, binarybaron is offering to pay you separately from your CCS to review their wallet code?

<s​needlewoods_xmr:matrix.org> yes

<j​effro256:monero.social> me: reworked large portions of the Carrot Rust library and opened a PR to hopefully speed input verification in many large-load cases: monero-project/monero #10157

<j​berman:monero.social> no issue at all with that! pretty cool of binarybaron

<j​effro256:monero.social> vtnerd: jeffro256/carrot #5#issuecomment-3398566553

<s​needlewoods_xmr:matrix.org> thanks for the feedback, appreciate it :)

<j​berman:monero.social> 1 other related task that I think would be very nice re: that wallet restore stuff SNeedlewoods is finding a way for wallets with an expected daemon connection to set the restore height using the daemon's reported height, rather than the offline estimate

<r​brunner7:monero.social> jeffro256: Just curious, was that Carrot Rust library rework a result of insights and experience gained in the meantime, since writing the original library version?

<j​berman:monero.social> offline estimate is a welcome improvement for sure tho

<j​berman:monero.social> we discussed that connection stuff a bit last week, those logs may be helpful

<j​effro256:monero.social> kayabanerve: gave a lot of good feedback on how to make it Rustier

<r​brunner7:monero.social> Rustier, lol

<j​berman:monero.social> (and this PR sort of mentions it: seraphis-migration/monero #162 , we probably shouldn't need to override the restore height in that step 2, it's only there because the wallet's initial creation isn't using a functional daemon connection)

<s​needlewoods_xmr:matrix.org> isn't that already happening here github.com/monero-project/monero/bl…/src/wallet/wallet2.cpp#L5703-L5729

<s​needlewoods_xmr:matrix.org> or am I misunderstanding?

<j​berman:monero.social> problem is when that's called with the GUI e.g., the wallet doesn't have the connection to the daemon established yet

<s​needlewoods_xmr:matrix.org> I also looked in the GUI side, but didn't have enough time to figure out how that works exactly, but it seems it uses `restore_height` from `persistentSettings`, and that is the restore height of the wallet that was opened before

<s​needlewoods_xmr:matrix.org> will try to figure that out this week

<j​berman:monero.social> the context described in that linked PR description may help

<r​brunner7:monero.social> Regarding that potential Carrot sub-address generation problem: One would really hope that if there was a problem in there, audit(s) should have unearthed it already?

<r​brunner7:monero.social> A problem of that magnitude that gets through until implementation and only gets stopped by some unit tests failing would worry me ...

<r​brunner7:monero.social> We will certainly soon see how this plays out :)

<r​brunner7:monero.social> Alright, seems we are through with reports and coordination. Anything else to discuss today?

<j​effro256:monero.social> It shouldn't be an issue AFAIK, it looks like a notation mixup

<j​berman:monero.social> rbrunner7: you might be interested in this PR: seraphis-migration/monero #162

<j​berman:monero.social> it touches the incremental pool stuff

<j​berman:monero.social> to make refresh/show_transfers fast on every call

<r​brunner7:monero.social> ... that my old brain probably already forgot almost completely

<r​brunner7:monero.social> No, seriously, will try to have a look

<s​needlewoods_xmr:matrix.org> I'm happy to test it when new release is out

<s​needlewoods_xmr:matrix.org> nothing else to discuss for me

<r​brunner7:monero.social> So we won't prevent busy people working on stressnet any longer! Thanks for attending everybody, read you again next week

<s​needlewoods_xmr:matrix.org> thanks everyone