BIP

Effective-Ad5644

it’s BIP110 reducing spam

osem23

Thank you, this is a very fair and useful read of the model. Yes, the key idea is exactly that: the native-language layer is display/input only, while the English BIP39 mnemonic remains the canonical seed input to PBKDF2. The goal is to improve comprehension without adding a new cryptographic path. I agree that the main risk is UX confusion. A wallet implementing this must make the distinction very clear: the native words help the user understand and enter the backup, but the English BIP39 phrase is the portable fallback for recovery in standard wallets. On wordlist quality, I agree as well. Even though these are not standalone BIP39 replacement lists, confusion risk still matters. Near-homophones, spelling ambiguity, diacritics, regional meanings, and memory collisions all need language-level review. That is part of why the project is public. The native-speaker review point is also valid. Some languages are already reviewed more deeply than others, but broader review is needed before treating every list as equally mature. And I agree on the adoption path. A reference library is probably the right next step, especially something wallet developers can integrate without maintaining the mappings themselves. Appreciate the thoughtful feedback. This is the kind of criticism that is actually useful for making the project safer and easier to implement.

whatwilly0ubuild

The approach is sound. Display-layer translation with English as the canonical seed input to PBKDF2 means you're not introducing new cryptographic surface area. The index-pairing keeps the mapping deterministic and reversible. A few considerations from the implementation and adoption side: The UX risk is users not understanding the distinction. If someone backs up their native-language phrase and later imports it into a wallet that only accepts English BIP-39, they may think their funds are lost. The display layer needs extremely clear messaging that the English phrase is the portable standard and the native display is wallet-specific. Documentation alone won't prevent this confusion at scale. Wordlist quality matters more than it seems. BIP-39's English wordlist was carefully constructed to avoid similar words, minimize prefix collisions (first 4 characters are unique), and exclude offensive terms. Do your translated lists maintain similar properties? A wordlist where two words differ by only a diacritical mark, or where words are near-homophones, creates backup error risk that doesn't exist in English. The 31 languages without native-speaker review is a liability. Machine translation or non-fluent selection can produce words with unintended meanings, regional ambiguity, or cultural problems. The request for native-speaker corrections is the right call, but wallets adopting this before thorough review would be taking on risk. Adoption path is the harder problem. This only helps users if wallets implement it. Most wallet developers won't add 31 language mappings for a feature that serves UX rather than functionality. A reference implementation as a library (JS, Rust) that wallets can drop in would lower the barrier significantly.

lospantaloonz

that was my recollection, but it may have been a requirement of the application i was using with the node itself - what i was seeing was the message from BIP-0159: `NODE_NETWORK_LIMITED` in the logs (but don't recall if it originated from the node itself or the application using the node). can always try it out again i guess, but good question!

osem23

Understood. You are free to disagree with the project, but you do not get to define it on our behalf. You are not the owner of Reddit or Bitcoin. The repository states the model clearly: this is a display/input layer over canonical English BIP39, with English remaining the recovery base layer and fallback. Readers can review the repo and decide for themselves. Good luck.

osem23

understand your position, and we can leave it there. To be clear, we do not agree with your characterization of the model. The repository explains that this is a display/input layer over canonical English BIP39, not a standalone replacement wordlist and not a new seed standard. You are free to disagree with the approach, but please do not present it as if the project changes the recovery path or forces users into an unsafe non-standard backup. That is not what is being proposed or implemented. The English BIP39 mnemonic remains the recovery base layer and universal fallback. I appreciate technical criticism, but repeating a warning based on a model we are not proposing would be misleading to readers.

osem23

I understand your position, but you are still criticizing a different model. I am not saying the English BIP39 wordlist is more authoritative than the other BIP39 wordlists. I am saying that in this implementation, English is the chosen compatibility base layer. That is an engineering and UX decision, not a claim that English is “better” or more valid than Spanish, Korean, Japanese, or any other canonical BIP39 list. If a wallet creates a Spanish BIP39 wallet from the start, then the Spanish BIP39 mnemonic is the source of truth for that wallet. Same for Korean, Japanese, French, etc. But this project is addressing a different case: A wallet that intentionally uses English BIP39 as its portable recovery base, while giving non-English users a native-language display/input layer so they can understand what they are backing up. Creating new canonical BIP39 wordlists for additional languages is a valid path, but it is not the same problem. A new canonical BIP39 wordlist creates an independent mnemonic system for that language. This project creates a semantic layer over an English BIP39 mnemonic, so the user can understand the backup while still keeping the standard English recovery fallback. Those are different goals. You are arguing that native users should use native canonical BIP39 lists where they exist, and I agree. But that does not invalidate an application-layer model where a wallet chooses English BIP39 for portability and adds native-language comprehension on top. So the distinction is simple: Canonical native BIP39 wordlists are for creating native BIP39 mnemonics. This project is for displaying and entering native-language meanings over an English BIP39 recovery base. That is the model.

na3than

Fine, I'll criticize the model. **You're treating the BIP-39 English word list as if it's special, preferred, primary or privileged.** It's not. All BIP-39 word lists are equally authoritative. Translating a BIP-39 English mnemonic into a mnemonic in another language is unnecessary. The BIP-39 model is very good, is extremely well accepted, and is extensible to other languages. Users who read English can and should use BIP-39 mnemonics constructed from the English wordist. Users who read Spanish can and should use BIP-39 mnemonics constructed from the Spanish wordist. Users who read Korean can and should use BIP-39 mnemonics constructed from the Korean wordist, and so on. Users who don't read English, Japanese, Korean, Spanish, Chinese, French, Italian, Czech or Portuguese aren't served well by the existing body of BIP-39 word lists, but **the best remedy for this is to draft and circulate for review new word lists in new languages following the principles laid out in BIP-39**: a) smart selection of words - the wordlist is created in such a way that it's enough to type the first four letters to unambiguously identify the word b) similar words avoided - word pairs like "build" and "built", "woman" and "women", or "quick" and "quickly" not only make remembering the sentence difficult but are also more error prone and more difficult to guess c) sorted wordlists - the wordlist is sorted which allows for more efficient lookup of the code words (i.e. implementations can use binary search instead of linear search) - this also allows trie (a prefix tree) to be used, e.g. for better compression

nick2001kuzn

this is why we need BIP-110, in the near future people can not store the full copy of the blockchain

osem23

That is the intended model. The user is not locked into the native-language display words. They can recover in the native language inside a wallet that supports this display/input layer, and they can also recover with the canonical English BIP39 words in any standard wallet that supports English BIP39. That is the base layer. The native-language words exist to help the user understand and enter the backup in their own language. But the recovery source of truth remains the canonical English mnemonic, and the English words are always the portability fallback. So nothing is “lost” if another wallet does not support the native display layer. The user still has the English BIP39 backup path. That is the point of the model: native-language UX for understanding, English BIP39 for universal recovery compatibility.

