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

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

<j​effro256:monero.social> Howdy

<s​needlewoods:monero.social> hey

<r​brunner7:monero.social> Ok, maybe somewhat smaller circle today. What are the reports about last week?

<s​needlewoods:monero.social> I just pushed github.com/monero-project/monero-gu…cached_password_with_verifyPassword & github.com/monero-project/monero/co…his_wallet:x_remove_cached_password

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

<j​berman:monero.social> me: FCMP++ optimization contest launched! (blog post: getmonero.org/2025/04/05/fcmp++-contest.html). Coordinating with xmrack on additional comms (reddit, twitter, and additional outreach)

<j​berman:monero.social> Also finished including the FCMP++ tree root in the PoW hash for each block. After much discussion with jeffro256 , I settled on an approach that I think is very solid (it won't materially affect miners creating new block templates nor normal sync), and also happened to be straightforward to implement: seraphis-migration/monero #22

<j​berman:monero.social> This week I'm planning to implement caching pre-built blinds in the wallet in the background (so that tx construction is near-instant). Blinds construction takes on the order of seconds and does not have to run at tx construction time (i.e. can be pre-cached). The FCMP++ contest (on divisors specifically) will hopefully speed this up by at least 2x, but even a 2x speed-up remains <clipped messag

<j​berman:monero.social> on the order of seconds without caching

<j​berman:monero.social> I will also likely finish my current CCS this week, and open another

<s​needlewoods:monero.social> didn't make as much progress as I hoped for, but fixed a nasty bug that changed your password to zero bytes of the length of your original password when changing restore height, because that uses `setPassword()` to trigger rewrtite of .keys file

<j​effro256:monero.social> me: integrated Carrot/FCMP++ transaction building into `wallet2` and am almost done with testing

<r​brunner7:monero.social> "didn't make as much progress as I hoped for" SNeedlewoods : Lack of time? Or did you finally stumble over something that you can't rectify regarding storing passwords in memory, for hard technical reasons?

<r​brunner7:monero.social> jberman: Did you also consult some "mining people"? Or is the approach clear and simple enough that the two of you can be sure it flies?

<j​berman:monero.social> The latter. Some miners who construct block templates themselves via some routes exposed by the daemon just need to read a new field `fcmp_pp_tree_root`, which the daemon just reads from the db / doesn't spend time doing crypto to feed it to the miners

Tobtoht has been experimenting with feather + fcmp++ testnet. Constructing transactions and such :)

<r​brunner7:monero.social> Sounds like some adventure for tobtoht :)

<s​needlewoods:monero.social> lack of time, many unexpected distractions, also I feel the scope of just "remove cached password" increased and Qt has giving me trouble a couple times, but I'm still optimistic that I'll be able to finish this

<r​brunner7:monero.social> Nice

Preventing cached password in the GUI ? I long ago assumed it was not possible, unless you patch Qt.

That's why I only did monero-wallet-cli. Unless you can override malloc in Qt...

<j​berman:monero.social> Of note, there is a theoretically optimal approach to block template construction: the daemon could immediately serve new block templates (/ data used for new block templates) before verifying a block's contents , so that miners aren't wasting cycles mining a likely stale block template in the usual case

You *could* override operator new and operator new[] though. I suppose you could wipe *everything*....... So disregard my comment...

Assuming Qt always goes new and not malloc/calloc.

<j​berman:monero.social> This is relevant because the approach to tree construction right now adds something like 5-15 milliseconds to block verification (depending on the machine), which is done before miners can get the new template. 5-15ms is a relatively small proportion of block verification at the moment, which is why I would say the above theoretical optimum is one that is sensible to keep on the b<clipped messag

<j​berman:monero.social> ack-burner and not a pre-req for FCMP++

<s​needlewoods:monero.social> moneromoo my approach is to call this function to wipe the QStrings github.com/SNeedlewoods/monero-gui/…1c06/src/qt/utils.cpp#L218C1-L224C2

<r​brunner7:monero.social> "FCMP++ optimization contest launched!" jberman , do you plan to follow up that blog post with a Monero subreddit post? Maybe we won't reach many potential contestants with such a Reddit post, but the community might be interested anyway.

<j​berman:monero.social> yes coordinating with xmrack on it. From @xmrack also: "I’ve sent out emails to four groups of researchers who publish monero related works in the past. I also sent out emails to codeforce and zprize to see if we could advertise to their userbase" + "I also submitted an inquiry to Kaggle which is a long shot but curious what they say back"

That wipes *a* QString, but you have no idea where an edit widget put your data.

In wallet2, I had to contend with std::cout (same thing, it might buffer) and made sure I avoided that potential buffering. But Qt might buffer a lot more.

<j​berman:monero.social> the UI elems shouldn't be manging the password in memory at all though right? should just be those black dots

