Topic: Deterministic wallet compatibility matrix (Read 13855 times)

I think you can find similar lists that are better update on websites like Bitcoin Optech Compatibility Matrix and Wallet Recovery.
It is important to know exact derivation path, address type and what BIP standard is used to find if wallets are compatible, and anyone can contribute and update information on their github page.

Well, I am sort of in need of exactly such list and while it is a bit outdated - does anyone know if there is anything similar but with most updated information?

I agree it should be a GitHub project.

Very nice and innovative idea!

Where is Jaxx.io?

No you have misunderstood. If you look at that github issue I've linked above then you can see that breadwallet supports bip32 (HD wallets) and 39 (standard for seed mnemonic/wallet words/passphrase to seed conversion) but not bip44 (key derivation standard). Wallets that use bip39 and 44 cannot be restored in breadwallet simply because the derivation path (bip44) is different from what bread wallet uses. That is what he meant by this comment on reddit.

The phrase itself (bip39) is not the problem. There is nothing in the phrase that tells you which wallet it came from so if you support one bip39 wallet you support them all.

See https://www.reddit.com/r/Bitcoin/comments/4n0wdt/received_my_ledger_nano_today_im_extremely/d402mre/ you're welcome

Where does he say that? bip39 is not the same as bip44.

I think the file is correct. Breadwallet follows the bip32 default wallet layout with path m/0'/0/x, where x = each new address generated. According to the developer Breadwallet doesn't allow you to recover all possible bip39 compatible phrases, but all Breadwallet recovery phrases are bip39 compatible.

breadwallet uses bip39:

https://github.com/voisine/breadwallet/issues/131#issuecomment-69028749

please correct the file. it is a very useful resource

Following.
Necro, I know, but this thread deserves to be seen and I want to be able to find it again.

thx for the reply.  I'm presently writing a command-line utility that performs wallet-discovery.  The idea is to read in a master xpub and then generate all of the receive and change addresses for the wallet, checking for received tx, until the gap limit is reached.  (It also handles multiple masters as in the case of copay wallets.)

In fact, I'm using your bitwasp library, so thx for that also!

As I have read bip32, bip44, and bip45 more, I have come to realize that the fault is not entirely with wallet authors using non-standard paths.  bip32 was fine by itself, but then bip44 and 45 re-defined the path in new ways causing much confusion and no way to resolve it.  So any code that is the recipient of an xpub (which contains depth but not path or bip number) is screwed because there is no in-band mechanism to know the bip-format.   Asking users is a non-starter, except for maybe asking them which wallet software and version they are using.

Even worse, if the receiving app gets it wrong, it has no real way of knowing because new (and incorrect) keys are happily generated.  They just won't have any received funds.   No way to differentiate that from an empty wallet.

Seems really broken and bad for interop and user experience.

copay is especially crazy.  Here's a snippet for how I have to deal with them.  ( Copay 1.x )



I suppose  such games might not be necessary if my app were to receive the bip39 words, but that exposes the master private key and ruins the entire idea of 3rd party audits without private keys.  And I'm not sure if that tells us the structure or not...

I am thinking we could solve this with a new bip that defines a standard format for wallet software to export master keys(s) so that necessary information is not lost, including:
  + list of xpubs  ( and/or optionally xprivs )
  + absolute path including purpose ( bip number / format identifier )
  + number of signers (in case of multisig wallets)

Basically a standard wallet interchange format.    :-)

I'm new to this hd wallet stuff.  Has anyone drafted a relevant bip already that I'm just not aware of?

You're right; that information is lost. You can only know the parents fingerprint, and the current index. This assumes someone has the parent key, and can compare fingerprints.

You seem to share some of my issues around HD implementations. There should be a way to import your electrum xpub into GreenAddress, or absolutely *any* HD wallet cosigning applications.

It's partially a lack of a mechanism for requesting signatures and public key information (something I've drawn up before) but largely because wallet providers prefer to lock users to their platform.

Edit:

Hmm, what are you trying to achieve btw? I had this problem in an app that accepted xpubs, I just wanted to inform the users who pasted it in (as opposed to the JS option) exactly what the path was, since they likely only kept their root key and only wanted the full path..

I'd err against doing that now, and just inform them of the issue. If your app generates keys using BIP45, etc, great, you know what the path is, and probably only need to show the address index. But for the users who'd like full control of their keys, you probably shouldn't even be exposed to the full path, as you only do child derivations.

By only ever showing the public key index, you force them to maintain that information themselves, which is all BIP32 allows.

answering my own question, it seems the answer is yes.  The library I am using provides a getDepth() method which seems to work for my purposes.

Still, I do not see any way to access the nodes of the path, so it's unclear if the path is formatted according to bip32, 44, or something else.  

Example, from a mycelium android xpub alone I can determine that the path is like:
m/?/?/xpub

