iancoleman / bip39

A web tool for converting BIP39 mnemonic codes
https://iancoleman.io/bip39/
MIT License
3.45k stars 1.43k forks source link

Add a dropdown menu to generate the account extended public/private key #375

Open andronoob opened 4 years ago

andronoob commented 4 years ago

I once felt confused when I saw both Account Extended Private Key and BIP32 Extended Private Key were showed to me, on the BIP44/49/84 tab.

Now I have learned that the BIP32 Extended Private Key is actually a child key of Account Extended Private Key.

I think this tab could be more intuitive, by adding a dropdown menu, which contains four options:

  1. Account Extended Public/Private Key (for Wallet Import/Recovery)

  2. BIP32 Extended Public/Private Key of Receiving Addresses only

  3. BIP32 Extended Public/Private Key of Change Addresses only

  4. Custom BIP32 Extended Public/Private Key

When the 1st option was selected, the External / Internal field would be hidden. The following Derived Addresses view should also show both receiving addresses and change addresses, with clear distinction. Maybe a reminder about actual basis of these derived addresses should also be showed to the user.

When the 2nd/3rd option was selected, the External / Internal field would be visible, but uneditable. The following Derived Addresses view should explicitly show the address type (receiving or change). The user should also be warned not to import these extended keys into any wallet (because the wallets would tend to derive addresses from a child key of provided extended key).

When the 4th option was selected, the following Derived Addresses view should show some warning to remind the user of deviation from the standard.

iancoleman commented 4 years ago

Maybe a reminder about actual basis of these derived addresses should also be showed to the user.

The BIP44/49/84 tabs have the text

"The account extended keys can be used for importing to most BIP44 compatible wallets, such as mycelium or electrum."

and

"The BIP32 derivation path and extended keys are the basis for the derived addresses."

Is this not enough explanation?

I see your point that there are potentially many child extended keys that are useful to the user.

Dropdown option number 1 is currently shown as "Account Extended * Key"

Dropdown option number 2 is current shown as "BIP32 Extended * Key"

Dropdown option number 3 is current shown as "BIP32 Extended * Key" when the 'external / internal' field is changed to value 1.

Dropdown option number 4 is currently achieved using bip32 tab.

So I don't see much improvement in UX by having the dropdown. Option 3 changes field values when the dropdown changes which is sorta dangerous I feel, action-at-a-distance type stuff.

I'm open to further comments though.

andronoob commented 4 years ago

"The account extended keys can be used for importing to most BIP44 compatible wallets, such as mycelium or electrum." and "The BIP32 derivation path and extended keys are the basis for the derived addresses." Is this not enough explanation?

At least this was not enough explanation for me in the past. I think dumb users like me might get a headache while facing a flood of unrecognised awkward proper nouns :-)

Also, I think it would be more intuitive or educational that:

The following Derived Addresses view should also show both receiving addresses and change addresses, with clear distinction.

andronoob commented 3 years ago

I see your point that there are potentially many child extended keys that are useful to the user.

So I don't see much improvement in UX by having the dropdown.

Actually I'm not sure whether you've got my point. Just like what you said:

Dropdown option number N is current shown as "XXXXXX"

That's exactly what I thought - the functionalities are already present, these functions already work well.

I just think it's not intuitive/educational enough, especially for a smatterer like me.

Also, the dropdown option number 2/3 should have some notice/warning, stating that they are generally not intended to be imported into a wallet, otherwise the user would see an empty wallet, or even worse, store funds on non-standard derivation paths, which are not visible to common wallets (edit: these warnings apply to option 4 as well).

Option 3 changes field values when the dropdown changes which is sorta dangerous I feel, action-at-a-distance type stuff.

Sorry, but I haven't realized how this could be dangerous yet. I think it just works like the autofill feature of browsers - user chooses an option, then the textfields get filled. I think it can on the contrary prevent human errors.

If you think the value change is not quite visible to the user, I think the dropdown menu entry text could be modified, like:

  1. BIP32 Extended Public/Private Key of External Keychain (Derives Receiving Addresses)

  2. BIP32 Extended Public/Private Key of Internal Keychain (Derives Change Addresses)

andronoob commented 3 years ago

Oh, it's tricky that Bitcoin Core didn't use the internal keychain in the past - maybe some other wallets did the same? I don't know. Therefore, showing "receiving/change" would be misleading in this case.

andronoob commented 3 years ago

Also, in the title I actually meant "reorganize" rather than "add".

Anyway, again, this tool already works perfectly for these purposes, I just think it might become even more user friendly.