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

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

<s​needlewoods_xmr:matrix.org> hello

<j​effro256:monero.social> howdy

<s​yntheticbird:monero.social> hi

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

<r​brunner7:monero.social> Alright, onwards to the reports from last week

<s​needlewoods_xmr:matrix.org> made great improvements on the Wallet APIs `wallet_keys_unlocker` thanks to jeffro

<s​needlewoods_xmr:matrix.org> also finally fixed the bug that made `verifyPassword()` fail after make_multisig

<r​brunner7:monero.social> So the hunt for the last remaining pieces of direct wallet2 use in the CLI wallet can continue :)

<s​needlewoods_xmr:matrix.org> yay, way more fun than starring at the debugger :D

<r​brunner7:monero.social> If the bug is interesting ...

<j​berman:monero.social> me: fixed a couple bugs testing forking from current testnet (in the migration and in scanning) in prep for alpha stressnet, cleaned up the FFI (removed unwraps/asserts, used int error returns to gracefully handle errors, de-duplicated some code with macros, clippy+fmt), implemented consolidated paths in the RPC for getting paths in the tree by global output id, started on a bette<clipped messag

<j​berman:monero.social> r organizational structure for curve trees logic in the db code, tested kayaba's latest prove/verify optimizations (good results!!)

<j​berman:monero.social> Planning to complete organizational structure in the next day, then moving to documentation/Carrot review, in prep for opening PR's to the main Monero repo

<j​berman:monero.social> Good news: kayabanerve implemented linear prove() times, dropping 128-input tx construction down from 5m30s to ~1m!! Huge

<j​effro256:monero.social> me: initiated communication about Carrot follow-up review by Cypherstack, updated FCMP++ benchmark tool for all the latest FCMP++ changes (github.com/jeffro256/clsag_vs_fcmppp_bench/), working on supporting high input counts in benchmark tool, working on patches in Monero core repo, re-reviewing the de-dup PR by rbrunner7, reviewed several PRs in seraphis-migration, did a write-up<clipped mess

<j​effro256:monero.social> for an upcoming vuln disclosure, helped prepare v0.18.4.2 release

<r​brunner7:monero.social> Rucknium answered jeffro256 's questions that came up during his review, and I made the requested (smaller) changes. I think it's ready now for a second review, that certainly seems a good idea because of the importance of the code: monero-project/monero #9939

<r​brunner7:monero.social> "an upcoming vuln disclosure". Oh, always interesting. Did the fuzzing already turn up something auctionable?

<k​ayabanerve:matrix.org> 👋

<k​ayabanerve:matrix.org> I deduplicated 25k lines of code and optimized FCMP++ prove. Apologies for being a few minutes late to the meeting.

<r​brunner7:monero.social> That's the 5 times speedup that jberman mentioned?

<j​effro256:monero.social> Yes, but this specific one isn't related to the fuzzing group. The report will go up as soon as v0.18.4.2 binaries are out, not sooner so users don't get confused.

<k​ayabanerve:matrix.org> I also raised the topic of migrating the hash to point algorithm with FCMP++s after finally successfully identifying the present algorithm.

<k​ayabanerve:matrix.org> Largely rbrunner7

<j​effro256:monero.social> But if you're self-compiling for your own wallet, just make sure to be on the latest release-v0.18 or master branch.

<r​brunner7:monero.social> Just curious, what is there to win if we migrate to another "hash to point" algorithm? A bit faster?

<r​brunner7:monero.social> jeffro256: Thanks for the hint

<k​ayabanerve:matrix.org> Bits of security currently being lost.

jeffro256 would this be on -site as a blog post also - pushed at the same time binaries are?

<k​ayabanerve:matrix.org> We currently use keccak256. Would you be happy if I set the first byte to 0 after every usage?

<k​ayabanerve:matrix.org> We currently use a hash to point which has an explicit bit of bias and probably has further bias after.

<r​brunner7:monero.social> Is this a trick question :)

<k​ayabanerve:matrix.org> a new hash to point just tightens everything back up

<k​ayabanerve:matrix.org> It's also only ~10 lines of cryptography. It just invokes the existing hash to curve twice. It isn't a major change re: cryptography

<r​brunner7:monero.social> And no hairy compatibility issues if we switch that algorithm? Or will it be done in standard version based way?

<r​brunner7:monero.social> Before like so, afterwards differently

<j​effro256:monero.social> plowsof: yes that could be done

<k​ayabanerve:matrix.org> New outputs are added to the tree with a key image generator sampled using the new hash to point

<k​ayabanerve:matrix.org> Old outputs are added to the tree with their key image generators sampled using the existing hash to point

<k​ayabanerve:matrix.org> The world keeps spinning

<r​brunner7:monero.social> Alright :)

<j​effro256:monero.social> It's a type of vuln that doesn't really benefit much from being hidden from attackers since it's a data leak, it mainly just hurts users the longer they don't update. If it makes sense, perhaps a report PR can be made to the monero-site, but I just don't want it to spread on social media sites before the release binaries are posted, and cause confusion

<j​effro256:monero.social> @selsta

<j​berman:monero.social> plowsof: bumping this PR too not sure who else to bump to: monero-project/monero-site #2510

<r​brunner7:monero.social> Ok. Anything else to discuss today beyond these reports?

<r​brunner7:monero.social> Doesn't look like it. I think we can close. Thanks everybody for attending, read you again next week!

fuzzing found issues but so far none have been exploitable

<s​needlewoods_xmr:matrix.org> thanks everyone

<r​brunner7:monero.social> Good to hear, selsta.

<r​brunner7:monero.social> By the way, SNeedlewoods , it looks as if eigenwallet really went the API way instead of using wallet2 directly, which is nice: libera.monerologs.net/monero/20250712#c540320

<j​effro256:monero.social> Yes, sorry, I should have been more clear about the changes made due to the fuzzing group: actionable, but not exploitable.

<j​effro256:monero.social> Thanks everybody

<r​brunner7:monero.social> (There must be some more recent statement, but can't find right now)

<s​needlewoods_xmr:matrix.org> had a chat with the devs a while ago and gave them a link to the branch I'm currently working on, so they can track the most recent changes to the API

<j​effro256:monero.social> rbrunner7: about the changes?

<j​effro256:monero.social> for fuzzing?

<r​brunner7:monero.social> Er, no, about eigenwallet using the API

<j​effro256:monero.social> Oh okay nvm