<s​needlewoods_xmr:matrix.org> 02f

<s​needlewoods_xmr:matrix.org> ////

<s​needlewoods_xmr:matrix.org> // BalanceExclusions

<s​needlewoods_xmr:matrix.org> // - Enotes that match with a balance exclusion will not be included in a balance calculation.

<s​needlewoods_xmr:matrix.org> ///F0c+*ü9ä,

<s​needlewoods:monero.social> sry spilled some stuff over my laptop

Well, you won big at the monkey with a typewriter competition I guess.

<s​needlewoods:monero.social> clipboard content could've been worse

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

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

<s​needlewoods_xmr:matrix.org> hey

<j​effro256:monero.social> Howdy

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

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

<s​needlewoods_xmr:matrix.org> I wrote a wrapper so `wallet_keys_unlocker` can be used by the Wallet API ([commit](monero-project/monero c995b8d)), also based it onto jeffros improved version [#9860](monero-project/monero #9860), was excited when the tests passed, but after testing `make_multisig` manually from the CLI it still do<clipped

<s​needlewoods_xmr:matrix.org> esn't work, so will have to do more debugging.

<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

<v​tnerd:monero.social> Hi

<s​yntheticbird:monero.social> hi

<r​brunner7:monero.social> Uh, that #9860 PR looks pretty wild, with all those issues about something so small ...

<r​brunner7:monero.social> Is that not yet merged because a second review is missing?

<s​needlewoods_xmr:matrix.org> also re-review was requested after two small changes afaict

<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

<j​berman:monero.social> g a start date, writing a post with instructions on how to join, etc.)

<r​brunner7:monero.social> Sounds like the real fun can soon start then. allpha net will be a pretty milestone I think.

<j​effro256:monero.social> Me: I mostly worked on consensus based hash changes, unrelated to Qubic stuff (e.g. monero-project/monero #10038)

<r​brunner7:monero.social> What is an "intermediate PoW hash"?

<j​effro256:monero.social> I also want to propose a new Carrot math audit at the next MRL to address some small things: gist.github.com/jeffro256/12f4fcc001058dd1f3fd7e81d6476deb

<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

<j​effro256:monero.social> SNeedlewoods: looking at that commit now

<o​frnxmr:monero.social> got my fcmp testnet up to ~18mb blocks, mining stopped for now while jberman investigates an issue

<r​brunner7:monero.social> Ah, I see. That's floating around for quite a while already

<r​brunner7:monero.social> monero-project/monero #8827

<j​effro256:monero.social> Yes, exactly

<j​effro256:monero.social> Will link that in the PR, thanks

<r​brunner7:monero.social> So this Carrot follow-up audit will preferrably go again to CypherStack, to profit from pre-knowledge?

<j​effro256:monero.social> Yes, it *should* be relatively quick I think

<j​effro256:monero.social> Haven't solicited quotes yet, just wanted to see if anyone would be opposed to it

<j​berman:monero.social> Proposed follow-up audit lgtm

<r​brunner7:monero.social> Yeah, checking again can't be wrong. If a problem sneaked in, however unlikely that is, we must know.

<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

<j​effro256:monero.social> Agreed

<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": repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/604

<r​brunner7:monero.social> Don't be shy, make your voice heard

<j​berman:monero.social> I'll share a comment on that proposal soon

<j​berman:monero.social> likely today

<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

<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.

<o​frnxmr:monero.social> So the ccs isnt "to harden monero against certain attacks", but to write a book about it

<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.

<r​brunner7:monero.social> I guess we have many quite controversial discussions ahead on the way to that.

<r​brunner7:monero.social> Ok, do we have to discuss something today beyond these reports?

<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.

<s​needlewoods_xmr:matrix.org> last MRL meeting no one told me to bring water, was very dehydrated at the end

<r​brunner7:monero.social> Lol

<r​brunner7:monero.social> I think we can close for today. Thanks everybody for attending, read you again next week!

<s​needlewoods_xmr:matrix.org> thanks everyone, cu

<o​frnxmr:monero.social> [@jeffro256:monero.social](https://matrix.to/#/@jeffro256:monero.social) for wallet devs, if fcmp++ basically plug-and-play?

<o​frnxmr:monero.social> (For wallet_api wallets)

<o​frnxmr:monero.social> xyproblem: if i built a wallet like monfluo and swapped in the fcmp repo, would it "just work"?

<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

<j​effro256:monero.social> That's the goal

<j​effro256:monero.social> Please lmk if that's not the case

<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

<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

<v​tnerd:monero.social> Which is good because all of this lws/lwsf/wallet work wouldve been partially wasted

<v​tnerd:monero.social> I just have to figure out how to get fcmp++ working with lwsf, etc

<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.

<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)

<j​effro256:monero.social> This somewhat assumes that spending privacy is already gone for light wallets from the perspective of the daemon

<j​effro256:monero.social> Optionally, you can also fetch FCMP *decoy* paths to get ring-signature-like privacy against the daemon

<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

<v​tnerd:monero.social> technically the server effectively knows when a spend occurs anyway (now)