12:10:57 .merge+ 10331 12:10:57 Added 13:05:12 can anyone offer the use cases for a --restricted wallet-rpc? and/or give feedback for which things should be available for it in https://github.com/monero-project/monero/pull/10378 - there is no custom 'allow_this_in_restricted_mode' for each method so its all or nothing 13:08:52 IMO i think read operations should be allowed, as well as store (a write operation). I would say that the only thing that should be read, is private keys. tx keys, proofs etc should be readable. I don't think its productive to lose all sync progress anytime the wallet is shut down 13:09:41 Currently the use case would, i think, be because you want to monitor outgoing txs. So a pseudo view-balance wallet 13:13:20 for the curent pr.. i would unrestrict store and get_tx_key. the latter aligns with 10271 reasoning (and get_*_proofs arent restricted either) 13:22:23 Ideally we would use a multisig wallet for that purpose, instead of having a hot wallet protected by --restricted, but, experimental and all that 13:25:05 Don't you have to sync key images with peers to see the outgoing txs on a musig? 13:28:55 OVK would help here ofc. I think im forgetting that with RINO you spent from their UI so they didnt need to sync? 🤔 13:48:59 .merge- 1378 1379 13:49:10 removed them until the discussion is resolved 13:49:44 typo? 13:51:24 .merge- 10378 10379 13:51:24 Removed 15:05:43 .merge+ 10397 10398 15:05:43 Added 17:40:58 I'm open to unrestrict `store` and `get_tx_key` if there is strong support 17:40:58 for `get_tx_key` I'd still like to hear jeffro256 s take, or from anyone who is qualified to asses potential security drawbacks 17:41:00 for `store` there is ctrl+c to close the wallet which also stores it, meaning it's not impossible to store a restricted wallet, but you need to have direct access