thanks for the PR. I am curious though what is the motivation for adding 24 word support?

My concern is that it introduces more complexity for every neptune wallet interface. In particular, I recently added basic mnemonic support (18 words) to neptune-proton. So it would also need to be updated. Any future wallets that wish to interop cleanly with neptune-core wallets would need to support both formats also, both for imports and exports.

There is UI complexity and user confusion to consider also.

I think that if introducing such a burden, the motivation should/must be very compelling. But that case is not yet made.

Probably relevant: #362.

I anticipate that a) compatibility with hardware wallets, and b) compatibility with other blockchains (for users (including exchanges) who need to interface with multiple cryptocurrencies) are important motivations. @hduoc2003: would you mind expanding on these motivations and adding any that I am missing?

As I see it, this PR is addressing two separate, but related, concerns.

1. Support for 24-word mnemonic seed phrases (import + export).
2. Optionally use 256 bits to represent the secret key material.

It is quite obviously moot to do (2) without doing (1): where would the remaining 64 bits of entropy come from or go to? However, it is not unthinkable to do (1) without doing (2). Why did you decide against this strategy?

I confess I am opposed to using more than 192 bits for the secret key material because 192 is already more than enough. Every derivation path that involves the secret key material passes it through a hash function first. Any attack on the secret key material involves attacking one-wayness or second pre-image resistance of that hash function. The complexity of this task is linear in the size of the output space, or 192 bits. In particular, we need not worry about the square root complexity associated with finding collisions. However, I am willing to hear a counter-argument.

Regardless of whether we decide to do just (1) or (1) and (2), I should like to use this opportunity to address the concerns raised in #362. Would you mind commenting on the correctness and completeness of that summary, and on the feasibility of expanding the scope of this PR to include the tasks described therein?

Furthermore, in case it should be mentioned: a very important constraint for this and similar PRs is that existing seed phrases and secret-sharings continue to work. Could you add unit tests showing that this is indeed the case?