BIP39 and Bitcoin Core: what the public record actually says
An examination of the documented objections, support for interoperability, and questions that deserve clarification today.
By FF2K ·
What do Bitcoin Core contributors actually say about BIP39? The public record contains specific design objections, historical implementation constraints, and support for interoperability. The sources reviewed here do not establish a single current collective position. Dated statements are evidence of what their authors said then, not confirmation of what they recommend today.
This examination separates those claims rather than treating every criticism, missing feature, or compatibility proposal as the same verdict.
What BIP39 does—and does not do
BIP39 encodes computer-generated randomness, with a checksum, into a human-readable mnemonic. It then converts that mnemonic into a binary seed using PBKDF2-HMAC-SHA512 with 2048 iterations and an optional passphrase. The seed can feed a deterministic wallet scheme such as BIP32. The specification explicitly says it is not a way to turn user-created sentences, or brainwallets, into wallet seeds. [4]
That distinction matters: criticism of predictable words chosen by a person is not automatically evidence that a correctly generated random mnemonic is guessable.
Versioning, recovery, and unsafe inputs
On March 14, 2017, Greg Maxwell wrote:
“The lack of versioning is a serious design flaw in this proposal. On this basis alone I would recommend against use of this proposal.” [2]
The recovery concern is practical. A mnemonic does not by itself specify all the derivation paths and address formats needed to find a wallet’s funds. Software that searches the wrong scheme, or no longer supports the required one, can present an apparently empty wallet. Electrum’s documentation describes that failure mode and also criticizes fixed-wordlist dependence. Electrum is a separate project; its documentation is not a Bitcoin Core statement. [5]
The current BIP39 specification still lists the lack of versioning as a shortcoming, but says it is now largely mitigated by descriptor wallets used alongside a seed. That qualification belongs beside the historical objection, not in a footnote that readers never see. [4]
Maxwell’s comment also warns about user-chosen mnemonic sentences (brainwallet-style inputs) and says implementations should enforce the checksum, describing implementations without that enforcement as an attractive nuisance that had caused losses. This is a warning about behavior and accepted inputs, not a demonstrated attack on properly random input. The specification itself requires computing the mnemonic checksum and warning when it is invalid. [2] [4]
The 2019 implementation and KDF criticism
In a June 8, 2019 Stack Exchange answer, Ava Chow, known on GitHub as achow101, wrote that BIP39 was absent from Core “largely for implementation reasons and because BIP 39 is not as secure as it could be.” [6]
The answer described the wallet architecture of that period as unable to accommodate BIP39’s 512-bit seeds without substantial changes. It also criticized PBKDF2 as a relatively weak key-derivation function and raised versioning and wordlist concerns. These are historical statements, not a description verified against today’s Core code. The page’s later edit by another user is not evidence that Chow reaffirmed the answer.
The KDF comparison needs care. Current Electrum documentation also describes 2048 iterations of key stretching, explicitly following BIP39. It would therefore be misleading to summarize Electrum as simply avoiding BIP39’s KDF approach. [5]
A useful clarification would identify the threat being discussed: guessing a weak optional passphrase after the mnemonic is exposed, guessing a weak mnemonic, or another attack. Those scenarios should not be collapsed into one claim about the security of randomly generated words.
Interoperability was also supported
In Bitcoin Core issue #16393 on July 15, 2019, Chow wrote:
“Concept ACK. I think it would be good for us to allow users of most other wallets to be able to import their full HD wallet into Core.” [1]
The same comment immediately acknowledged differing derivation paths and proposed combining seed import with descriptor wallets. Pieter Wuille, posting as sipa, wrote:
“It should be easily possible to convert a BIP39 seed into a descriptor.” [1]
Wuille opposed adding this support to the legacy wallet logic and directed development toward descriptors. These comments support interoperability through a descriptor-oriented approach. They do not amount to an endorsement of every BIP39 design choice, nor do they prove that a particular native import interface exists today.
What “unanimously discouraged” meant
On August 20, 2023, Wuille explained that the old “unanimously discouraged for implementation” summary described the negative comments submitted through the BIP comments mechanism—not a vote of all Bitcoin Core contributors. He wrote:
“All that is needed for that summary to change is for someone to post a positive comment.” [3]
He described the mechanism as apparently largely abandoned and its summary as potentially out of date. He also distinguished opposition to BIP39 from opposition to all seed-phrase systems or support for hot wallets.
The live specification reviewed for this article now says “Status: Deployed,” does not contain the old comments-summary header, and includes a Shortcomings section. “Deployed” records deployment status; it is not a security certification. Neither the old label nor the current status substitutes for examining the technical arguments. [4]
The discussion continued in 2025
The record does not stop in 2019. On March 24, 2025, in Bitcoin Core issue #19151, Sjors wrote:
“Every attempt to do this has been met with concept NACKs or lack of review. Maybe we should just decide to not do this and close?” [7]
Wuille replied the same day:
“I really don't see a problem with, or difficulty implementing, support for bip39 in descriptor parsing.” [7]
His proposal would map the input to an xpub internally rather than echoing the words back. This is support for a particular parser/import approach, not an endorsement of every aspect of BIP39 or proof that the feature was merged. The issue remained open when reviewed. The exchange records both stalled implementation efforts and continuing support for a route forward—not a unanimous position. [7]
What this record supports
Within these reviewed public sources, the strongest conclusion is a qualified one: identifiable contributors documented real design and implementation concerns, while some also supported importing other wallets through descriptors. The sources do not establish a current collective recommendation.
This is not a comprehensive survey of contributors, a current Core feature audit, or a security audit of BIP39 implementations. Absence of native support, criticism of a design, and evidence of an exploitable vulnerability are distinct claims. Each requires its own evidence.
An invitation to clarify the record
I welcome clarification from Bitcoin Core contributors, BIP39 authors, and wallet developers, including the people quoted here. Are these views still current? Are there newer discussions this article should include? Which concerns apply to correctly generated random mnemonics, and which concern weak passphrases, implementation behavior, or incomplete recovery information?
What gaps remain when descriptors accompany the seed? Is there a documented current recommendation readers should consult?
If a passage is inaccurate or incomplete, please identify the passage and the supporting source. I will correct errors and document substantive updates transparently. The purpose is to make the technical record clearer, not recruit developers into an argument.
— FF2K