But what I want to be certain of is:
m/44/0/xpub     ( bip 44 )

- or -

m/0/0/xpub   ( bip 32, in the wrong place )

If I'm not mistaken, the only way to obtain that info is out of band.  Eg, by asking the user "What wallet software did you export this key from?"    And then I need to maintain a matrix of wallet software versions and their idiosyncracies so I can know which bip/purpose they use for exporting keys.    fun!

Hopefully someone can inform me I'm wrong about that?   Or is there some heuristic that can be used to determine whether bip32 or bip44 is used?

Thanks for this list.  really useful to me right now.

I'm presently trying to implement a tool that can read in an XPub and then find all the addresses that have ever been used, both receive and change.  for auditing/accounting purposes.

I quickly found that a) not all HD wallets export the xpub (eg multibit) and b) wallets are exporting the XPub from non-standard paths eg mycelium.

I don't understand why it is so hard for wallet authors to simpy follow the Bip32 spec as written.  This is people's money we are talking about.  Did we learn nothing from the browser wars?   Are they doing this specifically to waste my time investigating?  sure feels like it....

ok, so to my question:    Given only an xpub and no additional info about where it came from, is it possible to determine what location it should be at in the path?     Basically my code needs to be 100% certain that it is generating the correct addresses, and also that it can find both receive and change addresses.

And for those wallets that do not allow exporting the xpub at all.... really?   seriously?   Exactly whose money do you think it is?  What alternative mechanism do you provide that enables 3rd party auditing/accounting?   oh really, none?   yeah, that's what I thought.

Please add bitcore wallets, including copay, details:

https://github.com/bitpay/bitcore-wallet-client/blob/master/lib/common/constants.js

Ditto.

To clarify, I am not talking about GreenAddress sharing their private keys.

What I meant is, a customer of a wallet shouldn't rely on GreenAddresses app to derive their personal HD key. They can do this themselves, and probably already have several if they use Bitcoin Wallet, Mycelium, Electrum.

Why not enable users to submit an xpub from their existing wallet, allowing them to use GreenAddress but add their signature using software they trust. Anything less than this creates custodial risk. Signing is implementation agnostic, GreenAddress will sign using their stack as always.

One reason for multisig is distributing risk. I would use GreenAddress if I could do so using Electrum as it works well for offline transactions. I'd know my private keys are in effective cold storage (not on an Android device.....) and there's no risk that GreenAddress would ever deliver an update or javascript that undermines the security of my private keys.

If you can export your xprv, you should be able to upload it somewhere. It at least assumes you're taking charge of it yourself, and might like to change providers at some point, or make use of multiple services using the same root key!

Excuse me for my mistake, it looks like it was indeed an error in the browser I was using, it works fine offline and on Chrome.

As for Electrum, I knew it was intentional... but never read the post you linked, thanks for that Keep it up with the spreasheet

Welcome.


Is it not being calculated correctly for you (it's a formula cell)? Are you looking in the wrong place maybe? Here's what it looks like for me:




Perhaps you already know this, but it was an intentional trade-off made by the Electrum dev: https://bitcointalksearch.org/topic/bip-39-vs-electrum-mnemonic-seed-1082586, https://bitcointalksearch.org/topic/m.10366268

On the positive side, Electrum 2.x does have some xpub (watching-only) compatibility with other wallets, and it's the only wallet to have xprv compatibility with any other.

I would guess that multisig web wallets are looking for ways to monetize their user base (integration or tie-ins with exchanges? non-free instant confirmations? advertising? time will tell...). It seems unlikely they'll remain "free" (as in no monetization) forever. If that guess is correct, a multisig web wallet would have no self-interest in permitting users to download the provider's private keys—that would allow users to move their wallets to a competitor. It also probably isn't a good idea from a security point of view, either.

For another take, consider GreenAddress 2-of-2 wallets. Their security model for instant confirmations outright prohibits them from sharing their private key, lest a user be able to double-spend a UTXO which GreenAddress has placed its instant-confirmed faith behind.

They already all (I certain hope?!) provide a recovery mechanism, so sharing keys between wallets isn't necessary for recovery purposes either.

In short: I don't think web-based multisig providers will ever share their keys (nor should the need to), and so I doubt they have much place on this spreadsheet. Could be wrong, though....

There are however non-web-based multisig wallets, like Armory, Electrum 2.x, mSIGNA, and Copay. These certainly do have a place here, but I don't think any are yet compatible with one another (I'm not sure about Copay though, I haven't checked them out yet). Since adding them would complicate the spreadsheet and not add much new value, I'm hesitant to expend the effort at the moment.... however I think it should be done one day. (BTW I'd be happy to be wrong about their current compatibility if someone could correct me.)


Agreed, BIP-67 is a good thing.