13:51:19 Hope this comes out correctly as a reference to a proposal from you, @jberman:monero.social , from May 7, regarding a better fix than your Anonero "hotfix" for the problem with the unrestored Polyseed after coming back from background syncing. > <@jberman> the more optimal fix is: 13:52:04 I had a look at this today. First, as it is to be expected, I can confirm that the hotfix works. 13:56:26 You propose to modify verify_password to give back the whole account keys struct that it has to read anyway internally, to avoid a second read of that just to restore the Polyseed and its optional passphrase. Well, those verify password methods in wallet2 are a bit of a tangle, so I hesitate to modify them and/or add ano [... too long, see https://mrelay.p2pool.observer/e/qtGvq4MLcS0tdE1K ] 13:59:38 You propose to add, if possible, a sanity check after restoring the Polyseed, to check whether it encodes the correct spend private key. Well, it would be possible to verify that, but you would have to go through quite some process with the Polyseed data until arriving at the resulting private key and then compare. I would gue [... too long, see https://mrelay.p2pool.observer/e/76W7q4MLSHRVcjZm ] 14:00:20 All in all, I arrive at the following proposal: I take over your "hotfix" into my PR and call it a day ... 14:00:24 Thoughts? 15:57:04 My concern was that the hotfix may not properly handle re-encrypting the keys for unattended wallets e.g. CLI, not RPC. I didn't dig deep into it. The hotfix didn't fully make sense to me tbh. I load() in the if statement above should already be calling load_keys . I don't see what's accomplished by calling load_keys again / how exactly it fixes the issue 15:57:36 verify_password wouldn't need a new variant fwiw, just replace spend_key with account, which contains the spend key 15:58:41 The benefit of sanity checking the polyseed is to avoid this exact bug where spend key is decrypted correctly but polyseed doesn't get restored properly, but if it's a pain to do it, then ok 15:59:35 Also fwiw, hotfix wasn't mine, that was @r4v3r23:monero.social 's 16:01:57 I will probably look deeper into it upon PR and will have a stronger argument then. Feel free to go the route you think is best for the PR 16:50:02 Thanks for the feedback. Didn't notice the "puzzle" why it works in the first place, and thus will investigate closer. 16:52:28 If I remember correctly there is some code that does not simply take the private key out of the account keys struct to set the parameter but makes some distinctions based on all the various types of wallets there are. Will also check again. 16:53:17 You would not worry that those verify password methods are public, and in theory there could be third-party code that uses them, that we would break? 18:15:43 @rbrunner7: I introduced that new verify_password with the background sync. In hindsight I should have kept it a private function, since we don't use it anywhere else. I would be pretty surprised if anyone's using it, and if they are, I'd wager they'd find similar value in the full account keys being returned over just the spend key and think it would be an acceptable break 18:18:34 Almost convinced :)