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

<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 (github.com/monero-project/monero/bl…src/wallet/api/wallet.cpp#L673-L677).

<sneedlewoods_xmr:matrix.org> Though this (github.com/monero-project/monero/bl…t/wallet_rpc_server.cpp#L3892-L3898) check prevents the wallet-rpc and this (github.com/monero-project/monero/bl…wallet/simplewallet.cpp#L4103-L4115) & this ( [... too long, see mrelay.p2pool.observer/e/hNTUqYwLeUZ3d1dm ]

<sneedlewoods_xmr:matrix.org> Is there a particular reason to not allow restoring by ssk only, or could we modify those checks?

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

<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 monero-project/monero 8b55dd7

<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

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

<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

<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

<spirobel:kernal.eu> most likely it is like this because view wallet functionality was implemented first.

<spirobel:kernal.eu> no rational reason, just checking if args present for this, then spend wallet was caked over it later. Thats my guess :)

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

<rbrunner7> But on the other hand in the CLI wallet app you need to use the special --non-deterministic startup parameter to activate this ...

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

<rbrunner7> By the way, now for supporting Polyseed, I made it just a bit more complicated still, isn't it a joy :)

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

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

<jpk68:matrix.org> No problem, I will try and send in a patch then :)

<ofrnxmr> @rbrunner7: github.com/monero-project/monero-do…docs%2Fen%2Fmnemonics%2Fpolyseed.md

<ofrnxmr> docs.getmonero.org/mnemonics/polyseed

<rbrunner7> Thanks.

<ofrnxmr> Its mostly a copy of tevadors document.

<ofrnxmr> So, it should probably be updated upstream first

<ofrnxmr> (i dont know what needs updating?)

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

<jpk68:matrix.org> The need for an update is mostly related to Polyseed support in core

<ofrnxmr> @rbrunner7: Yeah

<rbrunner7> *legacy_seed of course

<ofrnxmr> @jpk68:matrix.org: The polyseed doc has nothing to do with support in wallets

<rbrunner7> Polyseed itself did not change at all, after all

<jpk68:matrix.org> @ofrnxmr: I know, but it would be useful to mention that it is supported in core if/when it's merged

<rbrunner7> That, yes

<ofrnxmr> @jpk68:matrix.org: in the document? No

<ofrnxmr> Just add the flag to the wallet cli and rpc pages ...

<ofrnxmr> Its not a blog

<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

<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

<jpk68:matrix.org> Reading about the different seed types seems a bit moot if you don't know where they're used

<jpk68:matrix.org> For example, the MyMonero seed page gives info like this (which is relevant)

<ofrnxmr> docs.getmonero.org/mnemonics

<ofrnxmr> Mymonero seed is called "mymonero" seed, because its only used by mymonero

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

<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"

<jpk68:matrix.org> Sure, I agree. As well as encryption, of course

<jpk68:matrix.org> The legacy seed page could also use some info about offsets

<jpk68:matrix.org> Plus maybe in general, the origin of the wordlists (i.e. BIP-39 for Polyseed, etc.)

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

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

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

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

<sneedlewoods_xmr:matrix.org> And wallet-rpc still doesn't allow it I think.