BIP

AutoModerator

Post is by: babarob98 and the url/text [ ](https://goo.gl/GP6ppk)is: /r/CryptoMarkets/comments/1ukmep7/quantum/ Hi fellow Bitcoiners, I would consider myself a long term holder of BTC. I am not writing this post because “sentiment” is low or anything. I would be writing the same post even if price was at 200k. Down to my point. I don’t see many Bitcoiners worried about the quantum threat. The excuse is always “oh we will do a fork, we’ve done it before” or “Banks and everything will be fucked too”. My concern right now is that, yes a fork is possible, but for the Bitcoin devs to align it could take years… For example the block size war took 4 years and Taproot took 2 years. With Q-Day being around the corner, expected 2030 or even 2029 now. BIP-361 proposes eventually freezing wallets that haven’t migrated to quantum-safe addresses, and that goes against Bitcoin’s most sacred principle “immutability” and no central control. That debate alone could slow the entire upgrade process for years while the clock ticks. And it’s not just a technical problem, it’s also a philosophical civil war waiting to happen. I am concerned about OG Bitcoiners and devs not being worried about and working on this subject enough. In my opinion we might not make it on time if it takes years to align on simple subjects, let alone this one which questions the core principles of BTC. What are your thoughts on that? *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/CryptoMarkets) if you have any questions or concerns.*

TheresNoSecondBest

>It will only create 2 separate chains if the BIP-110 chain has less hashpower According to signaling, the 110 duct tape has less than 0.5% power.

DavidKens

This is the definition of a soft fork: https://www.investopedia.com/terms/s/soft-fork.asp Old nodes will accept blocks made on BIP-110, but old nodes don’t know how to do BIP-110 validations. This means the miners not running BIP-110 are able to make blocks that BIP-110 nodes would not accept. All soft forks work this way.

reactNativeNoob

I agree that miners will mine on the main chain, I just think they will enforce the BIP 110 rules since that is the path of least resistance

DavidKens

This is the definition of a soft fork https://www.investopedia.com/terms/s/soft-fork.asp Nodes do not need to update in order to accept the new blocks. You are correct that if miners keep creating old blocks, those would not be accepted by nodes on BIP-110. All soft forks work this way.

DarrelXero

Learn about BIP110 softfork signaling & activation: https://bip110.orange.surf/

AlabamaHotPocketses

Can’t they avoid potentially “mining worthless blocks” by only mining blocks that 100% of the network will accept? i.e., BIP110 valid blocks?

reactNativeNoob

BIP 110 is not forking off by default.  It's blocks are compatible with all existing nodes.  The choice will end up being given to the miners as to whether or not to split the network in order to save 0.1% of their revenue for a single year.   Just don't see it

reactNativeNoob

It will only create 2 separate chains if the BIP-110 chain has less hashpower.  If BIP-110 has more hashpower, the other chain will immediately accept it by default (since it's blocks are still valid on the other chain) and will overwrite the other chain.

NiagaraBTC

Every mined block will be on the main chain. Not every mined block will be on the BIP-110 chain. There will be a fork. 110-coin will be worthless. Miners don't want to spend energy mining worthless blocks. It's that simple.

Easy-Ninja669

That's an appeal to authority, not fact. I've done my own research and come to my own conclusion that BIP 110 is the right direction. 

Realistic_Fee_00001

>You have to expose yourself to an exchange rate risk to make use of BCH features. That makes no sense to me. Have you used BCH? What exchange rate risk are you talking about? BTC/BCH or BCH/USD? You can use BCH directly there is no difference to any other crypto. >Also there are now many BTC holders who have no current exposure to BCH. If they stop to suppress BCH or endorse it, capital will flow from BTC to BCH and they lose value. Yes, BCH has a lot of upside potential. >A low feature, small blocksize (small hardware requirement) coin has real advantages. Resilience to attack and centralization. Again, makes no sense. It isn't even correct. Ask BIP-110 proponents how they feel about Core hogging the code of the single node repository. BTC is very centralized in development. >In my opinion BCH and BTC complement each other and everything would be smoother if their combined supply was 21 million coins. They don't, BCH can do everything BTC can. Once BCH is recognized as the better working Bitcoin there is no reason why it should not also be recognized as the better SoV. That's why they fight it so fiercely. >PS: One advantage of the small block argument is that the whole blockchain has to be downloaded to run a full node. I don't believe that is true. Then why are you parroting their false claims? > If BTC was to make regular snapshots (7 days apart for example) of the UTXO database and then include cryptographic hashes of those snapshots in each live block, then >(1) the hashes must be the same for the same most recent snapshot, a consensus would be established >(2) it makes downloading the snapshot possible >This weakens the argument for the necessity for small blocks. Exactly, BCH is already researching these. https://bitcoincashresearch.org/t/chip-2021-07-utxo-fastsync/502/86 https://bitcoincashresearch.org/t/chip-2025-03-merkle-header-commitment-for-enhanced-spv-scalability/1518

CompetitionDouble420

Meanwhile, I'll continue mining BTC quietly in the background while watching the retail guys quarrel over MSTR/STRC and BIP110 🤙🏼

user_name_checks_out

> It does. Your opinion doesn't change facts. Someone more informed than I has laid out the arguments against BIP110 [here](https://old.reddit.com/r/Bitcoin/comments/1uhzk8o/bip_110_thoughts/ouc88b1/). Those are not opinions, they are facts.

user_name_checks_out

Your two reasons, BIP110 succeeds in addressing neither of them.

user_name_checks_out

> BIP-110 configures your node to reign in *rein [Reign vs. Rein: What’s The Difference?](https://www.dictionary.com/articles/reign-vs-rein)

TheresNoSecondBest

>I’m glad we agree on that at least. The vast majority of bitcoiners IMHO do. And **finding the correct solution should be a priority**. Not trying to push something that isn't working and could potentially make more damage. >Personally I don’t see how not fixing the taproot exploit or blowing open OP\_Return default policies is making spammers life difficult, quite the opposite Implementing Bip110 would make our lives more difficult. That's the issue. The spammers will need to use multiple TXs, using even more block space, growing the size of the chain even faster. >So enter BIP-110 as pushback. Like it or not the growth of Knots is significant. It’s like 30%+ active nodes and 40/60 knots to core ratio of new nodes in the last year or something like that. I like how the same people running multiple knots nodes tried to rest hash and fake the miners support too, and reaching 0.8% signaling support, which obviously dropped the following period because it's much more expensive than the node Sybil attack they are running. Now back under 0.5% support. You know the node numbers are fake, why bringing that to the conversation?

bitusher

>Start9 That is a small fringe bitcoin company and one of many selling ready made nodes. If that is your example of the largest economic merchant than that is a very poor example. What do you assume their yearly revenue is ? >Several prominent figures in the Bitcoin social media space are backing it (Kratter/Mechanic/Simply Bitcoin). People with 100s of thousands of followers and millions of views combined. More social media influencers who have more viewers are either nuetral or opposed to BIP110 by a long shot. There is so little support from companies that they are having to lie and just make up a fake list filled with misinformation https://x.com/i/status/2071017378536648993 https://x.com/SuperTestnet/status/2071078883768582185 and worded in a way that is misleading >sure, but it’s not nothing. Agreed , there are real users that support BIP110 . No one is denying that but this come back to my original question .... Should 15% of nodes be able to coerce the remaining nodes with threats of a reorg to get their way ? Do you believe that is justified?

FieryButPeaceful09

12,000 nodes and companies like Start9, one of the largest companies selling retail ready make node servers are publicly backing BIP-110. Several prominent figures in the Bitcoin social media space are backing it (Kratter/Mechanic/Simply Bitcoin). People with 100s of thousands of followers and millions of views combined. It’s not everybody or even a majority, sure, but it’s not nothing.

7ivor

BIP110 breaks scaling solutions while failing to block spam, if anything it just pushes people to more harmful versions. Spam sucks, but BIP110 is a poorly written and shortsighted response. [Here's a list of multiple posts explaining various technical issues.](https://x.com/i/status/2030310642306232639) [Here's a good thread from that list explaining specific technical issues about how it negatively impacts scaling and fails to prevent spam.](https://x.com/i/status/2020594400955695442)

bitusher

>You seem to be of the understanding that larger miners are in control of the network. No , I agree with the reality that economic nodes have more control than miners which is why I worked with Luke and others with UASF148 There really just isn't a lot of economic support for BIP110 either >The nodes are the soul of the network and right now approximately 15% Again , you can't weigh all nodes the same , especially when a speculation attack occurs. This is all very old lessons from the blocksize wars

Search327

All I here from people against it are " it sucks"! Please explain! From what I understand it sounds like the BIP 110 intent is to remove spam data from transactions.

bitusher

> Still I think the original statement “zero large economic node support” is not accurate given I never suggested this but I see you are referring to someone else. It does beg the question what is an example of the largest economic support they have ? Perhaps "Ocean" ? That running Datum doesn't exclusively support BIP110 though. Do you have another example of a large exchange, merchant , pool , merchant processor , or hodler that supports BIP110 ? The largest I can think of is a very small mining farm like barefoot mining. >with those kind of numbers there is not an insignificant level of support. Should 15% of nodes be able to coerce the remaining nodes with threats of a reorg to get their way ? Do you believe that is justified? >have been activist censoring/banning this topic, creating an echo chamber and perhaps giving you the false censorship excuse is moot because we have been discussing/debating this topic of spam since 2011 and op_return since 2014 an naseum . Even in subs like this that are famous for moderation/censorship (in this case it would be justified because its clear that luke will likely create a altcoin with a hard fork soon ) have allowed many BIP110 posts occur over and over again.

FieryButPeaceful09

Generally I don’t disagree with most of what you’re saying. Still I think the point the statement “zero large economic node support” is not accurate given the uptake of BIP-110 signalling. Whether 20 or 50% of the \~12,000 nodes signalling for it today are economic, or pass whatever sniff test you want to impose, the fact is with those kind of numbers there is not an insignificant level of support. Kratter/Mechanic and co have reached a fair amount of bitcoiners whether you like it or not. And yes I realise that the overall % of Bitcoiners is small, but we’re talking about node runners here’s Places like this Reddit community have been activist censoring/banning this topic, creating an echo chamber and perhaps giving you the false sense of a lack of grassroot support for the proposal. I’m actually surprised this thread is still open.

bitusher

> what you’re saying is BIP148 had wider support in premise but not at the technical detail level. No , segwit had wide support as a whole but some businesses/miners wanted more , segwit + more weight, hence segwit2x >Sounds a lot like the situation now where almost everybody agrees spam=bad but disagrees about how to fix it. This is not a new topic. We have been debating/discussing spam since 2011 and op_return since 2014 >Growth of the BIP-110 nodes to 12,000 looks pretty organic to me, many examples of unnatural amount of peers on the same subnet like https://x.com/GhostofMapl/status/2024620340047978612 and multiple examples of sybil spikes in general https://x.com/w_s_bitcoin/status/2045657562419224651 To be fair , plenty of non economic nodes exist running Bitcoin core as well. Which is precisely why developers reached out directly to exchanges , merchants , wallets , merchant processors directly to try and get a rough idea of consensus before attempting to activate segwit . BIP110 mainly relies only on node count instead and there is not any good evidence there is a lot of UTXOs or transaction activity behind those BIP110 nodes. If anything from my conversations of BIP110 users and the way nodes are being promoted they often are treating as a way to "vote" instead of sending and receiving all their UTXOs. I have no idea whether its 20%, 40%, or 80% of the nodes are sybil nodes. It also depends how you define a sybil node too because There is good evidence that many BIP110 supporters are simply spinning up non economic full nodes to "vote" which some would call a type of sybil node. IMHO, I imagine there might be less than 10-20% of these full nodes that are economic (sending and receiving UTXOs) >We’re at what now 15% of the network or something and growing every day. Even if you assume that all 15% are not sybil (good evidence reflects otherwise) and are all are economic (good evidence suggests otherwise) , 15% of node count does not mean 15% of Bitcoin users. This is because most Bitcoin users do not run their own full node so a political movement of a passionate minority can spin up a bunch of nodes to make it seem like they represent a larger part of the Bitcoin ecosystem than they actually represent.

FieryButPeaceful09

How is patching the taproot exploit and putting the lid back on OP\_Return going to “gimp” Bitcoin? Luke is not in control of the network, it’s a temporary soft fork merge request that every open source project is open to. And he didn’t even make the BIP it was Dathan Ohm. Or wait you only think Core or other approved person can make changes? Sounds like an authoritarian take to me.

FieryButPeaceful09

So what you’re saying is BIP148 had wider support in premise but not at the technical detail level. Sounds a lot like the situation now where almost everybody agrees spam=bad but disagrees about how to fix it. Growth of the BIP-110 nodes to 12,000 looks pretty organic to me, I see no huge jumps in the numbers in say 1 day or from one actor. We’re at what now 15% of the network or something and growing every day.

bitusher

There is a big difference because BIP148 was only one of many implementations supporting segwit. Core and all the other common implementations supported segwit. The only dispute was around adding more blockweight in addition to segwit , thus segwit2x . The group of people that really opposed segwit where 20-100 people following Mircea Popescu and they opposed all changes . Most the bikeshedding of hf vs sf to increase the blocksize mainly came later and wasn't directly related to opposing segwit itself This is completely different than BIP110 which has a small fraction of 1% support of Bitcoin users

bitusher

I personally hate spam but this proposal does not help. BIP110 supporters often don't seem to understand how many ways there exists to hide spam on Bitcoin unless you make Bitcoin a centralized permissioned ledger. Than they use this fact to suggest we are apathetic or we like spam which is untrue because there are effective ways to reduce spam that don't have all these consequences. I have always hated nfts, spam, inscriptions , and ordinals, just like many developers do. Even hated when luke was spamming bible verses in the blockchain (location does not matter as adding data in the coinbase does increase tx and blocksize just the same) Here are 3 solutions : The best solution as I often promote is to spend and replace Bitcoin as money. This is best done on other layers like lightning that use much less blockspace, but the more people that open and close channels the higher the fees exist for spammers which will encourage them to use altcoins instead for their spam. Yes , more l2 txs reduce onchain use which is why a large focus should be on adoption overall to increase both L2 and onchain transactions concurrently. The second best solution is education which I have been doing for many years where I inform people that nfts/inscriptions are scams and don't do what people claim they do and are a waste of time. A third solution is we invest more in bitcoin and bitcoin adoption which raises the price of Bitcoin and since fees are priced in BTC onchain fees will grow as well pricing out spammers . Those are 3 quick solutions among many more that I actively am involved in. Suggesting solutions that don't work at all or have very harmful tradeoffs is not effective. This being said I completely support your right to enforce any rules you want on your node and even fork off. Power to the node operators. Just do so with your eyes open.

bitusher

u/ajr1788 What BIP110 is trying to do is much different as explained in this summary: https://x.com/theonevortex/status/2020594400955695442 -Protocol/Ledger neutrality - By moving "Standardness" filters into "Consensus" rules Bitcoin ceases to be a neutral settlement layer and starts looking like a curated platform and this sets a precedent where a 55% majority can decide that your valid transaction is "spam" simply because they dislike the use case -It doesn't actually solve the problem - As Peter Todd demonstrated these filters are easily bypassed as he successfully embedded the entire 6,000-word text of BIP 110 into a single transaction by fragmenting the data across multiple 256-byte PUSHDATA elements and 83-byte OP_RETURNs so this proves the fork doesn't stop data it only increases the transaction fee "tax" for users -Incentivizes Centralizing BlockSpace Market - Capping the public relay at 83 bytes forces high-volume data users to bypass the P2P network and instead pay large mining pools directly via private APIs to include "illegal" non-standard data which creates a private blockspace market that small home-node miners cannot see or profit from -Risk of confiscation / disruption to backwards compatibility - As Gregory Maxwell noted Bitcoin nodes have no "global state" of pre-signed transactions so if a user has a multi-year inheritance plan or a "Vault" emergency exit signed offline that uses a 500-byte script or an OP_IF branch BIP 110 welds that exit shut and since the transaction is now consensus-invalid the funds are effectively confiscated for the duration of the fork -Anti-Scaling (Kills eltoo/ln-symmetry) - BIP 110 explicitly invalidates the Taproot Annex which directly blocks the ln-symmetry upgrade which is the industry's best hope for a Lightning Network that dramatically reduces the need for constant watchtower monitoring and enables simpler multi-party channels -Creates UTXO bloat - BIP 110 incentivizes spammers to hide data inside fake addresses/UTXOs (like multisig-encoded data) and while an OP_RETURN can be ignored by a lean node, a fake UTXO must be tracked by every node forever so BIP 110 intended to "save" nodes but actually creates a more expensive permanent burden on them -Breaks Miniscript & Vaults - Miniscript is the industry standard for writing readable secure smart contracts (used for inheritance, multi-party escrow, timelocked recovery) and relies heavily on OP_IF to branch between conditions so by banning OP_IF in Tapscripts BIP 110 effectively breaks Taproot-based custody setups that represent the direction the entire industry is moving -Lobotomizes BitVM - BitVM is one of very few viable paths to trustless Layer 2 bridges and requires deep "Taproot Trees" (Merkle paths) to verify computation and a 257-byte limit caps the tree depth at roughly 7 levels (128 leaves) when BitVM protocols often require thousands of leaves to function -Loss in fees for miners - If you filter out the highest paying transactions because you don't like their content you are effectively asking miners to take a pay cut which could lower the "hash price" and as block subsidy continues to halve transaction fees become increasingly critical to security -Rushed Timeline / Governance Precedent - BIP 110 activates unconditionally by September 2026 regardless of support with early activation possible at just 55% signaling within a tiny 3-month window and this "emergency" style of governance is a radical departure from Bitcoin's traditional 90%+ consensus model, if rushed "emergency" consensus changes become normalized that governance precedent is permanent even if the technical changes expire ------------ "We need to stop data on bitcoin because there could be viruses and grandma could get infected!" But on-chain data just sits there as inert bytes that no node ever executes, and bitcoin isn't a file network, so there's no path by which verifying the chain runs or installs anything. "We need to stop all spam on bitcoin!" But you can't prevent arbitrary data from being embedded, and the BIP itself admits this because it says all you do is force people to disguise the data as financial data or break it into multiple pushes. "We need to slow down spam on bitcoin!" But 110 doesn't stop spam and the authors concede that, so all it really does is pick which data survives, because it restores the 83 byte OP_RETURN limit that Runes already fit inside while it guts inscriptions. "We need to make it harder for spammers to spam on bitcoin!" But forcing data off OP_RETURN and into disguised outputs can make the footprint worse, because provably unspendable OP_RETURN can be pruned while disguised script data sticks around and bloats what every node has to keep. "We need to signal to spammers that we don't want spam on bitcoin!" But arbitrary data has been on bitcoin since the genesis block when Satoshi embedded the Times headline about the bank bailout. "But spam is bad and bitcoin is money!" But we already knew and agree spam sucks and that bitcoin was money because it has a price ticker, and that's been the main use case to date.

bitusher

The MASF of BIP110 looks like a total failure https://wickedsmartbitcoin.com/bip110_signaling which is dropping from 0.8% to 0.4 % and now at 0.1% so far this period and it was clear they are even renting hashrate to boost those numbers. You must mean to possibly indicate a UAHF with a PoW change that Luke keeps mentioning creating some obscure altcoin mined with gpus with low security that can be attacked by botnets and small gpus farms ?

FieryButPeaceful09

How many nodes signalled for BIP-148? Do you even run a node?

PublikStatik

Yeah, the quantum threat is real. And I agree that AI will supercharge the speed of new discoveries.  Given that we’re dealing with a blockchain, it is critical that the right BIPs are implemented to allow for migrations to quantum secure addresses. There have already been proposals. But I think the consensus is we dont want to introduce the BIP too early before post quantum cryptography standards have started to form — or too late for people to start migrating their wallets. Especially with Bitcoin, I invest what I can afford to lose. And I know there is a lot of interest in not seeing the network implode. But it’ll be a wild ride the next few years. I’m excited to watch this story play out.

Prestigious-Buddy539

BIP110 dead chain incoming. These retards are going to fork themselves off into oblivion. ZERO pool support and zero large economic node support.

7ivor

It's an IQ test. Anyone for BIP110 has failed the test and doesn't actually understand how bitcoin works. Especially the ones claiming it's going to succeed if people don't run a URSF. Just a complete lack of understanding of how blocks are added to the chain and how forks would resolve.

CloudLeading1502

There are dozens of similar projects that were well-intentioned and resulted in loss of funds and I'm concerned that you used an LLM to reply to my initial comment, which to me signals that you aren't interested in a serious discussion. I would urge anyone coming across such projects to instead look at established, widely-used, reproducible tools such as a hardware wallet, Ian Coleman's BIP39 tool (offline), or SeedTool to name a few. "I reviewed it and it looks correct" is not a strong enough standard, and the bar for trusting any single unaudited generator with your savings is "DON'T"!

Large-Cress900

Ian Coleman's BIP39 tool is a great project and has been around for years. I'm not trying to replace it or suggest this is a better alternative. This started as a personal project that I decided to rewrite from scratch because I wasn't happy with the original implementation anymore. My focus was on an offline mnemonic generator with optional supplemental entropy, built-in self-tests and code that's easy to inspect and review. As for the "vibe coded" comment, I don't think that's a technical criticism. Whether AI was involved somewhere during development doesn't determine whether software is correct or secure. If you see a design flaw, a cryptographic mistake or an implementation bug, please point it out. That's exactly why I shared the project here. I'd much rather discuss concrete technical issues than labels.

user_name_checks_out

> Silent Payments (BIP352), JoinMarket-NG, Taproot channels on LND — I see that em dash. Hello ChatGPT. > Which part feels like 2014 to you? Genuinely curious. [link](https://old.reddit.com/r/Bitcoin/comments/1uh1qbe/your_bitcoin_is_being_watched_how_chain_analysis/ou5e5mk/): > Your ChatGPT generated article says that Samourai Whirlpool is one of the three main CoinJoin implementations in 2026 but Samourai closed down in early 2024. > Your ChatGPT gnerated article says that Wasabi Wallet uses a centralized zkSNACKs coordinator but the zkSNACKs coordinator actually shut down in the summer of 2024 and users have been able to manually choose what coordinator they wish to use since then. > Your ChatGPT generated article doesn't even mention Ginger Wallet which launched in the summer of 2024, has a built in CoinJoin implementation and is still operating in 2026.

Large-Cress900

Silent Payments (BIP352), JoinMarket-NG, Taproot channels on LND — all 2025-2026. Which part feels like 2014 to you? Genuinely curious.

Large-Cress900

Not AI generated — I run a full LND node and wrote this from real experience. "Not up to date" — what specifically? JoinMarket-NG (HRF funded Q1 2026), Silent Payments BIP352 live on Sparrow and Cake Wallet, Wasabi 2.x with zkSNACKs coordinator — all current. Tell me what's outdated and I'll address it.

coindigest

Solid writeup, but it's selling the timeline way harder than the tech supports. The keystone of this whole thesis, OP\_CAT, isn't live. It's BIP-347 and it's been stuck for years with no broad consensus and not even a scheduled activation attempt. As of mid-2026 literally zero soft forks have reached deployment since Taproot in 2021. So "natively trustless settlement engine" is a roadmap, not a description of what exists today. Where the post is actually right: BitVM2 is real and in production, Citrea's Clementine bridge went live on mainnet back in January. Credit there. But calling it "trustless" glosses over the catch: BitVM2's security rests on dispute economics. Challenges get paid in Bitcoin blockspace, so if fees spike during a challenge window an honest challenger can get priced out, which is exactly why these setups lean on overcollateralization and watchtower services. That's a genuine unsolved tradeoff, not a finished trustless system. The irony is that a post opening with "strip away the marketing noise" and then declaring the "cryptographic death of altcoins" is itself the marketing. The direction is legit and Bitcoin programmability is genuinely moving forward, but the altcoin-scaling-is-dead victory lap is years early and hinges on a soft fork that might never get consensus.

Appropriate-Talk-735

Thanks for posting. Will it work with BIP-110 also?

DarrelXero

Correct, the biggest supporter, and most likely creator, of BIP110 does not signal for BIP110 in the blocks for the templates they provide outside of DATUM users. But in order to run a DATUM gateway it requires a knots node. And even if you just point your hashrate at Ocean and use their templates you are being served templates through a knots node. Thus, if you use Ocean you are supporting knots. That's not a decision that should be forced on anyone.

Aggravating-Map-293

BIP-110

Mooks79

So? BIP39 is public, as are the list of words, of course it can.

kirovreported

How cleverly a two-day-old redditor smeared BIP-110 and Ocean, mentioning their alleged connection to KYC.

SaltyProfession2020

Récupération Seed Phrase 1-3 mots manquants (4x H100) Service professionnel de brute-force sur seed BIP39. No recovery = No fee. Spécialisé dans les cas où il manque 1, 2 ou 3 mots. Matériel puissant → résultats rapides. Contactez-moi en MP si vous avez une seed partielle + adresse du wallet. Seulement les cas sérieux.

BryantNielson-QCI

The important development here is real, but the framing is overheated. The White House order sets federal migration deadlines for high-value systems. It does not declare that a cryptographically relevant quantum computer will arrive by 2030. The dates reflect long migration lead times, sensitive data lifecycles and the cost of replacing legacy systems. Bitcoin developers are also working on the problem, but BIP-360 and BIP-361 are proposals, not deployed protections. BIP-360 introduces a possible quantum-resistant output structure. BIP-361 proposes a phased sunset of vulnerable ECDSA and Schnorr outputs after a post-quantum path exists. Neither has network-wide activation or consensus today. The 34% figure should be described carefully too. It refers to coins associated with revealed public keys under a particular counting method. It does not mean 34% of Bitcoin can be stolen today, and it does not prove that all of those coins are lost or attributable to Satoshi. So the real story is less cinematic: The government has accelerated its migration timetable. Bitcoin now has serious migration proposals. The unresolved issue is whether the network can agree on how to protect active users without creating an ownership crisis around dormant coins. That is significant enough without calling it panic or pretending the code is already live.

sylsau

The U.S. Government just declared a hard 2030 deadline to migrate federal systems to post-quantum cryptography. The "harvest-now, decrypt-later" threat is no longer theoretical. The state is panicking. But guess what? Bitcoin devs have been shipping code to fight this since February. BIP-360 and BIP-361 are already live in the repository, leveraging the exact same NIST-approved primitives the White House is now scrambling to mandate. The cypherpunks didn't wait for a presidential directive. But with 34% of the total BTC supply sitting in quantum-vulnerable legacy addresses—including Satoshi’s 1.7M coin stash—the clock is ticking. Bitcoin doesn't have a CEO. It has a consensus problem. Do we freeze the ancient coins to save the network, or do we let the quantum wolves hunt? The ultimate boss battle of decentralized governance has officially begun. Are your sats safe? 🧵👇

FieryButPeaceful09

How is patching 2-3 known spam attack vectors but the possibility of there still be 1 spam attack vector (which is valid with both BIP-110 and non BIP-110 rules btw) painting the door red? And you didn’t answer your question, what is your proposal? Sounds like the nihilistic appeal to technical authority with zero substance we’ve all come to expect from the spam apologists. Trouble is it doesn’t work when your held to account. Care to explain how’s this damage would come about that I can’t probably comprehend? Or is linking to that article your entire argument? Outstanding impudence. Think we’ve found a spammer.

BaldBear_13

Lol. Proper post-quantum solution will be implemented across entire Bitcoin network as a new BIP, it will take couple years to get everybody to agree on the a specific solution, and then another few months for hardware makers to release a firmware upgrade, which you should download directly from their website.

__Ken_Adams__

When you import a non-Electrum seed into Electrum you have to choose the option to tell it you're importing a BIP39 seed instead of an Electrum seed.

whatwilly0ubuild

Bagpipe in the wordlist plus your phrase getting rejected by Metamask and Electrum points hard at Monero. Monero doesn't use BIP39, it uses its own 25 word mnemonic where the 25th word is a checksum of the other 24, which is exactly why BIP39 tools spit it back at you. If it's 13 words it's the older short Monero scheme, same idea. To check, grab the official Monero GUI or CLI, choose restore wallet from seed, and paste it in. If the checksum word is valid it'll accept it immediately, and that alone confirms what you've got. Then it has to scan the chain to find your balance, so set a restore height around when you think you made it to save yourself a multi hour sync, or set it low and let it grind if you have no clue. The old wallet still works fine despite all the hard forks since, the seed math didn't change. One thing I'll be blunt about, do not type that phrase into any seed checker or wallet finder website, ever. Those things exist to drain exactly this situation, someone finding an old seed and pasting it somewhere to see what it is. Download the official binaries, verify the hashes, and ideally do the restore on a machine that's offline for the check. If there's anything on that wallet, the website crowd will empty it before you finish reading their results page. Worst case it's a few bucks of old crypto, best case the chain scan surprises you, but either way keep the damn seed off random sites.

nonkeywayzee

What makes you believe they care about this thing working? This whole BIP is a fight for identity, it has never been a technical thing, it is about how they feel about other people using freedom money in ways they don't like.

bitusher

> Your example shows that BIP110 makes the spam larger and as a result, more expensive. More expensive and far more damaging to the network than spam in OP_Return. Some spammers will always spam Bitcoin because we are the most secure blockchain that has good transaction finality and will likely still be around in many years unlike altcoins that pump and dump. Additionally, others will always spam Bitcoin regardless the price as an attack on the network. So spam is inevitable and cannot be stopped . The question is do we reduce spam by simply using Bitcoin more as money (what I prefer) or with these band aids that barely work as a deterrence and simply encourage more harmful forms of spam

bitusher

> BIP110 reduces spam. It doesn't remove the worst kine and most prevalent form of spam called Runes, additionally it will just as easily make much worse spam if it ever gets adopted , which will never happen

AlabamaHotPocketses

Admittedly, yes I was a bit quick on the draw with that comment, adding no value at all, so let respond properly this time round. Firstly, sounds like you are saying shouldn’t close or raise the cost of existing methods because new ones might be found? I don’t think that’s a reason to do nothing, by that logic you never patch anything. Surely raising the cost of cheap, high-volume paths is a win? The fact that a determined dev can still hand-craft one image doesn’t change that. Secondly, I think the example you provided can be interpreted as evidence in support of BIP110. Your example shows that BIP110 makes the spam larger and as a result, more expensive. If spam demand responds to price at all, then more expensive means less of it. You are demonstrating that the deterrent works. Unless you are implying that spammers are price insensitive and will pay at any cost forever.

Pasukaru0

BIP110 doesn't reduce spam. If anything, it will only divert it to other mechanisms. If somebody wants to upload CSAM they can and will do so regardless of BIP110.

AlabamaHotPocketses

No we can’t remove the spam already on the chain, but that doesn’t mean we can’t reduce it going forward. If there is less spam the storage requirements grow slower, good for node runners, good for de-centralization. BIP110 reduces spam.

Ecstatic-Mulberry-98

I'm based in france and I have to say I'm not feeling safe about that, even If i'm very discreet about my interest in crypto. I'm making an open-source app (https://github.com/Caltanjun/timelocked) to help me, and hopefully others, to sleep better. It allows to easily time-lock assets. The idea is to timelock a BIP-39 passphrase, for your long term cold storage, using local and offline timelock puzzles. Basicaly it encrypts data and non-parallelizable CPU time is needed to decrypt.

nonkeywayzee

This is how we all know that you guys have idea how Bitcoin works. It is a soft-fork yes, but only nodes signaling for it will mine on top of the signaling blocks (if there's any at all) after obligatory signaling, and the rest of the network, which is way greater than BIP-110 nodes, will simply accept their blocks if valid, but they will also mine non-signaling blocks.

96933287275978

BIP‑110 is a temporary soft fork, not a hard fork that splits Bitcoin. It activates either by miner signaling (55% in a 2016‑block period) or unconditionally at block 965,664 (\~September 2026), not before August 7. It’s also designed to auto‑expire about a year after activation, so it can’t coexist permanently like SegWit.

TheresNoSecondBest

>That’s not how this works. A BIP-110 soft fork would change network rules They will either, self-fork (hardfork) out of Bitcoin or the whole proposal will fail to activate before August 7th. Bip110 cannot exist in parallel like Segwit for example. That's at least how I see it and why I'm not joining their camp. They're just making drama and attacking Bitcoin instead of trying to work together and change it for better. The vast majority of Bitcoin HODLers don't like NFTs, runes and other crap, and would be more than happy to get rid of them. But bip110 simply isn't the correct way, IMHO. >not require ordinary BTC holders to exchange or move their coins. There’s no need for hodlers to do anything. Agreed. Bitcoin HODLers won't need to do anything, no matter if it's a soft or hard fork.

96933287275978

That’s not how this works. You clearly don’t understand what you are talking about. A BIP-110 fork would affect network rules. BIP-110 is a soft fork, so ordinary BTC holders do not need to take any action to keep their coins.

statoshi

That's not a bet because you lose nothing when you're proven wrong. You'll just spend a couple minutes switching your node software back to non-BIP110 code so that the chain continues to sync.

statoshi

Everyone who listens to Mechanic is going to get rekt in August. Mark my words. If you think I'm wrong, I urge you to engage in a trustless fork futures bet with me. I've been making this offer for 4 months but nary a BIP-110 supporter will take me up on it.

More-Tear-5568

21] [ 13] [ 12] [ 28] [ 29] [ 5] [ 4] <- Row 0 (Codes 1-8) [ 26] [ 27] [ 7] [ 6] [ 22] [ 23] [ 11] [ 10] <- Row 1 (Codes 9-16) [ 14] [ 15] [ 19] [ 18] [ 2] [ 3] [ 31] [ 30] <- Row 2 (Codes 17-24) [ 8] [ 9] [ 25] [ 24] [ 16] [ 17] [ 1] [ 32] <- Row 3 (Codes 25-32) [ 52] [ 53] [ 45] [ 44] [ 60] [ 61] [ 37] [ 36] <- Row 4 (Codes 33-40) [ 58] [ 59] [ 39] [ 38] [ 54] [ 55] [ 43] [ 42] <- Row 5 (Codes 41-48) [ 46] [ 47] [ 51] [ 50] [ 34] [ 35] [ 63] [ 62] <- Row 6 (Codes 49-56) [ 40] [ 41] [ 57] [ 56] [ 48] [ 49] [ 33] [ 64] The main shore woman proposed the people of Danli Road to live in knife fight Bai Yu attacked and killed the East type country rich not 64 middle blood book Taiwan ah 89 people Russian Taiwan group for main woman people live knife country rich middle blood book group this is the best I could do don't really understand how to solve got this but it says it's invalid UNLOCKED BIP-39 WALLET PASSPHRASE SEED --- Word 01: abstract (From Code C=1) Word 02: addict (From Code C=9) Word 03: absent (From Code C=17) Word 04: adjust (From Code C=25) Word 05: accuse (From Code C=33) Word 06: action (From Code C=41) Word 07: amount (From Code C=49) Word 08: alert (From Code C=57) Word 09: add (From Code C=2) Word 10: absurd (From Code C=10) Word 11: advance (From Code C=18) Word 12: able (From Code C=26) Word 13: act (From Code C=34) Word 14: achieve (From Code C=42) Word 15: accident (From Code C=50) Word 16: actress (From Code C=58) Word 17: agent (From Code C=3) Word 18: also (From Code C=11) Word 19: again (From Code C=19) Word 20: always (From Code C=27) Word 21: aisle (From Code C=35) Word 22: alley (From Code C=43) Word 23: ability (From Code C=51) Word 24: acoustic (From Code C=59) Complete Seed Phrase for Wallet Import: abstract addict absent adjust accuse action amount alert add absurd advance able act achieve accident actress agent also again always aisle alley ability acoustic if I figure out anything else I'll post it but still don't understand what to do with any of still kind of new to the whole cryptography stuff

TheresNoSecondBest

**Strange coincidence**. 99% of pro-BIP110 posts are created by a zombie account. OP was sleeping for a couple of years. Also, none of the posters ever explained what u/user_name_checks_out/ mentioned: >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. Makes me wonder why in both cases.

lifeanon269

BIP-110 will end up being a hard fork. https://blog.lopp.net/a-laymans-guide-to-bip-110/ https://jlopp.github.io/knotzi-death-march/

TheresNoSecondBest

Sorry, I always had Green on Android, just learned on iOS it gave the 27 words option too. Not sure if Bluewallet will recover then. Let's go back to Blockstream then. Find what derivation path is your current setup using. You're looking for something that looks like: m/42'/0'/69' The most common paths: The most common derivation paths used in Bitcoin are: BIP 44: m/44'/0'/0' (1addresses) BIP 49: m/49'/0'/0' (3addresses) BIP 84: m/84'/0'/0' (bc1qaddresses) BIP 86: m/86'/0'/0' (bc1paddresses)

Sacredwisp

I agree that something should be done about it sooner rather than later. There are several people working on proposals, but they are not really be talked about all that much at the moment. I think the conversation should be taken more seriously, because getting consensus could take a year or two, and if the method chosen requires coins to be migrated to new addresses, that could take another few years. I know at least one fork (BIP-322) could address the quantum threat without having to migrate coins, but I have not really looked into the technicals of any of the proposals (or really have the knowledge to properly evaluate them, tbh). That said, from my very limited understanding, quantum computers have been increasing in physical qbits, not logical ones. There's too much error. The largest number factored using quantum to this day with Shor's algorithm is still 21, and there may have been fuckery for that even then. From my understanding, the methods where they factored more, they used quantum as basically being an extremely expensive random number generator. There could always be a breakthrough, but for now, I think we're still safe.

crunchyeyeball

Are you sure it's 27 words? If so, it may be related to this: https://help.blockstream.com/blockstream-app/troubleshooting/fix-issues-with-recovery-phrase-entry > The Password protected option is only used for 27-word recovery phrases. If you do not have a 27-word recovery phrase and enable this option, you will receive the "Invalid Recovery Phrase" error. In any case, taking a photo of your seed phrase is not a good idea. If you recover your funds, I'd suggest you consider moving them to a new wallet which supports the BIP39 industry standard (12 or 24 words) or SLIP39 (20 words), and *only* record your seed phrase on paper or metal plates, *never* digitally. If you have enough to justify the cost, get a hardware wallet, and follow the instructions it comes with regarding seed phrase security and recovery options.

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.