Deterministic wallet compatibility matrix

[btchris]

This is a first attempt at creating a compatibility matrix for deterministic wallets. In other words, it tries to answer the questions:

When using two different wallet apps from different devs, will I have the same list of addresses and the same balance if I:

• use the same mnemonic sentence (seed) in both?
• export a master private key from one into the other?
• export a master public key from one into the other (creating a watch-only wallet)?

For now, it's an Excel file available for viewing or downloading here: https://onedrive.live.com/redir?resid=584F122BA17116EE%21313.

It has four tabs. The first, "Details", lists out (hopefully) all relevant details of various wallets that might make them compatible or not with one another.

The next three are calculated from the first; they try to answer the three corresponding questions above. (Sorry, but Excel Online doesn't render vertical text correctly, so they look a bit ugly online. Either download a local file, or hover over the wallet names in the first row to read them; they're in the same order as the wallet names in the first column.)

I'm definitely interested if anyone has any input; in particular I'm not at all confident that the Details tab has everything correct, and it's probably missing some deterministic wallets that I'm unaware of. If there are any wallet devs who could take a quick look at their wallet on the first tab to see if I got anything wrong, that'd be great!

I'm also not sure that the list of requirements (spelled out on the three right-most tabs) is sufficient to guarantee compatibility.

(Also: don't rely on this without doing your own testing first!)

I'm not sure where, if anywhere, this is headed, but it'd be nice to turn this into a set of web-based tables on GitHub, perhaps something jekyll-based like this. Again, input is most welcome.

[Andreas Schildbach]

Just some clarification: the derivation path used by bitcoinj (and thus Bitcoin Wallet for Android) is specified in BIP-32. So it would be appropriate to use the term "BIP-32" in that column.

[btchris]

Just some clarification: the derivation path used by bitcoinj (and thus Bitcoin Wallet for Android) is specified in BIP-32. So it would be appropriate to use the term "BIP-32" in that column.

That would be better, thanks. Fixed.

[jim618]

Looks correct for MultiBit HD compatibility / paths etc.

Note that we made a mistake with our BIP32 compatibility in the Beta 7 release (details here: https://github.com/bitcoin-solutions/multibit-hd/issues/445). It is fixed in the code now and will roll out in Beta 8.

[btchris]

Looks correct for MultiBit HD compatibility / paths etc.

Note that we made a mistake with our BIP32 compatibility in the Beta 7 release (details here: https://github.com/bitcoin-solutions/multibit-hd/issues/445). It is fixed in the code now and will roll out in Beta 8.

Thank you for checking, I appreciate it.

There's already a comment attached to MultiBit HD's BIP-39 cell which mentions Beta 8 being a requirement. (I'm the same Chris who opened that issue on GitHub )

[AussieHash]

Needs an additional column :

BIP-44 passphrase support yes/no

For example myTrezor support BIP-44 with passphrase, as does electrum's trezor plugin

However Ledger's Chrome wallet and electrum's btchip plugin are BIP-44 without passphrase support

[btchris]

Needs an additional column :

BIP-44 passphrase support yes/no

For example myTrezor support BIP-44 with passphrase, as does electrum's trezor plugin

However Ledger's Chrome wallet and electrum's btchip plugin are BIP-44 without passphrase support

Do you mean BIP-39 passphrase support? That's a good idea (It'd probably be a requirement for "full" compatibility, but not for "partial" compatibility).

Would it also make sense to add one line for each software/hardware combination, e.g. Electrum/TREZOR, MultiBit HD/TREZOR, myTrezor/TREZOR, etc., since they might offer different levels of support? Or are all TREZORs pretty much the same? (and all btchips, etc.)

Unfortunately I don't own any hardware wallets, so that makes it more difficult for me.

[Andreas Schildbach]

For BIP44, multiple account support is mandatory. So strictly speaking, MultiBit HD doesn't support BIP44 (if the "Multiple Accounts" column is right).

[btchris]

For BIP44, multiple account support is mandatory. So strictly speaking, MultiBit HD doesn't support BIP44 (if the "Multiple Accounts" column is right).

At least for Beta 7 the "Multiple Accounts" column is correct. I updated the sheet, and while I'm sure you're technically correct, I think it's slightly more confusing now, but I've no strong preference either way.

[Michail1]

Nice job.
I was having issues with Mycelium on ios vs android a long time ago.  I figured it out with using pycoin and shared the information; however, you did a great job in showing in multiple wallets.

Kudos.

[erasmospunk]

Some info about the Coinomi wallet.

Code:

BIP-39?                             YES
Display/restore mnemonic?           YES
BIP-39 passphrase?                  YES
BIP-32?                             YES
HD path                             BIP-44
Master pubkey export?               NO (Planned)
Master pubkey restore?              NO (Planned)
Master privkey export/restore?      NO (Sweep priv key only)
xpub/xprv path                      m/44'/0'/a'
Multiple accounts?                  NO (in Alpha)
Account naming convention           for "Account 1" a=0
Lookahead size                      20
Lookahead frequency                 continuous

[btchris]

Some info about the Coinomi wallet.

Thanks for spelling out all the details! I've updated the spreadsheet.

If you remember to let me know once new features are released, I'll update the spreadsheet to include them.

-Chris

[fbueller]

btcchris: I'm happy to see this, something that kills me about multisig is that it leads to vendor lock-in at the moment. Being able to orchestrate a 2-of-2 between two different multisig web wallets is the direction I see it going.

Btw, maybe note if the wallet sorts public keys in multi-signature addresses as there's a BIP for that now to encourage wallets to be compatible with eachother.

[unamis76]

Thank you for making this list. I looked for something similar for quite some time, only to fail in finding it.

In the mnemonic-compatible tab it says there is no compatibility between breadwallet and MultiBit HD, which is not correct: I've successfully imported a seed from breadwallet in MultiBit HD. I needed to import it because I was looking to sign a message from one of the addresses in my seed (breadwallet doesn't have that functionality), and I managed to sign the message through MultiBit HD.

On another note, sad to see that Electrum is pretty much incompatible with everything else... I thought these new BIP standards (especially BIP 39) would help to unify seed usage throughout wallets... But that doesn't seem to be the case. Maybe a new, more universal standard should kick in?

[btchris]

btcchris: I'm happy to see this, something that kills me about multisig is that it leads to vendor lock-in at the moment. Being able to orchestrate a 2-of-2 between two different multisig web wallets is the direction I see it going.

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.)

Btw, maybe note if the wallet sorts public keys in multi-signature addresses as there's a BIP for that now to encourage wallets to be compatible with eachother.

Agreed, BIP-67 is a good thing.

[btchris]

Thank you for making this list. I looked for something similar for quite some time, only to fail in finding it.

Welcome.

In the mnemonic-compatible tab it says there is no compatibility between breadwallet and MultiBit HD, which is not correct

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:

On another note, sad to see that Electrum is pretty much incompatible with everything else...

Perhaps you already know this, but it was an intentional trade-off made by the Electrum dev: https://bitcointalk.org/index.php?topic=1082586.0, https://bitcointalk.org/index.php?topic=939337.msg10366268#msg10366268

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.

[unamis76]

Thank you for making this list. I looked for something similar for quite some time, only to fail in finding it.

Welcome.

In the mnemonic-compatible tab it says there is no compatibility between breadwallet and MultiBit HD, which is not correct

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:

On another note, sad to see that Electrum is pretty much incompatible with everything else...

Perhaps you already know this, but it was an intentional trade-off made by the Electrum dev: https://bitcointalk.org/index.php?topic=1082586.0, https://bitcointalk.org/index.php?topic=939337.msg10366268#msg10366268

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.

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

[fbueller]

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!

[TheButterZone]

I would use GreenAddress if I could do so using Electrum as it works well for offline transactions.

Ditto.

[it-zone]

Please add bitcore wallets, including copay, details:

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