osem23

Yes, that is closer to the intended use case. This is primarily a UX and comprehension layer for wallet software, not a proposal to replace BIP39 wordlists or create a new independent seed standard. The user can still have the English BIP39 words as the universal recovery fallback. The native-language layer helps them understand what they are backing up, instead of copying foreign words blindly. A true additional BIP39 wordlist for each language would also be valuable, but that is a different goal and a much higher standardization process. This project is focused on a more practical layer: keep English BIP39 compatibility underneath, while making backup and recovery clearer for non-English users inside wallets that choose to support it.

Langiri

I think maybe I'm misunderstanding your intended use case. If you are suggesting that the user should still memorize / enter the words in English, and this is just meant as a drop in "UI convenience" layer for wallet software, then you probably have far less work to do. But it does seem like a much better goal to actually develop a true alternative list (conforming to the requirements laid out above for BIP39 word lists) so that that I can simply memorize a seed phrase in my own language without increasing my likelihood of making a mistake.

osem23

Specific language feedback is welcome, and that is why the lists are public. A lot of work was done to reduce issues across each language as much as possible, but no multilingual UX layer is perfect without broad native-speaker review. The important point is that this does not put the backup at risk. The recovery source of truth remains the canonical English BIP39 mnemonic. The native words are a display/input layer, not a replacement seed standard. So yes, individual words can be reviewed and improved. But that does not invalidate the model or make the recovery path unsafe.

Langiri

