Suggestion: add "Mnemonic" column, and rename "BIP39 Pass" into "Passphrase"

[andronoob]

First of all, (as a reply of #129 (comment) as well) I think this website/project is intended to show how to recover funds from a wallet listed in the table, isn't it?

Some wallets like Bitcoin Core and Bitcoin Wallet app (maintained by Andreas Schildbach) don't have any mnemonic at all.

Some wallets like Electrum and LND have mnemonic schemes which are incompatible with BIP39.

For these cases, I'm afraid to say the info provided on this site is not quite clear in this aspect - "is this wallet itself recoverable, and how? Oh, not so clear..."

Therefore, my bold suggestion is adding a new "Mnemonic" column to represent such info.

Just like Electrum, Bitcoin Core and LND, these three wallets could be represented like (some text should be hyperlinks but I haven't set them):

Software Wallet	Mnemonic	Path and/or Script	Passphrase (NOT wallet encyption)
Electrum↗︎	Electrum2.0↗︎; BIP39↗︎ (import only↗︎)	Electrum2.0: m m/0' | 1' (decided by version bits embedded inside mnemonic); Imported BIP39: Single Signer: m/ | 44' | 49' | 84'/0'/0' Multisig: m/45'/0/0/0 m/48'/0'/0'/1' m/48'/0'/0'/2'	Optional, supported via salting aka. "25th word of 24-word mnemonic"
Bitcoin Core↗︎	N/A	Pre-0.15.0: (incl. old wallet.dat loaded by newer software)m/0'/0'/k' (receiving and/or change); 0.15.0 and later: (incl. manually upgraded wallet.dat)m/0'/0'/k (receiving), m/0'/1'/k' (change)	N/A
LND↗︎	aezeed↗︎	(decided by version bits embedded inside mnemonic, seems to be BIP44/49/84 compliant but unsure)	Optional, supported via encryption rather than salting

[nvk]

ACK, please keep PSBT YES/NO too. As this is the new standard.

[andronoob]

please keep PSBT YES/NO too

I was just too lazy to add other columns for this demo.

[nvk]

Cool, wanna make a PR? I will try to not merge anything till you done.

[andronoob]

Personally I'm a fan of BIP39/44/49/84 scheme.

I think the current description of derivation path only, like m/ | 44' | 49' | 84'/0'/0' could be simply represented with Compliant to standard(s): BIP44↗︎BIP49↗︎BIP84↗︎. I think it's a good simplification, which also covers script/address types (current description doesn't cover script/address types yet).

Just like the case of Trezor, where more than one "account" is supported, so that such derivation path description is aslo inaccurate.

However, I'm aware that some prominent contributors in this field have been strongly disagree with BIP39 for years, so that they might think they were discriminated, or ignored (because they at least think BIP39 itself is already "(completely) broken" so that it should die ASAP, then the whole situation will be improved just by getting rid of BIP39 - which is the point I strongly disagree with) - in fact "being discriminated" was exactly my personal, narrow-minded feeling as well, when using Electrum, I faced the "warnings" against BIP39, and the (semmingly purposeful) awkward derivation path input field (thankfully it had already been improved) - all of them gave me unpleasant feelings.

[nvk]

I think many share your sentiment. But the purpose here is help the most amount of people to recover from wallets, old and new.

There will always be wallets deviating from common "standards" and we will need to have to document them here.

We should layout the information with that in mind, that's why I had them explicit.

[andronoob]

I think many share your sentiment.

I'm sorry for dumping emotional craps here.

But the purpose here is help the most amount of people to recover from wallets, old and new.

There will always be wallets deviating from common "standards" and we will need to have to document them here.

That's why I hesitated to post #132 (comment).

---

There's another idea I hesitated to post: I thought it's probably necessary to add another "Script (Address) Type" column, however it would probably make the table width exceed the screen edge.

[nvk]

Maybe we could rename Derivation Path column to Derivation Path & Script Type and add there. That's the fatest entry that would save on width.