16:58:54 <m-relay> <r​brunner7:monero.social> Meeting in 1 hour
18:00:01 <m-relay> <r​brunner7:monero.social> Meeting time. Hello! https://github.com/monero-project/meta/issues/1190
18:00:25 <m-relay> <r​brunner7:monero.social> Thankfully the Monero matrix server is fast again ...
18:00:39 <m-relay> <s​needlewoods:monero.social> hey
18:02:13 <m-relay> <r​brunner7:monero.social> But maybe some people still searching for their hidden Easter eggs :)
18:03:33 <m-relay> <r​brunner7:monero.social> Anyway, something to report from you, SNeedlewoods ?
18:03:49 <m-relay> <j​berman:monero.social> *waves*
18:04:21 <m-relay> <j​berman:monero.social> me: completed the FCMP++ blinds cache (implemented serialization to save pre-calculated blinds to the wallet cache), implemented composition changes prior discussed (hash y coords in the leaf layer in addition to x coords), implemented comments on latest PR's for bannig torsion at consensus and modifying the PoW hash for FCMP++, and did some debugging in the torsion checking crypt<clipped messag
18:04:22 <m-relay> <j​berman:monero.social> o code. Continuing this week reviewing jeffro's PR on FCMP++ / Carrot transaction weight and taking a look at FCMP++ fees (will likely discuss with @articmine once I'm further along in my looking into)
18:04:46 <m-relay> <r​brunner7:monero.social> I saw tobtoht reporting new tx creating times middle last week, with release build instead of debug build, which look very promising: 1-in: 1.2s, 2-in: 1.5s, 4-in: 2.4s, 8-in: 4.4s
18:05:32 <m-relay> <j​berman:monero.social> Yep and with the blinds cache + elimination of multiple rounds of blinds calculations during tx construction, it should be instant
18:05:57 <m-relay> <r​brunner7:monero.social> Because the fetching of decoys falls away?
18:07:31 <m-relay> <s​needlewoods:monero.social> been trying to remove all the secret material from memory that appears after you open the seed page
18:07:32 <m-relay> <s​needlewoods:monero.social> I figured out displaying the QR code creates a bunch of copies of secrets, but even if I disable the QR thing there are still one copy for each svk, ssk and seed that I can't get rid off.
18:08:26 <m-relay> <j​berman:monero.social> I believe fetching decoys can take some time especially pointing to a cold node (it's also 2 round trips to the node), so eliminating that definitely helps yes. I was mostly referring to the client-side execution time to construct the tx
18:10:07 <m-relay> <r​brunner7:monero.social> SNeedlewoods: What would probably be my strategy as a hacker to find those secrets in memory? I think all kinds of strings are in memory, how would I target the secrets in particular?
18:10:26 <m-relay> <r​brunner7:monero.social> Needle, meet haystack?
18:11:00 <m-relay> <j​berman:monero.social> I think it's oook to make an attempt to tighten secret material in ram in this case, but not really worth any sort of significant time. If the user requests the seed be displayed in the app (a relatively rare action), it's reasonable to assume the seed is going to be sprayed all over
18:11:37 <m-relay> <s​needlewoods:monero.social> for the QR code they were conveniently prefixed by "spend_key=" lol
18:11:38 <m-relay> <s​needlewoods:monero.social> otherwise it just looks like random bytes for the keys
18:14:31 <m-relay> <s​needlewoods:monero.social> "looks like random bytes" I have to correct, that's not the case since they are stored as a `QString` which has 16 byte characters, so each single byte of the key is followed by a `0x00` so there is a pattern
18:15:11 <m-relay> <r​brunner7:monero.social> I was just thinking back to some earlier thought of mine: If you can't eliminate each and every copy, fill memory with similar stuff, to obfuscate basically. If you do that basically at exactly the same time, not even comparing memory snapshots before and after should give many clues
18:16:20 <m-relay> <r​brunner7:monero.social> But I agree with jberman : Maybe at this point you should call it a day, PR what you have which is an improvement, and march on to greener fields
18:17:41 <m-relay> <r​brunner7:monero.social> So, anything to discuss today beyond these reports?
18:18:49 <m-relay> <r​brunner7:monero.social> The most prevalent attack scenario isn't probably genius hacker scanning process memory, but spammer sending people to the "verifysourseed.com" website ...
18:20:07 <m-relay> <s​needlewoods:monero.social> If an attacker can dump your memory, you probably have other things to be concerned about like e.g. keylogger, clipboard logger etc.
18:20:27 <m-relay> <r​brunner7:monero.social> Right :)
18:20:53 <m-relay> <r​brunner7:monero.social> Alright, seems like we can close the meeting. Thanks for attending, read you again next week!
18:21:10 <m-relay> <s​needlewoods:monero.social> thanks, cu