14:11:20 <m-relay> <s​needlewoods_xmr:matrix.org> 02f
14:11:21 <m-relay> <s​needlewoods_xmr:matrix.org> ////
14:11:23 <m-relay> <s​needlewoods_xmr:matrix.org> // BalanceExclusions
14:11:25 <m-relay> <s​needlewoods_xmr:matrix.org> // - Enotes that match with a balance exclusion will not be included in a balance calculation.
14:11:27 <m-relay> <s​needlewoods_xmr:matrix.org> ///F0c+*ü9ä,
14:13:56 <m-relay> <s​needlewoods:monero.social> sry spilled some stuff over my laptop
14:16:54 <moneromooo> Well, you won big at the monkey with a typewriter competition I guess.
14:37:38 <m-relay> <s​needlewoods:monero.social> clipboard content could've been worse
16:52:43 <m-relay> <r​brunner7:monero.social> Meeting in a bit more than 1 hour
17:59:56 <m-relay> <r​brunner7:monero.social> Meeting time. Hello! https://github.com/monero-project/meta/issues/1255
18:00:22 <m-relay> <s​needlewoods_xmr:matrix.org> hey
18:00:29 <m-relay> <j​effro256:monero.social> Howdy
18:01:08 <m-relay> <j​berman:monero.social> *waves*
18:01:29 <m-relay> <r​brunner7:monero.social> Alright, with that wave we can start with the reports from last week
18:02:51 <m-relay> <s​needlewoods_xmr:matrix.org> I wrote a wrapper so `wallet_keys_unlocker` can be used by the Wallet API ([commit](https://github.com/monero-project/monero/commit/c995b8dd03ab7a3d7e03cf078142144a49ae2bbd)), also based it onto jeffros improved version [#9860](https://github.com/monero-project/monero/pull/9860), was excited when the tests passed, but after testing `make_multisig` manually from the CLI it still do<clipped 
18:02:51 <m-relay> <s​needlewoods_xmr:matrix.org> esn't work, so will have to do more debugging.
18:02:58 <m-relay> <s​needlewoods_xmr:matrix.org> Would be nice to get some feedback on the commit, it feels a little messy with all the forward declarations and I'm not sure there may be room for improvements
18:03:34 <m-relay> <v​tnerd:monero.social> Hi
18:03:58 <m-relay> <s​yntheticbird:monero.social> hi
18:03:59 <m-relay> <r​brunner7:monero.social> Uh, that #9860 PR looks pretty wild, with all those issues about something so small ...
18:04:41 <m-relay> <r​brunner7:monero.social> Is that not yet merged because a second review is missing?
18:05:46 <m-relay> <s​needlewoods_xmr:matrix.org> also re-review was requested after two small changes afaict
18:06:13 <m-relay> <j​berman:monero.social> me: no significant update from last week (was mostly unavailable for personal reasons unrelated to the mainnet situation, I'm back at 100% now). Patched a bug reported by ofrn (fcmp++ wallet refresh recovering from daemon popping blocks correctly), currently investigating another. Once this final set of bugs is out of the way, I intend to take next steps on alpha stressnet (settin<clipped messag
18:06:13 <m-relay> <j​berman:monero.social> g a start date, writing a post with instructions on how to join, etc.)
18:07:04 <m-relay> <r​brunner7:monero.social> Sounds like the real fun can soon start then. allpha net will be a pretty milestone I think.
18:07:10 <m-relay> <j​effro256:monero.social> Me: I mostly worked on consensus based hash changes, unrelated to Qubic stuff (e.g. https://github.com/monero-project/monero/pull/10038)
18:07:49 <m-relay> <r​brunner7:monero.social> What is an "intermediate PoW hash"?
18:07:59 <m-relay> <j​effro256:monero.social> I also want to propose a new Carrot math audit at the next MRL to address some small things: https://gist.github.com/jeffro256/12f4fcc001058dd1f3fd7e81d6476deb
18:08:41 <m-relay> <j​effro256:monero.social> It enabled tevador's idea to be able to partially check PoW without needed to use RandomX, but a much smaller, lighter function Blake2B
18:09:02 <m-relay> <j​effro256:monero.social> SNeedlewoods: looking at that commit now
18:09:06 <m-relay> <o​frnxmr:monero.social> got my fcmp testnet up to ~18mb blocks, mining stopped for now while jberman investigates an issue
18:09:10 <m-relay> <r​brunner7:monero.social> Ah, I see. That's floating around for quite a while already
18:09:26 <m-relay> <r​brunner7:monero.social> https://github.com/monero-project/monero/issues/8827
18:10:16 <m-relay> <j​effro256:monero.social> Yes, exactly
18:10:29 <m-relay> <j​effro256:monero.social> Will link that in the PR, thanks
18:11:31 <m-relay> <r​brunner7:monero.social> So this Carrot follow-up audit will preferrably go again to CypherStack, to profit from pre-knowledge?
18:11:49 <m-relay> <j​effro256:monero.social> Yes, it *should* be relatively quick I think
18:12:19 <m-relay> <j​effro256:monero.social> Haven't solicited quotes yet, just wanted to see if anyone would be opposed to it
18:13:11 <m-relay> <j​berman:monero.social> Proposed follow-up audit lgtm
18:14:27 <m-relay> <r​brunner7:monero.social> Yeah, checking again can't be wrong. If a problem sneaked in, however unlikely that is, we must know.
18:15:00 <m-relay> <o​frnxmr:monero.social> also to note that my fcmp testnet is using jbermans 128in pr, and i feel the public /alpha test/stress net should as well
18:15:09 <m-relay> <j​effro256:monero.social> Agreed
18:15:42 <m-relay> <r​brunner7:monero.social> For the record, and for visibility, here a link to kayabNerve's CCS proposal to harden Monero against certain attacks, the "Finality Layer Book": https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/604
18:15:59 <m-relay> <r​brunner7:monero.social> Don't be shy, make your voice heard
18:16:11 <m-relay> <j​berman:monero.social> I'll share a comment on that proposal soon
18:16:20 <m-relay> <j​berman:monero.social> likely today
18:17:15 <m-relay> <o​frnxmr:monero.social> The ccs isnt to do any implementation, and shouldnt be misinterpreted as monero is going yo use a tfl, but solely the book, explaining/documenting the proposed solution
18:17:39 <m-relay> <r​brunner7:monero.social> It's unfortunate that we probably will have *two* monster projects running side-by-side, at least for some time, but you can't choose that.
18:17:57 <m-relay> <o​frnxmr:monero.social> So the ccs isnt "to harden monero against certain attacks", but to write a book about it
18:19:31 <m-relay> <r​brunner7:monero.social> You are right, too easy to misunderstand the way I put it. But anyway, the *idea* is that this book will lead to a way to harden Monero - if we do anything at all in this direction of course.
18:20:13 <m-relay> <r​brunner7:monero.social> I guess we have many quite controversial discussions ahead on the way to that.
18:22:09 <m-relay> <r​brunner7:monero.social> Ok, do we have to discuss something today beyond these reports?
18:23:22 <m-relay> <r​brunner7:monero.social> For mere length of meeting, MRL wins hands down for quite a while :) We might have more to coordinate once the alpha net starts.
18:23:59 <m-relay> <s​needlewoods_xmr:matrix.org> last MRL meeting no one told me to bring water, was very dehydrated at the end
18:24:08 <m-relay> <r​brunner7:monero.social> Lol
18:24:51 <m-relay> <r​brunner7:monero.social> I think we can close for today. Thanks everybody for attending, read you again next week!
18:25:07 <m-relay> <s​needlewoods_xmr:matrix.org> thanks everyone, cu
18:28:03 <m-relay> <o​frnxmr:monero.social> [@jeffro256:monero.social](https://matrix.to/#/@jeffro256:monero.social)  for wallet devs, if fcmp++ basically plug-and-play?
18:28:36 <m-relay> <o​frnxmr:monero.social> (For wallet_api wallets)
18:29:18 <m-relay> <o​frnxmr:monero.social> xyproblem: if i built a wallet like monfluo and swapped in the fcmp repo, would it "just work"?
18:30:26 <m-relay> <j​effro256:monero.social> Yes, mainly. Hot/cold wallets will have a hiccup in the API regarding fetching private tx keys, but regular wallets should "just work" after PR #73 was merged AFAIK
18:30:37 <m-relay> <j​effro256:monero.social> That's the goal
18:31:06 <m-relay> <j​effro256:monero.social> Please lmk if that's not the case
18:34:06 <m-relay> <s​needlewoods_xmr:matrix.org> just had a quick look at the `fcmp++stage` branch, kinda surprised how little has changed in the /api/ subdir
18:36:01 <m-relay> <j​effro256:monero.social> Yup that's the goal. Carrot is backwards compatible with the existing address scheme, FCMP tree building can/should be done during normal wallet refresh, and FCMP++ proof building is more or less an internal feature to transaction construction
18:48:33 <m-relay> <v​tnerd:monero.social> Which is good because all of this lws/lwsf/wallet work wouldve been partially wasted
18:49:05 <m-relay> <v​tnerd:monero.social> I just have to figure out how to get fcmp++ working with lwsf, etc
19:00:18 <m-relay> <j​effro256:monero.social> The main difference at a conceptual level for light wallets is that they don't do a full refresh, which means that they wouldn't be doing FCMP tree building, which means they can't construct FCMP++ tx proofs normally.
19:00:53 <m-relay> <j​effro256:monero.social> During transaction construction, light wallets should fetch FCMP tree paths from the daemon for outputs to be spent (or all owned)
19:01:23 <m-relay> <j​effro256:monero.social> This somewhat assumes that spending privacy is already gone for light wallets from the perspective of the daemon
19:01:56 <m-relay> <j​effro256:monero.social> Optionally, you can also fetch FCMP *decoy* paths to get ring-signature-like privacy against the daemon
19:55:54 <m-relay> <v​tnerd:monero.social> I mean I was assuming that the view-balance-key would be used by lws in the future anyway. its just an unfortunate tradeoff
19:56:19 <m-relay> <v​tnerd:monero.social> technically the server effectively knows when a spend occurs anyway (now)