18

Is there a specific reason to why BIP39 isn't added to Bitcoin Core? Seems very trivial to add and am confused to why it isn't there.

kcalvinalvin
  • 524
  • 3
  • 9
  • 1
    Good question. I thought there might be a github issue suggesting this, which might contain some explanation, but I couldn't find one. – Nate Eldredge Jun 07 '19 at 20:49
  • 3
    @NateEldredge It is discussed in https://github.com/bitcoin/bitcoin/pull/6265 – Raghav Sood Jun 08 '19 at 00:42
  • @RaghavSood: Thanks. As far as I can tell, the summary seems to be "people might be tempted to make up their own mnemonic phrases, instead of randomly generating them, and that would be bad because they'd be susceptible to brute force". – Nate Eldredge Jun 08 '19 at 02:07
  • BIPs 32/39/44 is already native to other Bitcoin frameworks, e.g., https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-mnemonic-to-seed. – skaht Jun 08 '19 at 02:31
  • 1
    @NateEldredge I got the same feeling from it, but the discussion is quite old, and possibly involves some misunderstanding - BIP39 in its current form already includes checksums, and it would generally be quite hard to create an insecure mnemonic, barring bad raw entropy (which would affect the current BIP32 seed in Bitcoin Core equally, since it would be the same entropy) – Raghav Sood Jun 08 '19 at 04:15
  • Well, the checksum for a 128-bit seed is only 4 bits, so you have a 1 in 16 chance of passing on the first try, and otherwise you can just change a couple of the words until you do. It appears the checksum feature was part of the BIP 39 proposal from its earliest days, at least since September 2013, so it's not a recent innovation. – Nate Eldredge Jun 08 '19 at 04:23
  • As an illustration, it only took about a minute of random guessing to come up with the valid BIP 39 phrase baby baby baby baby baby baby baby baby baby baby baby zebra. – Nate Eldredge Jun 08 '19 at 04:26
  • @NateEldredge If what you say is correct, that doesn't seem like a valid reason for not adding support for it. I mean no one stopping anyone from hashing a simple passphrase for their entropy. Seems like a very weak argument at best. – kcalvinalvin Jun 08 '19 at 06:16
  • I suppose you could open an issue on github requesting that it be implemented, and see how the developers respond. – Nate Eldredge Jun 08 '19 at 06:19
  • @NateEldredge Maybe that is the best way to go about it. Thanks for the effort though. – kcalvinalvin Jun 08 '19 at 06:19

1 Answers1

18

BIP 39 is not in Bitcoin Core largely for implementation reasons and because BIP 39 is not as secure as it could be.

The structure of Bitcoin Core's wallet doesn't really allow for BIP 39 to be implemented. The current structure doesn't allow for 512 bit seeds as BIP 39 specifies, and adding it would require some significant changes to the wallet code. Implementing BIP 39 would also require implementation of PBKDF2, although that isn't very hard.

Also, more generally, many Bitcoin Core contributors don't consider BIP 39 to be secure. It uses PBKDF2 which is generally regarded to be a fairly weak KDF so it isn't considered to be good for the secure storage of all of your Bitcoin. Some software (such as Electrum) used BIP 39 in the past but have switched to using their own mnemonic algorithm because of this weakness in BIP 39.

BIP 39 mnemonics have some other issues as well such as version numbering (or rather lack of) and the use of a fixed wordlist. Electrum has documented their reasons for why they don't support BIP 39, and those reasons are the same for Bitcoin Core.

Ava Chow
  • 70,382
  • 5
  • 81
  • 161
  • does bitcoin core use 256 bit seed in the wallet? And is this direct entropy that is used as seed or entropy is passed through some algorithm to arrive at the seed in Bitcoin Core? – Ugam Kamat Jun 08 '19 at 09:37
  • Besides PBKDF2, what would be the main reason for its weak security? Suppose if some other hash function that outputs 512 bit numbers is used. Would it be secure then? – kcalvinalvin Jun 08 '19 at 10:51
  • 1
    @Ugam Kamat yes, Bitcoin Core uses 256 bit seeds. It piggy backs off of the normal private key generation code. – Ava Chow Jun 08 '19 at 15:05
  • @K Calvin if another hash function were used, it may be more secure. However, as I've just edited, there are a few other issues with BIP 39. – Ava Chow Jun 08 '19 at 15:06
  • Worth noting that Electrum seed words are invertible while BIP 39 seed words are not due to the impact of one way hashes. Additionally, BIP 39 spoken language specific seed words (no internationalization of entropy is supported) can drive the synthesis of Electrum seed word but not the other way around because of BIP 39's one way hashing, i.e. Monero hardware wallets are doing this. – skaht Jun 09 '19 at 19:47
  • As far as I know, key stretching mainly servers the purpose of enhancing human-generated passwords,which is not the case for BIP39 mnemonic words (except the passphrase), since the words are randomly generated. Even the key stretching issue is taken into consideration (which is only useful to enhance the passphrase), isn't it possible to improve it? Since it's still possible to fix this problem, I don't see why key stretching could be a main reason not to use BIP39 or similar protocol. – Chris Chen Oct 23 '19 at 06:30
  • In other words, I wonder if the "mnemonic words" considered the correct direction of evolving by the developers at all? – Chris Chen Oct 23 '19 at 06:36
  • Electrum only switched from BIP39 to their own mnemonic format - they didn't give up on this direction. According to my experience of using Electrum, the lack of version numbering is almostly relieved by providing choices (of three different address types) to the user. – Chris Chen Oct 23 '19 at 06:40
  • IMHO, I suspect that the difficulty of coordination/seeking consensus among various projects is the main problem of BIP32/39/44 protocol. However, the incompatibility of mnemonic words seems to push the users back to handling WIF private keys, which seems to be far worse than adopting BIP32/39/44. – Chris Chen Oct 23 '19 at 06:57
  • @skaht I checked the docs of Electrum: "In order to eliminate the dependency on a fixed wordlist, the master private key and the version number are both obtained by hashes of the UTF8 normalized seed phrase" - Electrum also hashes the mnemonic words to generate the seed, which is not "invertible". Also, I didn't understand what you meant. What's "drive the synthesis of Electrum seed word"? What's "the other way around"? What "are Monero hardware wallets doing"? – Chris Chen Dec 14 '19 at 16:52
  • @Chris-Chen, see https://monero.stackexchange.com/questions/9815/support-for-a-ledger-nano-s-recovery-plan-b/10922#10922 for how BIP 39 seed words and bx can mimic the behaviors of Monero on a Ledger Nano S or Nano X. Details are provided for what the Trezor Model T is doing, not interoperable with Ledger devices. Concerning invertibility, go to https://github.com/skaht/XMR and look at the ./secret_key_to_public_key and ./bytes_to_words examples. With BIP 39 SHA512 hashing, one can't go backwards backwards. Good hashing functions are like entering into the event horizon of a black hole. – skaht Dec 14 '19 at 19:42
  • @Chris-Chen, the use of BIP 39 seed words is superior and substantially more capable the WIF private keys. BIP 39 HD wallets can support numerous decentralized accounts (essentially mathematically firewalled, speaking as an engineer) and provide multi-currency support. – skaht Dec 14 '19 at 19:49