Unless this is meant for internal use by an internal team building out a new UI, it's important to acknowledge that most people aren't going to read the README. They are going to see "_the_ word list" in my language and use it. The point u/na3than made about words with overlap in the first four characters in German also applies in Vietnamese. But, even if you are simply going for "easier to remember words in your own language" not "easy to enter accurately", these lists still need revision. Your list does not avoid semantic overlap (This is the "Avoiding words that are easily confused." from u/bitusher's comment above) like the BIP39 lists do. Just one example: tuổitrẻ and trẻtuổi These are close enough in _meaning_ (as well as spelling, they are the same two syllables reversed) that it would be easy to misremember which one you used.

osem23

I think we are going in circles here. The repository already explains the intended model: this is a display/input layer that maps back to the canonical English BIP39 words. It is not presented as a standalone replacement BIP39 wordlist. The English words remain available for standard wallet recovery, and the native words are there to help users understand what they are backing up. Your criticism seems to assume a different model than the one described in the repo. If you want to critique the actual proposal, please read the repository and address that model directly. I appreciate technical criticism, but repeating the same assumption does not move the discussion forward.

na3than

> The recovery path has not changed. Yes, it has. Anyone who uses your mnemonics to recover their wallet must use a non-standard client that knows about your non-standard recovery path. Same with my counterproposal, but mine uses standard word lists that don't suffer from 4-character collisions AND my mnemonics include standard checksums. > The underlying recovery path is still the standard English BIP39 mnemonic. Same with my counterproposal, but mine uses standard word lists that don't suffer from 4-character collisions AND my mnemonics include standard checksums. > The native-language words are only a translation/display layer that maps back to the same canonical English BIP39 words before recovery. Same with my counterproposal, but mine uses standard word lists that don't suffer from 4-character collisions AND my mnemonics include standard checksums. > A user can back up in the native language for understanding, or back up the English BIP39 words directly. The English words remain available as the universal recovery fallback and can be restored in any standard wallet that supports English BIP39. Same with my counterproposal, but mine uses standard word lists that don't suffer from 4-character collisions AND my mnemonics include standard checksums. > So this is not “enter a non-standard mnemonic into a non-standard wallet” as the only recovery path. Same with my counterproposal, but mine uses standard word lists that don't suffer from 4-character collisions AND my mnemonics include standard checksums.

osem23

You are mixing two different things. The recovery path has not changed. The underlying recovery path is still the standard English BIP39 mnemonic. The native-language words are only a translation/display layer that maps back to the same canonical English BIP39 words before recovery. A user can back up in the native language for understanding, or back up the English BIP39 words directly. The English words remain available as the universal recovery fallback and can be restored in any standard wallet that supports English BIP39. So this is not “enter a non-standard mnemonic into a non-standard wallet” as the only recovery path. The model is: Native language for user understanding English BIP39 for universal wallet recovery Translation layer only No change to seed generation No change to PBKDF2 input No change to the actual recovery path You can disagree with the UX choice, but saying the recovery path was replaced is misleading. The whole point is to preserve the English BIP39 recovery path while making the backup understandable to users who do not speak English.

na3than

But you HAVE changed the recovery path. The recovery path changed from "enter a BIP-39 mnemonic into a BIP-39 compatible wallet" to "enter a non-standard mnemonic into a non-standard wallet that knows what to do with it". You've jeopardized recoverability by introducing an obscure encoding technique. Why do you insist on adding more risk by using non peer-reviewed word lists?

osem23

I think we are talking about two different goals. If a wallet is creating a new Spanish BIP39 wallet from scratch, then yes, the canonical Spanish BIP39 list is the right tool. But this project is not trying to create standalone Spanish BIP39 mnemonics. It is a display/input layer for wallets that intentionally keep English BIP39 as the compatibility and recovery source of truth. In that model, the native words are aliases for the English BIP39 words, not a separate mnemonic to hash. Your counterproposal also requires special wallet logic. The wallet must know not to hash the Spanish mnemonic normally, but to decode it to entropy, re-encode that entropy as English, and then hash the English mnemonic. So both models require explicit wallet behavior. The difference is UX: Your model shows a standard Spanish BIP39 mnemonic that does not semantically match the English words the wallet ultimately needs. This model shows native-language meanings that map directly to the English BIP39 words, while keeping the English mnemonic available as the recovery fallback. I am not saying this replaces canonical native BIP39 lists. It solves a different problem: making an English-BIP39-based wallet understandable for non-English users without changing its recovery path.

na3than

> That is why simply re-encoding the same entropy into another canonical BIP39 language is not a safe recovery path for a wallet originally created from the English mnemonic. On its own, no. The same is true for your method: encoding an English BIP-39 mnemonic in Spanish is not a safe recovery path for a wallet originally created from the English mnemonic. Both methods require the wallet to know it has to perform extra steps to recover the seed from the Spanish mnemonic. So your method offers zero advantage in that regard. > The goal is to let a non-English user see and input native-language words while still resolving back to the exact canonical English mnemonic that the wallet uses as the PBKDF2 input. BUT WHY? Why are you working so hard to store an English BIP-39 mnemonic in another language? NON-ENGLISH USERS SHOULD NOT CREATE BIP-39 MNEMONICS USING THE ENGLISH WORD LIST. THEY SHOULD CREATE BIP-39 MNEMONICS IN THEIR PREFERRED LANGUAGE. > But if the wallet’s source of truth is the English BIP39 mnemonic, re-encoding the entropy into Spanish does not give the user the same recoverable wallet in ordinary BIP39 restore flows. It gives it the same level of recoverability as your method, except it does it using an **already standard word list** that avoids the 4-character collisions you've recklessly ignored. In your method, the Spanish user who re-encoded his English mnemonic needs to give his Spanish mnemonic to a special wallet client that's smart enough to know it has to translate the Spanish to English using an obscure dictionary before hashing the English mnemonic. In my counterproposal, the Spanish user who re-encoded his English mnemonic needs to give his Spanish mnemonic to a wallet that's smart enough to know it has to convert the Spanish mnemonic to the original entropy **using the standard BIP-39 Spanish word list**, then encode the entropy in English **using the standard BIP-39 English word list**, then hash the English mnemonic. Both methods require a client that knows the Spanish mnemonic can't be used as a normal BIP-39 mnemonic, but your method uses a flawed, unvetted, nonstandard encoding. Your method offers zero advantage.

osem23

I understand that BIP39 mnemonics encode entropy, and yes, the same entropy can be represented by different BIP39 wordlists. But that is exactly where the practical recovery problem appears. In BIP39, the final seed is not derived from the entropy alone. The seed is derived with PBKDF2 using the mnemonic sentence itself, plus the optional passphrase. So if a wallet was originally created from an English mnemonic, and you decode the entropy and re-encode that entropy using the Spanish BIP39 wordlist, you may have the same entropy representation, but you do not have the same PBKDF2 input. A standard wallet restoring from the Spanish mnemonic will hash the Spanish mnemonic sentence, not the original English sentence. That produces a different seed. That is why simply re-encoding the same entropy into another canonical BIP39 language is not a safe recovery path for a wallet originally created from the English mnemonic. The goal of this project is different. It is not trying to say that English is the only valid BIP39 wordlist, and it is not trying to replace canonical native BIP39 wordlists. The goal is to let a non-English user see and input native-language words while still resolving back to the exact canonical English mnemonic that the wallet uses as the PBKDF2 input. So the native words are not a new mnemonic sentence to be hashed. They are aliases for the English BIP39 mnemonic words. That preserves compatibility with the wallet’s original English BIP39 seed flow while giving the user a language layer they can actually understand. If a wallet is created natively using the Spanish BIP39 wordlist from the start, then of course the Spanish mnemonic is the correct source of truth for that wallet. But if the wallet’s source of truth is the English BIP39 mnemonic, re-encoding the entropy into Spanish does not give the user the same recoverable wallet in ordinary BIP39 restore flows. That distinction is the reason for this approach.

SellaPipeYO

Yep, buy more, run a node, signal for BIP110, transact in BTC! Never been a better time to be a bitcoiner

TheGreatMuffin

> Can AI data centers be used to attack btc network? No, what data centers (AI or not) are doing, has nothing to do with bitcoin. If you are referring to various mining-side attacks, it's not possible because bitcoin mining requires very "dumb", specialized devices that can do only one thing well: perform [SHA256 hashes](https://learnmeabitcoin.com/technical/cryptography/hash-function/). These devices are useless for anything else. And devices that are not optimized for that (data centers) are useless for bitcoin mining (or attacking it as a mining entity). > Can they be used to vote on bips setting up a ton of nodes? An entity can set up hundreds of thousands of nodes but they cannot enforce rules for other nodes. Every node is verifying everything on its own, so if there's a majority of "fake" nodes that follow different rules, everybody else will just ignore those nodes and continue happily on the "real" chain. The network is not really a democracy (nor is the BIP process itself), it's more of an anarchic system, which is often described as "rules, but no rulers". Meaning, there is nobody to enforce rules, you just can follow them and be in sync with those that follow the same rules, or you don't. Nobody forces you to do anything; neither an entity nor the majority of nodes.

Unable_Beat_3194

Look at the BIP proposals that counteract quantum compute. What makes you so firm on your stance?

na3than

I think you don't understand how - or why - BIP-39 works. BIP-39 encodes entropy in human-friendly form. If you created a wallet using software or firmware that gave you the following BIP-39 mnemonic sentence: `ritual fly merit private adult orange hollow token letter quality lock culture` ... I could prove to you that the entropy encoded by this mnemonic is ba8b3e2e55903d379b3f1f8095e60d9a. Using BIP-39 I could encode that same entropy as: `preso filtro medalla parcela acusar norma hogar teléfono lino pellejo logro cojín` or: `pizza espèce lanterne oisillon aciduler migrer frère sucre indexer ouragan instinct colibri` or: `抢 苦 豆 违 就 网 困 杰 壤 罚 床 市` All encode the same entropy. Read that again: **All of these mnemonic sentences encode the same entropy.** An Italian one is easiest to read for an Italian language native, and an English one is easiest for an English language native, but they're **all the same entropy**. Now, to derive a seed from that entropy, BIP-39 says one needs to hash the mnemonic sentence (plus an optional passphrase, if one is used), and THAT step obviously requires one to specify which word list to use for the encoding, but so what? You've proposed a method that allows a non-English reader to read and write a sentence in their native language that translates to an English mnemonic sentence, presumably to help them recover a wallet that was originally created by hashing an English mnemonic sentence. For that use case, why not just take the English mnemonic, reconstruct the original entropy, and re-encode it using the word list for user's native language?

osem23

I understand the question, but this is exactly the issue I am trying to point out. I am not saying English is morally or linguistically superior to the other BIP39 wordlists. The reason English is used as the source of truth in this model is because the existing non-English BIP39 lists are not translations of the English list, and they are not semantically aligned with each other by index. They are independent wordlists. That means the word at index N in Spanish, Korean, Japanese, French, etc. usually does not mean the same thing as the English word at index N. So for a normal user, this creates a strange UX problem: If their wallet shows an English mnemonic and then tries to “show it in Spanish” using the canonical Spanish BIP39 list, it cannot do that. The canonical Spanish word at the same index is not the Spanish meaning of the English word. It is a different word that happens to occupy the same entropy index. That may be valid cryptographically, but it is not a translation layer. This project is trying to solve that specific gap. It keeps one canonical cryptographic floor, the standard English BIP39 mnemonic, and adds native-language display/input words that are semantically paired to that English mnemonic by index. So when the English word is “abandon”, the native display word is actually the native-language equivalent of “abandon”, not an unrelated word from an independent native BIP39 list. That matters for user understanding. The goal is not to claim that English is the only valid BIP39 list. The goal is to avoid the destructive UX mismatch where users think they are seeing a translation, but in reality they are seeing a completely different independent wordlist. If someone wants to propose new full canonical BIP39 wordlists for languages that do not have them, that is a valid path too. But that solves a different problem. This project is not trying to replace canonical native BIP39 lists. It is trying to create a clear display/input convention where the native words actually mean the same thing as the mnemonic being backed up, while keeping recovery compatible through the English BIP39 source of truth.

na3than

> that maps back to the canonical English BIP39 list, with English remaining the source of truth. Why? Why does an English mnemonic need to be the source of truth for non-English users? The BIP-39 English word list is no more canonical than the Japanese, Korean, Spanish, Chinese (simplified), Chinese (traditional), French, Italian, Czech or Portuguese word lists. If a language doesn't have a word list in the BIP-39 repo, propose one.

osem23

That is fair pushback on the framing. The UX problem is still real: many non-English users struggle with English recovery phrases. That is the problem this project is trying to address. At the same time, recovery UX touches real funds, so wording, review, and limitations matter a lot. That is not the intended model. The intended model is a native-language display/input layer that maps back to the canonical English BIP39 list, with English remaining the source of truth. We have already updated the README and documentation to make this clearer, including stronger guidance around limitations, backup format, and what these lists should not be used for. I appreciate the detailed criticism. This is exactly the kind of feedback that helps make the project safer and clearer.

na3than

> A new canonical native BIP39 list requires broad review, standardization, wallet adoption, long-term support, and user confidence that other wallets will accept it in the future. That is a much higher bar, and it is not available for most languages right now. Yeah, there's a reason for that high bar: quality. Your proposal skips all the hard work and just puts something out in the wild without rigorous review. In ten minutes of review I discovered one major weakness. How many more weaknesses are still undiscovered? How many contributors vetted the word lists you proposed as "a new convention"? The tone of your initial post and your responses to comments gives me the impression you have an unjustifiably high assessment of the quality of your product and its readiness for public consumption. You don't seem all that open to accepting criticism on it. It may be "open source" in the sense that anyone can read it, but if you're not willing to alter it based on public feedback, what's the point?

osem23

I don’t think the answer is that this method is universally “better” than having a canonical BIP39 wordlist in every native language. If a language has a well-reviewed canonical BIP39 wordlist, designed with the same constraints as the original lists, supported by wallets, and accepted across the ecosystem, then that is obviously a very good solution. The problem is that most languages do not have that today. So the value of this approach is different: It gives the user native-language understanding while preserving immediate compatibility with the existing English BIP39 ecosystem. A new canonical native BIP39 list requires broad review, standardization, wallet adoption, long-term support, and user confidence that other wallets will accept it in the future. That is a much higher bar, and it is not available for most languages right now. Our approach keeps the English BIP39 mnemonic as the source of truth, but adds a native display/input layer on top of it. So the tradeoff is: Canonical native BIP39 list: cleaner if it exists and is widely adopted Native display/input layer mapped to English BIP39: more compatible today, easier to integrate in one wallet, and gives non-English users a way to understand what they are backing up without leaving the existing English BIP39 recovery path That is the point. I am not saying this replaces the need for proper native BIP39 wordlists. I am saying it can help users now, especially in wallets that want to preserve English BIP39 compatibility while improving recovery UX for people who do not understand English.

na3than

Everything you just said is made easier and less fragile by creating additional BIP-39 word lists in other non-English languages. So I'll ask again: How is your method better than presenting the non-English user a mnemonic sentence using a canonical BIP-39 word list for their native language?

osem23

Yes, exactly. That is very close to the intended model. The native-language words are meant to help the user understand and confidently record the backup, but the English BIP39 words should remain available as the universal recovery fallback. A good wallet UX could show both side by side during backup: native word for the user’s understanding canonical English BIP39 word for compatibility That way the user gets the benefit of a recovery phrase they actually understand, while still having the English BIP39 version available if another wallet only accepts the standard English list. So the goal is not to hide the English words or create a separate recovery world. The goal is to make backup clearer for non-English users while preserving the existing recovery path. In practice, I agree that a recommended policy should probably be: if a wallet uses a native display/input layer, it should give the user the option, or maybe the default, to back up both the native word and the canonical English word together. That gives users the best of both sides: local-language understanding and standard BIP39 portability.

osem23

The value is UX and recovery confidence. For a native English speaker, the English BIP39 list feels natural, so this problem is almost invisible. But most of the world does not speak English as a native language. For many users, an English mnemonic is not really a “sentence” or even a meaningful set of words. It is a sequence of foreign symbols they are asked to copy perfectly and trust with their savings. I have worked with thousands of non-English-speaking Bitcoin users, and backup/recovery is consistently one of the hardest parts. This is where many people make mistakes, lose confidence, or fail to understand what they are actually saving. That creates real recovery risk: They may not understand what they wrote down They may confuse similar-looking English words They may make spelling mistakes They may not feel confident verifying the words later They may rely on screenshots, translation apps, or someone else for help A canonical native BIP39 wordlist would be ideal where it exists and where the user’s wallet supports it. But BIP39 only has a limited number of official wordlists. Most users do not have a canonical BIP39 list in their native language. The point of this approach is not to create a new seed scheme. It is to give users a native-language display/input layer while keeping compatibility with the existing English BIP39 standard underneath. So the wallet can say to the user: “Here are words you actually understand,” while internally preserving the same BIP39 indexes and canonical English flow. That makes backup and recovery more understandable without requiring a new cryptographic standard. For English speakers this may feel unnecessary. For non-English users, it can be the difference between copying foreign words blindly and actually understanding what they are backing up.

na3than

> The goal is to make recovery UX more understandable for non-English users while still relying on the existing English BIP39 standard underneath. Why? What's the value in presenting a non-English mnemonic to the user, then converting it to English before hashing it to create a seed? How does that "make recovery UX more understandable for non-English users" compared to presenting the non-English user a mnemonic sentence using a canonical BIP-39 word list for their native language?

osem23

I understand the concern, but I think there is an important distinction here. These lists are not intended to replace BIP39, and they are not used as independent seed wordlists. In our implementation, the canonical source of truth remains the standard English BIP39 wordlist. The wallet maps the displayed native-language words back to the canonical English BIP39 indexes before any seed operation. PBKDF2 is not run on the translated words, and the cryptographic seed flow is not changed. So the user is not creating a new German BIP39 seed based on a German replacement list. They are using a localized display/input layer that resolves back to the standard English BIP39 mnemonic. That said, your point about users shortening words to 4 characters is a valid concern in a general public-wordlist context. If someone tried to use these lists as standalone BIP39-compatible wordlists, or engraved shortened versions of the localized words on metal, that would be unsafe unless the list guarantees the same uniqueness and clarity rules. But that is not the intended use case here. The intended model is: canonical BIP39 English remains the source of truth native words are display/input aliases wallet validation resolves them back to the English BIP39 index seed generation remains unchanged no wallet should treat these as standalone BIP39 replacement lists without additional guarantees So I agree this distinction needs to be made very clearly in the README to avoid misuse. The goal is not to create new BIP39 wordlists. The goal is to make recovery UX more understandable for non-English users while still relying on the existing English BIP39 standard underneath.

osem23

Exactly. That is the main point. A recovery phrase is only useful if the user can confidently write it down, recognize it, store it, and recover from it later. For English speakers this is taken for granted. For many users, English seed words are just unfamiliar symbols they are forced to copy carefully. The goal here is not to change the cryptographic seed flow or replace BIP39. It is to give non-English users a clearer display and input layer, so they can still recover reliably and keep full control of their bitcoin, even if they do not understand English. Self-custody should not depend on being comfortable with English.

osem23

Thank you, this is a very fair point. I agree that the original BIP39 wordlists were not designed as direct translations, and that their priorities around avoiding confusion, spelling ambiguity, similar-sounding words, and short-prefix uniqueness are important. To clarify my intention: I am not trying to replace the existing BIP39 lists, change the seed generation flow, or suggest that wallets should adopt this as a standard. This project is more of an open contribution / experiment for multilingual Bitcoin UX. It gives wallets and developers an additional reference if they want to explore native-language display or input layers, but there is no expectation that anyone must use it. The canonical BIP39 flow remains the source of truth. If a wallet needs strict 4-character uniqueness, metal backup compatibility, or full BIP39-style wordlist guarantees, then it should absolutely require that before using any list in production. So I agree with the concern. This repo should be understood as optional, experimental, and open for review, not as a claim that direct translations are better than the original BIP39 wordlist design principles. Appreciate the thoughtful feedback.

bitusher

Interesting... For those wondering the original BIP39 lists are here https://github.com/bitcoin/bips/tree/master/bip-0039 and list 10 different language lists The reason these lists did not use direct translations is because they prioritized - Avoiding words that are easily confused. - Avoiding words with multiple common spellings. - Avoiding words that sound nearly identical. - Ensure the first few letters uniquely identify the word. A direct translation of an English word might violate those rules in the target language. >We would appreciate review, criticism, native-speaker corrections, I am just wondering why a direct translation should be prioritized over the above concerns ? Also I read this - >"4-char prefix uniqueness is not guaranteed across all scripts. Wallets relying on prefix autocomplete should fall back to full-word matching." Which IMHO should be a non starter because this is needed for most wallets and even many metal seed backups It is critical for UX that wallets can auto complete the word after 3-4 characters rather than typing in many more characters

polymath_uk

Yes, I understand what you are saying. I have developed an app which takes a BIP passphrase as user input and generates in memory a bunch of keys for various purposes. The keys are not persisted and are regenerated each time the app opens. But, I could easily enough store some or all of those keys and send them somewhere if I were a malicious dev. What is stopping you from doing that?

Suspicious_Bag_9264

I already know that and saw BIP 360 361 and the enormous problem that we have Should not be a problem until 2029 at least

bitcoinuser2

You forgot to add quantum computers to your paranoid.  BIP-360.

lifeanon269

No. How would that even work? The reason why miners earn bitcoin is because they put in the work. There is no intensive work required to spin up a node. Earning bitcoin from just spinning up a node would be vulnerable to a Sybil attack where someone would just spin up thousands of nodes at once. We already see that with certain types of fork signaling where people just spin up thousands of new nodes just to make it seem like there is a ton of support for it *cough* BIP-110 *cough*. Running a node allows you to validate your transactions and gain privacy through broadcasting your transactions from your node and not exposing your xpub to other nodes.

Illustrious-Boss9356

You know how many things that run on SHA256 can be switched easily without the need for consensus from many different conflicted parties? And ECDSA will be broken before SHA256, you know the thing that secures public/private keys? And your bank account, mortgage, etc. are all centralized. All that needs to happen is for me to prove to JP Morgan that I'm me. Cannot prove that I'm the owner of a certain BTC address if others know my private key. And how will a BIP deal w a dwindling security budget? These are real issues and I'm not suggesting there aren't solutions. I'm saying it's concerning that very few people are actually debating these issues, rather they're selling and moving on to other things. I didn't sell any BTC for almost a decade, now I'm selling regularly until the actual community around Bitcoin cares about Bitcoin the chain, rather than Bitcoin the number.

CryptoAnarchyst

Lmao… 10 years from now BIP will be in place to deal with it… but more importantly, you know how many things run on SHA256 encryption? You think that Bitcoin tokenomics are an issue? How about your personal data? Your bank account? Your mortgage? You’re falling for the distraction, not the real issue

Illustrious-Boss9356

If Saylor get's liquidated, I think we'll in the $20-25k range. If BIP-110 fork goes sideways, I think we'll be in the $20-25k range. If quantum breaks ECDSA, we'll be in the $1-5k range. If none of those happen, I think we'll be in the $300-500k range.

Illustrious-Boss9356

Crypto isn't over. But most of the projects currently on existence are over. Plenty of headwinds. People have to realize that crypto is just software + adoption (and hardware + energy for PoW chains). If any of the large powerful institutions wanted to actually adopt, they would just create their own chains. Why would they build on ETH or SOL or XRP? The crypto side is easily replicable but influence, power and capital are not. They hold the cards. BTC being the exception because it's a hedge on central bank money printing, serves no other purpose and if they can figure out quantum migration, BIP-110 doesn't tear the community apart, and they figure out the security budget issue coming in 6-8 years, it should be ok. That's A LOT to get right and even then it's still not as good as investing in the economically productive assets. I say this as a BTC maxi.

Illustrious-Boss9356

A lot of talk here about asset class capital rotation into AI, how exciting or boring BTC is. Again, I want to stress please get involved and talk about the important things fundamental to the chain itself. Noderunning, upcoming BIP-110 soft/hard fork, and quantum migration. Yes the supply is limited to 21m, but there are unlimited chains. Yes, SHA256 is quantum resistant but ECDSA is mot. Yes, spam on chain could become an issue and there aren't enough economic transactions to crowd out cheap spam. These are all real issues and if the owners of BTC just want the number to go up... boy we're gonna be in for a rough ride. Please spend your BTC. Make bets w your friends in BTC. Send/receive your BTC! Accept BTC for selling things!

crunchyeyeball

It's really tricky. Classic *principles* versus *pragmatism* dilemma. I do lean slightly towards the "hourglass" consensus change as a possible interim measure: https://github.com/cryptoquick/bips/blob/hourglass/bip-hourglass.mediawiki ...but I'm still undecided on BIP 361 itself.

insubordinate_kralc

We’ll see with what ends up happening with BIP110. My biggest mistake could still be ahead of me…

IllllIIlIllIllllIlll

You can already do this yourself. Create a BIP39 wallet on a hardware wallet, send your bitcoins to it, and then backup only 8 out of the 12 words and wipe the hardware wallet. It would take roughly 10 years to bruteforce the missing 4 words on a normal computer.

Illustrious-Boss9356

Everyone's talking about price, which is why I'm still less than bullish. There is a ton going on in the world as it relates to BTC: BIP-110 fiasco and risk. Quantum computing advancements. Countries shutting down the use of BTC. It being much less pseudononymous as more CEX's are working w authorities to identify wallets to create paper trails. Miners and mining pool consolidation. Hashrate stagnation/drop. Power being more competitive due to AI needs. Future security budget concerns. My worry isn't that these risks exist, there will always be risks w anything. My worry is that the MAJORITY of Bitcoiners don't know or care about these risks. That's the fact pattern I worry, and until we see some change there, I have paused my DCA. I even sold a few BTC when Saylor sold earlier this week... first time I have sold BTC in over 7 years.

alami9

BIP-360 only protects new addresses and only when at rest. On-spend, these addresses are still vulnerable. The time the addresses exposed during transaction is 10 minutes, Google’s March 31 paper says 500000 physical qubits can break public key in 9 minutes. BIP-361 is in discussion only, including about freezing coins.

jkl2035

I have around 4-6m BTC in mind Hunter Beast (author of BIP360) was mentioning

MadSL1m

good question but worth separating two things. Google/Microsoft 2029 is general-purpose quantum. cryptographically-relevant quantum (CRQC = enough qubits to break secp256k1) is a separate threshold, most credible estimates land 2030s+. BIP360 is the signature scheme proposal, BIP361 covers migration logistics. dev work isn't stalled, it's at Brink stage. realistic risk window is P2PK + reused P2PKH UTXOs first (\~2M BTC), not active addresses.

malcador_th_sigilite

Regarding phase B of BIP361, frankly five years from even today is too long. There is a trade off where a tail of users who cannot afford the competitive fees of upgrading (given the massive rush to do so) will be left behind permanently, but also quantum computers may arrive faster than that date, leaving remaining wallet vulnerable (again the “lost” wallets e.g. satoshi). There is no perfect solution here. People crying centralisation over this simply don’t understand the tradeoff here imo.

DepthHorror9528

\> One thing that attracted me to Bitcoin originally was the idea that controversial rule changes would only happen with overwhelming social consensus. My impression was that maintainers acted conservatively and avoided pushing changes that large parts of the ecosystem strongly disagreed with. In this case the "Twitter mob" didn't get to decide. The meritocratic nature of Bitcoin is that knowledgable people get to decide. In this case all the OG devs believes this is the best way for Bitcoin and to save decentralisation. ( Open letter [https://bitcoincore.org/en/2025/06/06/relay-statement/](https://bitcoincore.org/en/2025/06/06/relay-statement/) ). The whole narrative that this relay policy change is somehow a deep conspiracy to invite spam is largely just that, a created narrative that isn't based on the fact and reasons for the change. It's easy to read and understand why. Bitcoin requires consensus which BIP110 doesn't have. So Bitcoin work just as intended. If a angry Twitter Mob shouting "Censor transactions I don't like! Fire the core devs!" gets to decide. Then we are truly in trouble.

na3than

You did not import "someone's wallet". You created a valid seed for a new wallet. One out of every 16 combinations of twelve words from the BIP-39 word list is a valid BIP-39 mnemonic. Congratulations, you found one of the 340,282,366,920,938,463,463,374,607,431,768,211,456 valid combinations.

Illustrious-Boss9356

Quantum is a threat to all security. But here's the difference. If I own my house, I can just change the locks. If you and I and thousands of others all have own a small stake in a house, it's difficult to get everyone to agree on changing the locks. What kind of new lock are you gonna put on it? Who's gonna get a copy of the new key? Which vendor are you gonna use? It's disingenous to say that banks and the NYSE will have a harder time adopting quantum resistance than the Bitcoin blockchain. Look at what's happening w BIP-110 as we speak. August is approaching fast... tick tock.

Illustrious-Boss9356

No but you said digital assets are the future, not "blockchain assets" are the future. And while I agree in some cases let's not pretend there are risks: 1. BIP110 soft/hard fork 2. Quantum computing 3. Security budget. Sincerely, a BTC Maxi who's losing conviction because 75% of the community chatter has become "the cycle" and "go up or down?". What happened to debating the benefits of centralization? Block size? Shielded vs unshielded addresses? Incorporating ZK capability onto BTC's chain? What happened?!?!

Illustrious-Boss9356

AI is not speculative. We use it every day. I used to use BTC much more than I do now. Especially back when no one tracked it or had KYC. And not only that there are 3 major issues which lack clear solutions, in order of near term risk: 1. BIP-110 potential soft or hard fork, 2. Quantum Computing advancement being accelerated by AI and 3. Security budget when 2/3 more halvings occur.

bitusher

If BIP110 creates their altcoin and forks off you would settle with your altcoin token and bitcoin token on both chains separately. A reorg concern is not a problem with lightning specifically but all transactions which is different entirely. This is why we typically want at least 90% of hashrate support to signal the remaining 10% of miners to upgrade before activation. Any softfork that requires less than at least 80% signalling is reckless and should be considered an attack on Bitcoin that disregards the safety of the users.

Illustrious-Boss9356

Same. Unless inflation picks up into 10% territory, which is possible, I just don't see where the demand will come from. Retail by and large lost $$ in BTC but even more in empty promises known as alts. Hard to clean up the crypto reputation... will take a long time. And the current BIP-110 situation and acceleration of Quantum Computing advancement are not helping...

bitusher

It would be foolish to close your channels because BIP110 should not be taken seriously and is more of a joke with almost no miner support . Even if they were successful your lightning channels would be fine on the original chain regardless. >Since they have progressively been finding more blocks This is not true . 0.1% signalling is so insignificant and there is no evidence its growing.

inmathwetrust

You seem to base your conviction in what other people say. While ignoring the fact that their movement keeps growing. Just last night another miner started signaling for BIP110. I think is safer to close LN channels close to mandatory signaling day.

Jaded_Bullfrog3978

I bought a new machine yesterday to run a BIP-110 node, I’ll be joining

Thin_Needleworker795

Awesome. Let's go BIP110 💪🚀🚀

Billkr

I can give you the google AI answer: A little more than ELI5. BIP-110 (Bitcoin Improvement Proposal 110), also known as the Reduced Data Temporary Soft Fork (RDTS), is a controversial proposal in the Bitcoin community designed to temporarily restrict the size of arbitrary data fields at the consensus level The purpose and key aspects of the proposal include: Combating Network Bloat: The proposal is designed to act as a temporary filter to curb network spam, large OP\_RETURN payloads, BRC-20 tokens, and Ordinals inscriptions that proponents argue bloat the blockchain and drive up fees. The "Signaling" Process: Miners signal their readiness and support for the BIP-110 upgrade by embedding specific version bits or data into the blocks they mine. Activation Thresholds: The proposal aims to trigger a soft fork once a 55% hash power activation threshold is reached, or at a predetermined block height, though some miners have already begun actively signaling support. Divide: The initiative has sparked intense debate. Supporters view it as a necessary defense to preserve Bitcoin’s primary role as a monetary network. Meanwhile, critics, including prominent developers and industry figures, warn that this consensus-level intervention sets a dangerous precedent for censorship, damages network credibility, and threatens the principle of neutral, predictable transaction capacity

inmathwetrust

At least is an honest answer. Most people reply assuming that they already know what is going to happen. But, so far I have not received a reply explaining why BIP110 cannot grow. Is like they all forgot that they were spermatozoids one time (excluding bots). As I understand it Bitcoin is designed to build consensus trough the process that we are going trough.

inmathwetrust

I agree that ”economic nodes” will decide what happens at the end. But I think you cannot dismiss hash renting BIP110 nodes as non-economic nodes. Those are people that are paying with their own Bitcoin to have a say on what Bitcoin is (reminds me of the movie 300). On the other hand exchanges, Strategy(Saylor), XXI(Jack Mallers) and the like , are subject to political influence and are in debt to their tits. So the “300” hash renting BIP110 signaling nodes may be the ones that have a final say if their influence keeps growing. How can you be so sure that this will not happen?

inmathwetrust

Sure this will shock even pro-BIP110 supporters. Since it is starting from very little and this has never been done. But it doesn’t mean it could not happen. Again, what makes you 100% sure it will not happen? I want to understand where your confidence comes from.

inmathwetrust

I was. But i’m trying to understand what makes people so sure that BIP110 is not going to keep growing since it has clearly shown measurable signs that it is.

Thin_Needleworker795

No, it's there to SAVE the network from spammers and scammers. You should support BIP-110.

Broad_Refrigerator99

BIP110 will activate this year gfy gmaxwell XD

nonkeywayzee

You do you, but nothing will happen, the knots people don't have enough economic power to get the network to migrate to BIP-110, they are an economic minority in the network, no economic nodes support BIP-110, no exchanges have even thought about this fork, so no, it isn't happening, stop worrying, they will just fork themselves off. If you want to be really sure, just contact your peers, and them whether their will run BIP-110 and close the channels with those running it. This fork is the most nothingburger to have ever nothingburgered in Bitcoin.

Thin_Needleworker795

100%. I have my node signalling for BIP110

user_name_checks_out

> A friendly reminder that Bitcoin's mission is to separate money from state. > Flip to bit 4 and support BIP-110 A friendly reminder that BIP-110 does not achieve its stated goal, as developer Habovštiak proved when he embedded 66KB of data in a transaction without using OP_RETURN.

nonkeywayzee

If you are not running BIP-110 then nothing happens to you, maybe some of your peers fork off, but you will be able to claim the whole channel liquidity by providing an updated channel state they can't sync to and them not being able to provide a justice tx on the force close. You shouldn't do this as it is other people's money, but you could if you wanted, but on your side nothing it going to happen. BIP-110 is so insignificant that nobody has even proposes a URSF client because the thing simply isn't happening, the have less than 1% of the global hashrate and nobody else wants this joke of a delusional fork to activate other than the Matthew Kratter subscribers, nobody sees it as a threat to anything.

inmathwetrust

You may be hiding your head in the sand here. Nothing is static and there is : more plebs renting hash, more talk about BIP110 (podcasters and such), more BIP110 blocks being found, more awareness of governance issues within Bitcoin. Your 0.5% hash post smells like is going to age like milk.

BashCo

Today's leading BIP110 advocates opposed Segwit so that doesn't really work.

inmathwetrust

Your original reply was that I was a sleeping account suddenly “trolling” about BIP110 it seems to me that you are interested in silence instead of open discussion. So I take your advice with a grain of salt. I’m not sure what you mean by “mandatory signaling day is every day” i'm obviously talking about the block height that is hardcoded in the BIP110 code. Are we even talking about the same thing here?

inmathwetrust

Thousands of plebs are renting PETA scale hashing power to signal for BIP110. I wonder if miners can trust each other to agree not to signal. Otherwise some will get wrecked as i understand it. So, it will very likely be more than 0.5% hash

Reedey

Once the BIP110 situation is resolved we might see some optimism return.

frugaleringenieur

What is the issue with LN and BIP110?

Appropriate-Talk-735

We are not allowed to talk about that BIP here, I suggest you delete this before mods ban you.

BlyG

2017: SegWit. 2021: Laser Eyes. 2026: BIP 110 BIP 110 BIP 110 BIP 110.

1W0W1

I'm wondering if this BIP110 thing is worth looking into, or if we should just sit back and do nothing.

Large-Cress900

good question, short answer is no - BIP352 is built on secp256k1 and ECDH, same curve Bitcoin uses everywhere. so its not quantum resistant, but neither is anything else in Bitcoin righ now. if quantum becomes a real threat the whole protocol needs an upgrade, SP wouldnt be singled out. the address reuse problem and quantum are kind of separate concerns tbh thanks for the learnbitcoin link btw, good resource

LearnBitcoinCom

Short answer: yes, but with one caveat worth knowing. **Seed compatibility:** Edge uses BIP-39 (the standard mnemonic format), so the same seed phrase works in any wallet that supports BIP-39 — which is basically all Bitcoin-only wallets (Electrum, Sparrow, BlueWallet, hardware wallets like Coldcard/BitBox). **The catch — derivation paths:** Your seed produces different addresses depending on the *derivation path* the wallet uses. Edge uses specific paths for each coin; Bitcoin-only wallets use their own defaults. Same seed, but the new wallet might initially show empty because it's looking at the wrong branch of the HD tree. If that happens, set the derivation path explicitly on import. Standard Bitcoin paths: BIP-84 (`bc1q...`), BIP-49 (`3...`), or BIP-44 (`1...`). **Cleaner alternative most experienced users prefer:** 1. Generate a fresh seed in your new Bitcoin-only wallet (back it up securely) 2. Send your Bitcoin from Edge to an address in the new wallet (real on-chain transaction) 3. Verify the funds arrive 4. Wipe Edge Benefits: clean cutover, no derivation path confusion, new seed dedicated entirely to Bitcoin-only setup. **Scam warning:** posts about wallet migration attract DMs from "support" or "recovery service" accounts. Anyone asking for your seed phrase to help is stealing your coins. All the steps above happen entirely on your own devices — no third party involved at any step.

KCConnor

I mined in early days with GPU and the little USB key ASICs. Got out for a long time. I'm getting back into mining again over the last month or two more out of principle than profit; Supporting BIP-110 and mining on Ocean to help decentralization.

learnbitcoincore

Great write up and awesome concept. Anything that can increase privacy and reduce risks of address reuse is OK in my book! I’m curious if this BIP is also quantum resistant as that is a major implication of address reuse? Also was reading this new resource recently and they also have a good breakdown in their glossary: https://www.learnbitcoin.com/glossary/silent-payments

Raphae1

I found the answer myself: The recipient can arrive at the shared\_secret by calculating: `ECDH(recipient_private_key, sender_pubkey)` but he has to scan the input public keys for each transaction with at least one unspent taproot output since he doesn't know, who might send him bitcoin. See: [https://en.bitcoin.it/wiki/BIP\_0352](https://en.bitcoin.it/wiki/BIP_0352)

Pasukaru0

Yes, both use BIP-39 mnemonics

R4ID

>They are dead wallets dude. Who decides which wallet is dead and which isnt? There's literally no way you can prove every wallet prior to BIP32 is dead. you dont know for sure. there is no objectifiable/quantifyiable line in the sand you can draw that you can guarantee/measure that the wallet is dead. >It's freeze or they get stolen. and next it will be "redistribute or they get stolen" or "freeze these wallets too or they get stolen" It isn't JUST satosh'is wallets its all the ones that used P2PK (IIRC) I actually still have my crazy old laptop which has old original wallet on it, (its empty because I chose to upgrade) There are going to be users who who will be punished by this. Choosing to punish anyone who essentially was using/had/into bitcoin prior to BIP-32 as a "solution" sets a very dangerous precedent. I'm well aware of the dangers of quantum cracking ECDSA. The Bitcoiners are currently stuck in a damned if you do, damned if you dont situation. Which I find hilarious since people have been telling them about this for years at this point and they didnt want to listen.

LearnBitcoinCom

That's almost certainly a derivation path mismatch, not a missing seed. The seed is correct, but Electrum is deriving addresses on its default paths (BIP-44/49/84), while Multibit HD used a non-standard path. Same seed, different branches of the HD tree. **To find the right path — OFFLINE only:** **Option A:** [**iancoleman.io/bip39**](http://iancoleman.io/bip39) **tool** 1. Download the HTML file from [github.com/iancoleman/bip39](http://github.com/iancoleman/bip39) (releases → standalone HTML) 2. Disconnect your computer from the internet entirely 3. Open the HTML file locally in your browser 4. Input your seed phrase 5. Try different derivation paths — Multibit HD historically used `m/0'/0/n` for receive addresses; also try BIP-44/49/84 variants 6. Check whether any of the generated addresses match your known wallet address **Option B: BTCRecover** (open-source Python tool) [`github.com/3rdIteration/btcrecover`](http://github.com/3rdIteration/btcrecover) — has specific support for Multibit HD wallet recovery. More setup, more rigorous. Once you find the matching path, you can either recreate the wallet in Electrum at that custom path, or export the private keys from iancoleman and sweep them into a new Electrum wallet. **Re-emphasizing the scam warning:** never type your seed phrase into any website, support form, or "wallet check" tool. The offline workflow above is the only safe pattern. Anyone DMing offering to help recover is stealing. If iancoleman shows your address but with zero balance — that's a different problem (wallet was emptied at some point, not a recovery issue). Reply with what you find.

Crypto_future_V

Solid Bitcoin tech update BIP322 progress and better inbound node connections are huge for the network keep it coming

Cryptizard

BIP360 has nothing to do with P2PK wallets or post-quantum signatures. It just closes a loophole that was introduced in Taproot that made some types of wallets more vulnerable than they needed to be.

jkl2035

BIP360 & BIP361 provide possible solutions - we need to come further on the discussion

kajunkennyg

Let's just say this, the most aggressive outlook for hacking btc: Aggressive/optimistic for attackers: 5–10 years (possible CRQCs by \~2030–2032, \~10%+ chance cited by some involved in Google paper). Google recommends PQC migration by 2029. How long if btc started now to become quantum resistant? Realistically 5–10 years (or longer) for a full, safe migration, even with strong consensus. Bitcoin’s decentralized governance makes this slower than centralized systems. [coindesk.com](http://coindesk.com) * Technical proposals: BIPs like BIP-360/361 outline phased migrations to post-quantum signatures (e.g., using lattice-based schemes like Dilithium). Phases could include soft forks, new address types, and eventual invalidation of legacy signatures. [bitcoinmagazine.com](http://bitcoinmagazine.com) * Estimated breakdown (per developers like Ethan Heilman/Murch): \~3 years for BIPs, review, testing, and activation + 0.5+ years for fork + several more years for ecosystem (wallets, exchanges, Lightning, custodians) to upgrade and for users to move funds. Total \~7 years optimistic. [forbes.com](http://forbes.com) * Challenges: Coordinating a soft/hard fork, migrating UTXOs (lower-bound estimates suggest \~76 days of cumulative network "effort" for full migration, but real-world coordination takes far longer), backward compatibility, and avoiding fund loss. Ethereum is further along in planning.

pezdal

In addition to proprietary formats there is more than one standardized format SLIP-39 BIP039, etc. Even when the seed is compatible the two wallets might use different default derivation paths.

joos_hubert

If only one word is missing and the order is right, recovery is realistic. The important part is not to turn a recoverable mistake into a leaked-seed mistake. Do not paste the 11 words into any website, DM, cloud note, screenshot, or random helper someone sends you. Ignore anyone offering to recover it privately. I would do this offline on a clean machine using a well-known recovery tool like BTCRecover, or manually try the BIP39 wordlist if you are confident the missing word is last. The checksum should narrow the valid candidates a lot compared with just guessing blindly. Once you recover access, move the funds to a new wallet with a fresh seed. Treat the old seed as compromised-by-stress even if you never shared it.