12:01:58 <br-m> <sneedlewoods_xmr:matrix.org> FWIW it seems src/cryptonote_basic/account.cpp allows generating an account with spendkey only, having set viewkey = crypto::null_skey.
12:01:58 <br-m> <sneedlewoods_xmr:matrix.org> In theory the Wallet API also allows restoring a wallet by just a ssk (+ the address to verify you restored the correct wallet) (src (https://github.com/monero-project/monero/blob/9e817b608b51b138273824afcde2a442b0764359/src/wallet/api/wallet.cpp#L673-L677).
12:01:58 <br-m> <sneedlewoods_xmr:matrix.org> Though this (https://github.com/monero-project/monero/blob/9e817b608b51b138273824afcde2a442b0764359/src/wallet/wallet_rpc_server.cpp#L3892-L3898) check prevents the wallet-rpc and this (https://github.com/monero-project/monero/blob/9e817b608b51b138273824afcde2a442b0764359/src/simplewallet/simplewallet.cpp#L4103-L4115) & this ( [... too long, see https://mrelay.p2pool.observer/e/hNTUqYwLeUZ3d1dm ]
12:01:58 <br-m> <sneedlewoods_xmr:matrix.org> Is there a particular reason to not allow restoring by ssk only, or could we modify those checks?
12:01:59 <br-m> <sneedlewoods_xmr:matrix.org> (If you only have a ssk, you can still use external tools to derive a seed (or view-key + address) and restore from that.)
13:15:00 <br-m> <sneedlewoods_xmr:matrix.org> For context, I'm currently trying to improve the functional tests for the wallet-rpc based on Wallet API, here is a WIP commit https://github.com/monero-project/monero/commit/8b55dd76017aef05da446cf2b5f4a8508750a0fd
13:31:17 <br-m> <spirobel:kernal.eu> @sneedlewoods_xmr:matrix.org: if you want to enable this functionality, just derive the viewkey from the spendkey input and set it internally, so the check still passes 
13:37:08 <br-m> <sneedlewoods_xmr:matrix.org> Yeah that would also work. I don't have a strong opinion to add this feature, just expected it would already work that way and was wondering if there is a specific reason why it's disabled.
13:39:49 <br-m> <spirobel:kernal.eu> later code  depends on the viewkey being present and this check was added without considering the possibility that this limitation is introduced 
13:41:20 <br-m> <spirobel:kernal.eu> viewkey is deterministically derived from the spend key, so when you have the spendkey, you also have the viewkey, it is an unnecessary limitation 
13:48:16 <br-m> <spirobel:kernal.eu> most likely it is like this because view wallet functionality was implemented first. 
13:51:41 <br-m> <spirobel:kernal.eu> no rational reason, just checking if args present for this, then spend wallet was caked over it later. Thats my guess :)
17:06:08 <br-m> <rbrunner7> @sneedlewoods_xmr:matrix.org: Not sure, but the whole thing could be at least in part connected with wallets that are not "deterministic", i.e. early wallets that had 2 random secret keys, and not a secret view key merely derived from the secret spend key. That's also behind those two_random parameters in the "account" classes. If you want to restore such a wallet, you have to specify two keys.
17:06:36 <br-m> <rbrunner7> But on the other hand in the CLI wallet app you need to use the special --non-deterministic startup parameter to activate this ...
17:10:11 <br-m> <rbrunner7> I just saw that the CLI wallet does have a startup parameter --generate-from-spend-key. Are you sure that the two code parts you linked are always reached? That restore method that handles all the restore variants is quite a tangle, and awfully long, so it's easy to overlook something.
17:10:39 <br-m> <rbrunner7> By the way, now for supporting Polyseed, I made it just a bit more complicated still, isn't it a joy :)
17:12:49 <br-m> <jpk68:matrix.org> @rbrunner7:monero.social Just curious, do you plan to update the Polyseed documentation (in the monero-docs repo) after this is merged? I'm asking because I was going to add some info on seed encryption, but it was mentioned that you might be doing it instead :)
17:14:36 <br-m> <rbrunner7> Er ... wasn't even fully aware that there is such a repo. Anyway, for me, if I wanted to continue with this after finishing the core code, a good idea would be making Polyseed available in the GUI Wallet app.
17:15:21 <br-m> <jpk68:matrix.org> No problem, I will try and send in a patch then :)
17:16:54 <br-m> <ofrnxmr> @rbrunner7: https://github.com/monero-project/monero-docs/blob/master/docs%2Fen%2Fmnemonics%2Fpolyseed.md
17:16:54 <br-m> <ofrnxmr> https://docs.getmonero.org/mnemonics/polyseed/
17:17:53 <br-m> <rbrunner7> Thanks.
17:18:26 <br-m> <ofrnxmr> Its mostly a copy of tevadors document.
17:18:56 <br-m> <ofrnxmr> So, it should probably be updated upstream first
17:19:05 <br-m> <ofrnxmr> (i dont know what needs updating?)
17:19:05 <br-m> <rbrunner7> Not sure where you would put things like the new legacy_command command I added to the CLI wallet. Maybe not in some Polyseed page, but into the CLI wallet documentation?
17:19:14 <br-m> <jpk68:matrix.org> The need for an update is mostly related to Polyseed support in core
17:19:20 <br-m> <ofrnxmr> @rbrunner7: Yeah
17:19:23 <br-m> <rbrunner7> *legacy_seed of course
17:19:36 <br-m> <ofrnxmr> @jpk68:matrix.org: The polyseed doc has nothing to do with support in wallets
17:19:45 <br-m> <rbrunner7> Polyseed itself did not change at all, after all
17:20:04 <br-m> <jpk68:matrix.org> @ofrnxmr: I know, but it would be useful to mention that it is supported in core if/when it's merged
17:20:12 <br-m> <rbrunner7> That, yes
17:20:26 <br-m> <ofrnxmr> @jpk68:matrix.org: in the document? No
17:20:43 <br-m> <ofrnxmr> Just add the flag to the wallet cli and rpc pages ...
17:20:46 <br-m> <ofrnxmr> Its not a blog
17:20:47 <br-m> <rbrunner7> It's default however, if you don't counter with a special command line argument, the CLI wallet app will generate a Polyseed wallet for you
17:22:08 <br-m> <jpk68:matrix.org> @ofrnxmr: Sure, but the purpose of that page is evidently to give some background info on seed types; it's not a user manual, that's for the other page you mentioned
17:22:26 <br-m> <jpk68:matrix.org> Reading about the different seed types seems a bit moot if you don't know where they're used
17:22:59 <br-m> <jpk68:matrix.org> For example, the MyMonero seed page gives info like this (which is relevant)
17:23:05 <br-m> <ofrnxmr> https://docs.getmonero.org/mnemonics/
17:23:26 <br-m> <ofrnxmr> Mymonero seed is called "mymonero" seed, because its only used by mymonero
17:24:38 <br-m> <jpk68:matrix.org> A quarter of the text on that page is explaining historical relevance. If you want to make it consistent, then why not remove that paragraph?
17:24:55 <br-m> <ofrnxmr> The only change to the doc that icna see, would be an "update: as of monero v0.19 polyseed is the default seed type for monero-project wallets"
17:25:32 <br-m> <jpk68:matrix.org> Sure, I agree. As well as encryption, of course
17:25:43 <br-m> <jpk68:matrix.org> The legacy seed page could also use some info about offsets
17:26:38 <br-m> <jpk68:matrix.org> Plus maybe in general, the origin of the wordlists (i.e. BIP-39 for Polyseed, etc.)
17:27:32 <br-m> <rbrunner7> I don't think you will run out of work anytime soon if you want to bring such a large body of documentation up to date ...
17:43:01 <br-m> <sneedlewoods_xmr:matrix.org> --non-deterministic only works for generating new wallets in combination with --generate-new-wallet AFAICT > <@rbrunner7> But on the other hand in the CLI wallet app you need to use the special --non-deterministic startup parameter to activate this ...
17:44:38 <br-m> <sneedlewoods_xmr:matrix.org> > <@rbrunner7> I just saw that the CLI wallet does have a startup parameter --generate-from-spend-key. Are you sure that the two code parts you linked are always reached? That restore method that handles all the restore variants is quite a tangle, and awfully long, so it's easy to overlook something.
17:44:38 <br-m> <sneedlewoods_xmr:matrix.org> Oh yeah, I was missing --generate-from-spend-key, that works as expected and doesn't even need an address to verify. It's just messy IMO that we have a different flag and code path for this.
17:44:38 <br-m> <sneedlewoods_xmr:matrix.org> And wallet-rpc still doesn't allow it I think.