selsta: monero-project/monero #7928#issuecomment-947422161

Conclusions:

- the forked repo reused the master's cache

- even though the buil directory was different (monero-mj), ccache didn't need to rebuild itself

Anyone an idea? reddit.com/r/monerosupport/comments…cpu_usage_after_sync_when_using_ssd

selsta: nice catch

it would be weird to share cache IMO, it's unlikely

have never seen such a monerod behavior. getting a perf snapshot would tell what it's doing

hyc: there is no perf on mac, but I will ask them to do something similar

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.

selsta: oh I overlooked this was on OSX. from what I've seen, monerod definitely behaves badly on OSX

haven't dug into it but it's pretty unreliable on my M1 Mac

it works perfectly on my mac, which is weird

anyway I bought one of these new M1 Pro Macs, will see if I can reproduce some of your issues

cool, def interested in hearing your results

prob will sell this M1 mac if the M1 pro works better

do you have incoming connections on your home network?

yes

ipv4, i2p, and tor

that might be why I can't reproduce the issues, I only have outgoing connections on my mac

hello

after changing data dir "-data-dir" monerod cant read new directory and goes allways to standard one "/home/user/.bitmonero"

i have 75gb blockchain!

should be "--data-dir"

sorry --data-dir

what to do

monerod won't fallback to another path if the one you specify doesn't work.

is madness to download again

so whatever you're running sounds like something else

./monerod --data-dir /old/blcockhain

anyway, not relevant to monero-dev channel. try asking in #monero

on monero need reg

are you using the GUI?

no cmd

monerod fallback because start from the begining

start to download block 0,1,2,

and by default goes to .bitmonero

Guest0000: try #monero no, no more reg necessary

now*

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

I didn't test that

will check if it works for me

selsta: ok

mj-xmr[m]: c++14 build issue solved (with help) monero-project/monero #8016

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`?

No, RPC goes over the wire, so no point wipeing.

But what can be encrypted should be.

In that case, none of the kex messages should be wipeable (they are all exposed to rpc)

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`:

```

using public_key_memsafe = epee::mlocked<tools::scrubbed<public_key>>;

```

Any thoughts/objections?

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

I don't think serializatoin would change, but it's easy to test, right ?

Change a few pubkeys in wallet2.h to that, load an existing wallet cache.

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.

old unfinished multisig setups*

As to pointless or not, is it stored plaintext ?

Idk... are the things in `wallet2::get_keys_file_data()` stored plaintext?

No.

Ok :)

The problem is `::serialization::parse_binary` and `::serialization::dump_binary` parse to `std::string`... lol

Eh it's not that important.

`m_multisig_derivations` are useless secrets without user private keys.

Ah. OK then.

Anyone know why I can do unordered map of `secret_key`, but not `public_key_memsafe`?

well my static analyzer says it's invalid (still compiling...); it doesn't complain about `std::unordered_set<crypto::public_key_memsafe>`

unordered needs hashable (as opposed to operator <).

There's a macro somewhere to add a hash for a type.

CRYPTO_MAKE_HASHABLE(public_key)

You need the same, or just a thin wrapper.

heyy that worked!

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

I'd say always return true, but that'd work only if it doesn't return data in the previous version.

The intent being that an existing RPC user that creates multisig addresses would still work.

If it's not that simple, forget about it.

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

Depends on the details I guess.

Would bumping the major version require all RPC users to update their code, or just those calling finalize_multisig?

Well... depends :)

If htey check major version, they'll stop working.

If they don't, they'll break if they use finalize_multisig.

"stop working" meaning "complain about the version change".

ah gotcha

So the mechanism to tell users of an incompatible change ends up being more annoying in practice here. Unfortunte.

Do you know how many dead/deprecated RPC methods there are currently?

No, but not many I think.

transfer is the only one I can think of.

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.

can clients with a higher major connect to daemons with a lower major?