We should further discuss the UX implications of allowing the user to generate additional payment addresses from a spending key, and what this could mean for the existing flows as we have them.
Should we (and how could we) support having a shielded account that doesn't have a transparent counterpart?
Could we instead have multiple shielded keys associated with a single (parent) transparent account seed? (Use-case is generating additional shielded keys - This functionality would simply increase the derivation path index for the account)
How would this affect shielding and unshielding flows?
Basically, what are the consequences of having only shielded or transparent keys as a single account? We group these currently by:
1) Generating a Transparent account (contains the mnemonic seed)
2) Deriving Shielded Keys from this Transparent Account, reference it by a parent ID (this is how they are linked together to display View Keys in the extension)
Currently, the Extension accounts flow looks like this:
User Generates/Imports a Mnemonic -> Transparent + Shielded Keys (default paths)
User Imports a Mnemonic with Custom Path -> As of 1155, Transparent + Shielded Keys (unless they specify change, which is not a component of Zip32, so shielded accounts get ignored here)
User Imports a Private Key -> Transparent (However, it's now possible to also generate shielded keys from this private key, so we can probably ignore this as it will be added soon - so assume this is the same as in first scenario)
User generates additional payment address from shielded account (Not currently implemented) - How will this be represented on Namadillo? Should users also have ability to select from other accounts in the extension that are not associated with the shielded/transparent key that is selected in Extension?
We should further discuss the UX implications of allowing the user to generate additional payment addresses from a spending key, and what this could mean for the existing flows as we have them.
Basically, what are the consequences of having only shielded or transparent keys as a single account? We group these currently by:
1) Generating a Transparent account (contains the mnemonic seed) 2) Deriving Shielded Keys from this Transparent Account, reference it by a parent ID (this is how they are linked together to display
View Keysin the extension)Currently, the Extension accounts flow looks like this:
change, which is not a component of Zip32, so shielded accounts get ignored here)