07:59:55 <mj-xmr[m]> selsta: https://github.com/monero-project/monero/pull/7928#issuecomment-947422161
08:00:05 <mj-xmr[m]> Conclusions:
08:00:05 <mj-xmr[m]> - the forked repo reused the master's cache
08:00:05 <mj-xmr[m]> - even though the buil directory was different (monero-mj), ccache didn't need to rebuild itself
08:00:55 <dEBRUYNE> Anyone an idea? https://www.reddit.com/r/monerosupport/comments/q8vgu3/monerod_high_cpu_usage_after_sync_when_using_ssd/
12:49:35 <mj-xmr[m]> selsta: nice catch
12:50:11 <selsta> it would be weird to share cache IMO, it's unlikely
12:52:41 <hyc> have never seen such a monerod behavior. getting a perf snapshot would tell what it's doing
12:58:56 <selsta> hyc: there is no perf on mac, but I will ask them to do something similar
12:59:17 <mj-xmr[m]> selsta: I replied in the thread. Mystery solved. The `depends` cache's ID is the same across various forks and master, because it is built from a hash of input files, which happen to be the same. But it's not the same "cache file" from GH perspective, so it's not shared.
13:02:07 <hyc> selsta: oh I overlooked this was on OSX. from what I've seen, monerod definitely behaves badly on OSX
13:02:25 <hyc> haven't dug into it but it's pretty unreliable on my M1 Mac
13:02:30 <selsta> it works perfectly on my mac, which is weird
13:02:55 <selsta> anyway I bought one of these new M1 Pro Macs, will see if I can reproduce some of your issues
13:03:11 <hyc> cool, def interested in hearing your results
13:03:34 <hyc> prob will sell this M1 mac if the M1 pro works better
13:04:46 <selsta> do you have incoming connections on your home network?
13:04:52 <hyc> yes
13:05:00 <hyc> ipv4, i2p, and tor
13:06:03 <selsta> that might be why I can't reproduce the issues, I only have outgoing connections on my mac
13:06:26 <Guest0000> hello
13:07:29 <Guest0000> after changing data dir "-data-dir"   monerod cant read new directory and goes allways to standard one "/home/user/.bitmonero"
13:07:44 <Guest0000> i have 75gb blockchain!
13:08:01 <hyc> should be "--data-dir"
13:08:12 <Guest0000> sorry --data-dir
13:08:45 <Guest0000> what to do
13:08:55 <hyc> monerod won't fallback to another path if the one you specify doesn't work.
13:08:56 <Guest0000> is madness to download again
13:09:20 <hyc> so whatever you're running sounds like something else
13:09:44 <Guest0000> ./monerod --data-dir  /old/blcockhain
13:09:54 <hyc> anyway, not relevant to monero-dev channel. try asking in #monero
13:10:12 <Guest0000> on monero need reg
13:10:17 <selsta> are you using the GUI?
13:10:22 <Guest0000> no cmd
13:10:55 <Guest0000> monerod fallback because start from the begining 
13:11:09 <Guest0000> start to download block 0,1,2,
13:11:25 <Guest0000> and by default goes to .bitmonero
13:11:26 <selsta> Guest0000: try #monero no, no more reg necessary
13:11:28 <selsta> now*
13:43:13 <BigmenPixel[m]> selsta: Hello. Patch for normal version display works, but even with `-DGUI_VERSION_TAG=release` displays `0.17.2.3-unknown (Qt 5.15.3)`
13:43:37 <selsta> I didn't test that
13:43:42 <selsta> will check if it works for me
13:44:08 <BigmenPixel[m]> selsta: ok
17:33:34 <selsta> mj-xmr[m]: c++14 build issue solved (with help) https://github.com/monero-project/monero/pull/8016
19:32:32 <UkoeHB> moneromooo: re: wiping secrets in multisig kex strings; it seems RPC request/response structs all use `std::string`. Do I need to change all these to `epee::wipeable_string`?
19:33:23 <moneromooo> No, RPC goes over the wire, so no point wipeing.
19:33:50 <moneromooo> But what can be encrypted should be.
19:37:12 <UkoeHB> In that case, none of the kex messages should be wipeable (they are all exposed to rpc)
20:12:25 <UkoeHB> In multisig key exchange there are Diffie-Hellman secrets (public keys, that are secret). Since the code doesn't have a wipeable pubkey, I am thinking to add this to `crypto.h`:
20:12:25 <UkoeHB> ```
20:12:25 <UkoeHB> using public_key_memsafe = epee::mlocked<tools::scrubbed<public_key>>;
20:12:25 <UkoeHB> ```
20:12:25 <UkoeHB> Any thoughts/objections?
20:20:00 <UkoeHB> If I change `m_multisig_derivations` from `wallet2` to `crypto::public_key_memsafe`, would there be problems with serialization (or,  would it be pointless to use memsafe for that variable, since it can be serialized to file)?
20:21:37 <moneromooo> I don't think serializatoin would change, but it's easy to test, right ?
20:21:52 <moneromooo> Change a few pubkeys in wallet2.h to that, load an existing wallet cache.
20:23:00 <UkoeHB> Ah, backward compatibility isn't necessary, since `m_multisig_derivations` is a temporary variable only used during multisig wallet setup. The current PR will invalidate old stuff anyway.
20:23:12 <UkoeHB> old unfinished multisig setups*
20:23:38 <moneromooo> As to pointless or not, is it stored plaintext ?
20:25:02 <UkoeHB> Idk... are the things in `wallet2::get_keys_file_data()` stored plaintext?
20:25:11 <moneromooo> No.
20:25:45 <UkoeHB> Ok :)
20:28:26 <UkoeHB> The problem is `::serialization::parse_binary` and `::serialization::dump_binary` parse to `std::string`... lol
20:29:19 <UkoeHB> Eh it's not that important.
20:29:49 <UkoeHB> `m_multisig_derivations` are useless secrets without user private keys.
20:29:58 <moneromooo> Ah. OK then.
20:40:25 <UkoeHB> Anyone know why I can do unordered map of `secret_key`, but not `public_key_memsafe`?
20:40:28 <UkoeHB> https://www.irccloud.com/pastebin/dpsNQFd8/
20:46:29 <UkoeHB> well my static analyzer says it's invalid (still compiling...); it doesn't complain about `std::unordered_set<crypto::public_key_memsafe>`
20:51:01 <moneromooo> unordered needs hashable (as opposed to operator <).
20:51:25 <moneromooo> There's a macro somewhere to add a hash for a type.
20:51:41 <moneromooo> CRYPTO_MAKE_HASHABLE(public_key)
20:51:57 <moneromooo> You need the same, or just a thin wrapper.
20:56:33 <UkoeHB> heyy that worked!
21:22:59 <UkoeHB> moneromooo: what do you mean by making `on_finalize_multisig()` a nop in RPC? Just clear the request/response structs and always return false from `on_finalize_multisig()` (or maybe leave the struct alone and just return false)?
21:23:49 <moneromooo> I'd say always return true, but that'd work only if it doesn't return data in the previous version.
21:24:11 <moneromooo> The intent being that an existing RPC user that creates multisig addresses would still work.
21:24:22 <moneromooo> If it's not that simple, forget about it.
21:30:42 <UkoeHB> Hmm I think backward compatibility can be maintained. However, would it be better to just clean up the dead code? Maybe that would require more work (i.e. go through and delete all the dead code at once).
21:33:33 <moneromooo> Depends on the details I guess.
21:34:27 <UkoeHB> Would bumping the major version require all RPC users to update their code, or just those calling finalize_multisig?
21:35:01 <moneromooo> Well... depends :)
21:35:13 <moneromooo> If htey check major version, they'll stop working.
21:35:24 <moneromooo> If they don't, they'll break if they use finalize_multisig.
21:35:45 <moneromooo> "stop working" meaning "complain about the version change".
21:35:57 <UkoeHB> ah gotcha
21:36:29 <moneromooo> So the mechanism to tell users of an incompatible change ends up being more annoying in practice here. Unfortunte.
21:40:04 <UkoeHB> Do you know how many dead/deprecated RPC methods there are currently?
21:42:23 <moneromooo> No, but not many I think.
21:42:33 <moneromooo> transfer is the only one I can think of.
21:51:21 <UkoeHB> I will just bump the major. It should be rolled out at same time as a hardfork, so the disruption can be bundled with that larger disruption.
22:44:14 <selsta> can clients with a higher major connect to daemons with a lower major?