Though, as I thought a few minutes ago, overringing delete/delete[] might work. Unless those widgets have long lived working data.

<j​berman:monero.social> Or are you saying as it ingests the input

You don't know though. That's the point.

You might if you read the Qt source but it might change.

I do know that std cin/cout do buffer stuff that stdio doesn't, for example.

<r​brunner7:monero.social> I guess without looking through the source code of Qt I guess what is left is looking in process memory for widget related copies of the password still left, and if none can be found that's a good probability it's not a problem.

Well, the particular impl of cin/cout I used when testing.

Right. I made a program to find my password in mapped memory when I did this.

<s​needlewoods:monero.social> wouldn't it work to dump the memory after you typed in many different password fields and then search for the bytes to confirm you can't find them anymore?

And cin/cout did leave droppings. I assume Qt can leave even more, since there's a lot more code dealing with I/O that we did not write.

<r​ucknium:monero.social> jberman: tobtoht 's testing of FCMP showed a 1in/2out tx took 3 minutes to construct. Is it the un-cached "blinds" that are causing the very slow construction? If so, could you explain more about blinds, their role, when they need to be computed/cached, and their performance characteristics?

Yes, it would mostly work.

<j​berman:monero.social> ouch. I believe at the moment, wallet2 is *also* doing multiple rounds of tx construction (including blinds calculations) that jeffro256's code for carrot construction I believe should eliminate once integrated

<r​brunner7:monero.social> SNeedlewoods: Do I remember correctly, you actually did some such memory searches?

<j​berman:monero.social> But yes, I'm guessing it's almost certainly tree branch blinding causing that slowness tobtoht is seeing

paste.debian.net/hidden/7d665900 is the code to grep for the password if this helps.

<s​needlewoods:monero.social> I did only confirm that the memory the QString pointed to before the wipe was empty afterwards, I didn't check the entire memory though

<j​effro256:monero.social> I'm not jberman, but yeah the blinds are going to take the majority of the CPU time when constructing FCMP++ txs. There's two types of blind: output blinds, and curve tree blinds. Output blinds can be calculated as soon as you scan on output. Curve tree blinds can be calculated whenever: they don't have any computational dependencies. You need 1 output blind per spend output, and <clipped mess

<j​effro256:monero.social> T-1 curve tree blinds per spent output, where T is the number of layers in the FCMP tree. At the moment for mainnet, this is 6-7 IIRC.

<r​brunner7:monero.social> Thanks for that code, moneromooo, interesting!

wallet2 used to (when I did it) create txes to check size, as it adds inputs, just to see when it stops being valid. It is fairly brute force.

<s​needlewoods:monero.social> thank you moneromoo, is it okay if I DM you on IRC if I have more questions?

<j​effro256:monero.social> Only tx *provers* need to construct blinds, and they need to do so when making membership proofs.

Note that a long password might only be partly present after a free, if some data is being reset (size, deltas...) but the main memory is left alone.

<r​brunner7:monero.social> Although worst case using that code may end up with some frustration for SNeedlewoods :)

<t​obtoht:monero.social> Thanks jberman and jeffro256 for clarifying.

Sure, dm me is fine.

I've not hacked on monero in a long while though.

<j​berman:monero.social> An output's path in the tree has to be blinded to construct the FCMP++ proof (which is part of avoiding revealing the output's path). This is part of the math that divisors is doing that is particularly slow, that the contest is targeted at speeding up

<r​brunner7:monero.social> With that very early goalpost set at 3 minutes tx construction time, will be interesting to see where we will finally land for the fork code!

<j​effro256:monero.social> The cache that jberman is talking about could startup a thread once a wallet is generated and create blinds in the background, so that when the user wants to construct a transaction, the blinds are already mainly ready

<s​needlewoods:monero.social> as long as I'm the only one frustrated by my work it's okay for me, but I don't want to start frustrating you guys

<r​ucknium:monero.social> Thanks for your responses. So we expect to have usable FCMP tx construction before the contest is done, correct? And even faster tx construction after it is done? I am thinking of stressnet and the need to spam txs.

<r​brunner7:monero.social> Imagine construction time of 3 minutes for a PC on a somewhat old-ish smartphone :)

<j​berman:monero.social> Final FCMP++ release also shouldn't be doing those blinds calculations >1 times per tx, so that will be fixed / looked into also

<j​effro256:monero.social> Technically speaking, an output blind is composed 4 subparts, and we will basically always need to recompute of 1 of the 4 subparts of the output blind during transaction construction time, even with a good cache

FWIW, IIRC the blind constructs bypass things like BP calc (using known size placeholders), exactly because it was starting to become slow enough to be annoying.

<j​berman:monero.social> "So we expect to have usable FCMP tx construction before the contest is done, correct? And even faster tx construction after it is done?" -> yes and yes. Something like <3s tx construction should be feasible even before the contest

