Bitcoin Forum

Bitcoin => Wallet software => Topic started by: btchris on March 23, 2015, 05:25:02 PM



Title: Deterministic wallet compatibility matrix
Post by: btchris on March 23, 2015, 05:25:02 PM
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 (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 (https://github.com/gurnec/btc-wallet-comparison). Again, input is most welcome.


Title: Re: Deterministic wallet compatibility matrix
Post by: Andreas Schildbach on March 25, 2015, 07:32:48 PM
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.


Title: Re: Deterministic wallet compatibility matrix
Post by: btchris on March 25, 2015, 08:57:44 PM
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.


Title: Re: Deterministic wallet compatibility matrix
Post by: jim618 on March 26, 2015, 12:19:27 PM
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.


Title: Re: Deterministic wallet compatibility matrix
Post by: btchris on March 26, 2015, 02:01:01 PM
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 :))


Title: Re: Deterministic wallet compatibility matrix
Post by: AussieHash on March 30, 2015, 06:49:56 PM
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



Title: Re: Deterministic wallet compatibility matrix
Post by: btchris on March 30, 2015, 07:54:28 PM
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.


Title: Re: Deterministic wallet compatibility matrix
Post by: Andreas Schildbach on April 03, 2015, 04:04:36 PM
For BIP44, multiple account support is mandatory. So strictly speaking, MultiBit HD doesn't support BIP44 (if the "Multiple Accounts" column is right).


Title: Re: Deterministic wallet compatibility matrix
Post by: btchris on April 03, 2015, 05:38:28 PM
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 (https://www.youtube.com/watch?v=hou0lU8WMgo), I think it's slightly more confusing now, but I've no strong preference either way.




Title: Re: Deterministic wallet compatibility matrix
Post by: Michail1 on June 01, 2015, 06:15:28 PM
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.


Title: Re: Deterministic wallet compatibility matrix
Post by: erasmospunk on June 07, 2015, 12:43:26 PM
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


Title: Re: Deterministic wallet compatibility matrix
Post by: btchris on June 07, 2015, 01:39:12 PM
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


Title: Re: Deterministic wallet compatibility matrix
Post by: fbueller on June 07, 2015, 02:36:41 PM
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.


Title: Re: Deterministic wallet compatibility matrix
Post by: unamis76 on June 07, 2015, 04:55:57 PM
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? :)


Title: Re: Deterministic wallet compatibility matrix
Post by: btchris on June 07, 2015, 05:23:06 PM
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.


Title: Re: Deterministic wallet compatibility matrix
Post by: btchris on June 07, 2015, 05:45:08 PM
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:

https://i.imgur.com/zVwJwqn.png

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=1082586.0), https://bitcointalk.org/index.php?topic=939337.msg10366268#msg10366268 (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.


Title: Re: Deterministic wallet compatibility matrix
Post by: unamis76 on June 07, 2015, 08:37:08 PM
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:

https://i.imgur.com/zVwJwqn.png

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=1082586.0), https://bitcointalk.org/index.php?topic=939337.msg10366268#msg10366268 (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


Title: Re: Deterministic wallet compatibility matrix
Post by: fbueller on June 15, 2015, 02:12:03 PM
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!



Title: Re: Deterministic wallet compatibility matrix
Post by: TheButterZone on June 15, 2015, 08:18:22 PM
I would use GreenAddress if I could do so using Electrum as it works well for offline transactions.

Ditto.


Title: Re: Deterministic wallet compatibility matrix
Post by: it-zone on December 21, 2015, 03:40:01 AM
Please add bitcore wallets, including copay, details:

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


Title: Re: Deterministic wallet compatibility matrix
Post by: btc4ever on December 28, 2015, 09:02:30 AM
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.

<rant>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....</rant>

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.

<rant2>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.</rant2>


Title: Re: Deterministic wallet compatibility matrix
Post by: btc4ever on December 28, 2015, 09:51:55 AM
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?

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.



Title: Re: Deterministic wallet compatibility matrix
Post by: fbueller on December 29, 2015, 09:27:11 PM
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.


Title: Re: Deterministic wallet compatibility matrix
Post by: btc4ever on December 30, 2015, 02:52:53 AM
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 )

Code:
       // copay uses a crazy constant instead of a bip45 cosigner_index.
        // why?  cuz they can.
        $copay_constant = '2147483647';
        $relpath_base = $copay_constant;
        $abspath_base = 'm/45/' . $copay_constant;
        
        $relpath = $relpath_base . "/$type/$idx";
        $abspath = $abspath_base . "/$type/$idx";


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?


Title: Re: Deterministic wallet compatibility matrix
Post by: Millionero on September 07, 2016, 06:34:33 PM
Following.
Necro, I know, but this thread deserves to be seen and I want to be able to find it again.


Title: Re: Deterministic wallet compatibility matrix
Post by: Abdussamad on January 22, 2017, 08:43:27 PM
breadwallet uses bip39:

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

please correct the file. it is a very useful resource :)


Title: Re: Deterministic wallet compatibility matrix
Post by: BitcoinNewsMagazine on January 22, 2017, 10:37:38 PM
breadwallet uses bip39:

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

please correct the file. it is a very useful resource :)

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.


Title: Re: Deterministic wallet compatibility matrix
Post by: Abdussamad on January 24, 2017, 10:09:29 AM
According to the developer Breadwallet doesn't allow you to recover all possible bip39 compatible phrases

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


Title: Re: Deterministic wallet compatibility matrix
Post by: BitcoinNewsMagazine on January 24, 2017, 03:58:59 PM
According to the developer Breadwallet doesn't allow you to recover all possible bip39 compatible phrases

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

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


Title: Re: Deterministic wallet compatibility matrix
Post by: Abdussamad on January 24, 2017, 04:50:45 PM
According to the developer Breadwallet doesn't allow you to recover all possible bip39 compatible phrases

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

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

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.


Title: Re: Deterministic wallet compatibility matrix
Post by: MilkTea on February 07, 2018, 12:48:28 AM
Where is Jaxx.io?


Title: Re: Deterministic wallet compatibility matrix
Post by: Spendulus on February 09, 2018, 07:20:04 PM
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 (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 (https://github.com/gurnec/btc-wallet-comparison). Again, input is most welcome.

I agree it should be a GitHub project.

Very nice and innovative idea!