<r​ucknium:monero.social> Should I put alpha testnet/stressnet/testnet planning on the next MRL agenda, or is it too early still?

<r​ucknium:monero.social> Great. That was my understanding from the old Curve Tress discussion. About 2 seconds to prove.

<j​berman:monero.social> "FWIW, IIRC the blind constructs bypass things like BP calc (using known size placeholders), exactly because it was starting to become slow enough to be annoying." -> can look into this approach for these new blinds calculations too

<j​berman:monero.social> thank you moo :)

<j​effro256:monero.social> The need for the subpart recomputation is because balancing a transaction's input and output amount commitments requires us to recompute what's called the "c_blind" or "amount commitment rerandomization blind". And the balancing process depends on knowing the amount blinding on the outputs, which we don't know until transaction construction time

<r​ucknium:monero.social> By the way, you no longer have to worry about leaving Exodus Wallet behind, since they plan to end Monero support in August, anyway. According to Reddit.

<r​brunner7:monero.social> Seems we enter a quite hot phase already with FCMP++ code, so much going on.

<r​brunner7:monero.social> I wonder what the MyMonero people plan. Did anybody hear something already?

Also, wrt your wipeQString function, I made a memwipe function, because at least one compiler (GCC) is known to be able to detect stores before a free, and removes those stores because it doesn't modify program behavior. So I would use memwipe instead of this.

<r​ucknium:monero.social> Or you could decide to plan alpha testnet (at least) here in these meetings.

memwipe isn't technically guaranteed to always work though, it just confuses the compiler enough to stop being a smartarse.

<r​brunner7:monero.social> Lol

<j​effro256:monero.social> I'm going to miss you dunking on how terrible their wallet software is

<r​brunner7:monero.social> Soon we will see the first ChatGPT based compiler that you won't be able to fool anymore :)

<r​ucknium:monero.social> Lol. I am of two minds on this Exodus dropping support

<r​brunner7:monero.social> Yeah

<r​ucknium:monero.social> Bad that Monero is available to fewer users with just the Exodus wallet, but good that their custom tx construction will come to an end.

<r​ucknium:monero.social> Probably they are dropping it because of the resources needed. They have always had overloaded nodes AFAIK.

<r​brunner7:monero.social> Ok, after that wealth of reports, do we have anything general left to discuss today?

<j​effro256:monero.social> Probably non-trivial dev time to keep their custom wallet software working with the current mainnet, plus whatever features they support, plus Exodus-specific bug fixes

<j​effro256:monero.social> Maybe they would be open to keep supporting Monero if there was a good general-purpose, community-maintained Monero light wallet library ? IIRC I think everoddandeven is working on something like that

<r​brunner7:monero.social> Does not look like it. Thanks everybody for attending this interesting meeting, read you again next week!

<s​needlewoods:monero.social> thanks everyone

<r​brunner7:monero.social> jeffro256: That's why I wonder about MyMonero. If I remember correctly, a number of wallets run on their infrastructure, and/or their tech. If they throw in the towel, they might take a number of such wallets with them. Not that we could do much against that ...

well i can support that stuff easily with my infra

but it’s a liability

and do we really want some central party scanning all these view keys?

one compromise and it’s game over for that set

at least future tech will alleviate that concern

as for the client side, don’t worry, as I have mentioned I have almost a direct factorization of wallet2 with LWS support

this means that any additional future updates as long as they are able to be compiled in an embeddable manner will be able to be run on the client side

<r​ucknium:monero.social> By the way, Exodus Desktop uses a remote node model, not a lightwallet model. I was able to set a custom remote node URL in the UI. I'm not sure about Exodus Mobile.

so just consider that in your writing of next generation code that it should be written with as few stipulations about platform as possible with as few hardcoded rats-nest deps (do not always assume access to ALL other monero code from whatever code module) so that it can still be compiled to wasm

i’ll write up my ccs proposal. i have had some really unfortunate events happen lately

and also had to add one more thing to my proposal due to a research discovery

i dont have any financial support anymore , and given my expertise in this i think it benefits the community to let me work on this still, which will be evident in the progress and discoveries i made on monero’s code

and its protocol… tbh

it really pains me to have these repos private still

i can hardly communicate that

but i have to do a number of things before i can even hit publish due to lacking $ in the first place and having to do it myself

luckily i got taxes done haha

but it does hurt to never have anyone mention my work

i wonder what that is about

i have very advanced lws infra already published. any company can contact me. it’s far more advanced than other implementations

i also designed most of the enterprise offering mymonero currently operates

and i built the client side lib from almost scratch with monero’s code and my factor/rewrite of some utils from mymonero v1

so idk why people dont ask me lol but hopefully by the time i can hit publish it wont after i have to update my core c++ for the next gen wallets

see the problem? :p

anyway…. i’ll continue my lonely work