Hey Willy, you are spot on! Actually, a few days ago, before you posted your first thread talking about quantum computers and Bitcoin, I started introducing the subject myself with similar concerns about the timeline and urgency of this threat.* We came to the exact same solution you're proposing with HD wallets! Before diving into solutions, let me address the timeline skepticism that was raised. Yes, quantum advantages are often overhyped, and Scott Aaronson provides valuable reality checks. But the Bitcoin developers aren't reacting to press releases. They're watching actual hardware. IBM has 433-qubit systems running commercially today, not in labs. Their 100,000-qubit roadmap by 2033 is engineering execution with billions committed. Google's Willow chip just solved the error correction problem that skeptics said would prevent large quantum computers. NVIDIA just announced massive investment into quantum error correction a few months ago, pouring resources into making quantum computers stable enough for real computation. The future isn't just AI; it's quantum computing, and the biggest tech companies know it. When you combine hardware progress with algorithmic improvements like Google's 20x speedup this year, the 2030s are coming fast. This isn't alarmist; it's pragmatic. The HD wallet approach with automatic address rotation is exactly right, and let me explain why this is literally the ONLY viable path forward for Bitcoin's post-quantum transition, using analogies so everyone can understand. Think of your Bitcoin wallet like a house with two locks: your public key is like your street address that everyone can see, and your private key is like the key to your front door that only you have. Quantum computers will be like master locksmiths who can look at any lock (public key) and instantly create a working key (private key). The question becomes: how do we upgrade to quantum proof locks when the locksmith can copy any key they see? Here's the crucial insight: we can't derive quantum resistant keys from existing ECDSA keys. That would be like trying to create an unpickable lock using the blueprint of a pickable one. The quantum computer could just follow the same derivation path and crack both. The ONLY solution is to go back to the original source of randomness, your mnemonic seed phrase, and derive completely separate, mathematically isolated key systems from it. This is the beauty of BIP32 hierarchical deterministic wallets! Your 24-word seed phrase is like a master blueprint that can generate infinite different types of keys through different derivation paths. For classical Bitcoin, we use paths like m/84'/0'/0'/0/0 for SegWit addresses. For quantum-resistant keys, I've been developing a new derivation path m/360'/0'/0'/0/0 that generates ML-DSA keys mathematically isolated from your classical keys. Same seed phrase, completely different cryptographic universes. I've been developing this dual-key system that maintains maximum compatibility while ensuring quantum security, which I plan to submit as an official BIP for post-quantum BIP32 upgrades. The system generates both classical ECDSA/Schnorr keys (32-byte private, 33-byte public) and quantum ML-DSA keys (much larger, 1312-2592 bytes public keys depending on security level). The clever part is we can hash the massive ML-DSA public keys down to 32 bytes using SHA256 for identification, while BIP360's P2QRH addresses will handle the actual script execution when implemented. On the other hand, people using raw private keys without BIP39/BIP32 will face a harsh awakening when quantum threats materialize. They'll need to create entirely new wallets because there's no mathematical path from a single ECDSA private key to a quantum-safe key that doesn't expose you to quantum attack. It's like trying to upgrade from a wooden door to a steel vault while someone's watching. They'll just break in during the upgrade. Only mnemonic-based HD wallets provide the isolated derivation needed for secure migration. You're absolutely right about the 9-18 year buffer that HD wallets provide, but there's a massive UX problem nobody talks about. Regular users get extremely confused when their address changes every time they send or receive funds. This is why most people reuse addresses despite security warnings. Experienced Bitcoiners understand address rotation, but we're the minority. What makes this worse is wallet fragmentation across the ecosystem. Try importing a mnemonic from one wallet provider to another and you'll often get completely different addresses because everyone uses custom derivation paths. Even Bitcoin Core, which you'd expect to be the standard, doesn't even support BIP39 mnemonics directly! Core predates BIP39 and uses its own HD wallet format with internal seeds stored in wallet.dat files. You literally have to derive private keys externally and import them one by one. After three years of Bitcoin development, I can confirm this fragmentation is a massive problem that confuses new users and breaks interoperability. When even the reference implementation doesn't follow the most common mnemonic standard, you know we have a serious coordination problem. The UX disaster goes even deeper. Most wallet developers don't understand that P2PKH, P2SH, P2WPKH, and P2TR addresses are just different encodings of the same underlying public key. They treat each address type as completely separate wallets instead of different representations of the same key material. Now imagine adding address rotation on top of this confusion. Users doing daily Bitcoin transactions would face an impossible UX without massive interface redesigns. Current wallets show you "coins at addresses" when they should be showing "UTXOs controlled by your keys." This fundamental misunderstanding of Bitcoin's architecture makes implementing proper address rotation nearly impossible without completely rethinking wallet design.* To help normal folks understand why this is such a mess: Bitcoin doesn't work like a bank account with a balance. It works with UTXOs, which are like bank checks that can't be partially spent. When someone sends you Bitcoin, they're giving you these checks locked to your address. When you spend, you have to use entire checks and get change back, but for quantum safety, that change must go to a brand new address every time. You can't merge these checks together unless you make a transaction (which costs fees and waits for block inclusion), and the network can only process a limited number of merges per block. Now imagine you're a business receiving hundreds of payments daily. With proper address rotation, each payment creates a new check at a new address. After a few months, you might have thousands of these checks scattered across thousands of addresses. Current wallets show you this chaos as thousands of separate "accounts" instead of one unified balance. It's like having 5,000 different bank checks in your pocket, each needing its own tracking number, and you need to remember which ones you've already shown publicly (making them quantum-vulnerable) versus which are still safe. The wallet should just show "You control $10,000" and handle this nightmare invisibly, but instead users see an incomprehensible mess. The congestion scenario you describe becomes terrifying when you look at actual numbers. Bitcoin currently has exactly 163,888,957 unspent UTXOs on-chain (thanks to my own toolings, I can pull out this info live). A typical block can only process about 12,000 UTXOs maximum. Lets do the math: if everyone tried to migrate their assets to quantum-safe addresses simultaneously, we'd need about 13,650 blocks just to move existing UTXOs once. At 144 blocks per day, that's over 3 months of maximum capacity just for migration, assuming zero regular transactions! But let's be realistic: Bitcoin processes about 3,000-4,000 regular transactions per block today. If we assume migration takes up half the block space (6,000 UTXOs) while normal activity continues, we're looking at 6-7 months minimum. During fee spikes or high activity periods, migration transactions might only get 2,000-3,000 UTXOs per block, stretching this to over a year. And this assumes perfect coordination, which won't happen. In reality, with panic, confusion, and competing priorities, we're likely looking at 1-2 years of congestion where transactions sit in the mempool for days or weeks. What should be a short-range quantum attack window (seconds to minutes) becomes a long-range opportunity (days to weeks). A quantum computer that needs hours to crack a key suddenly has unlimited time while your transaction waits for confirmation. The migration itself becomes the vulnerability. This extended congestion exposes the brutal economic reality nobody wants to discuss is whether the mining fees are even worth the migration for most users. If fees spike to 1000 sats/vbyte during the panic, migrating millions in consolidated UTXOs might still make sense. But what about the guy with $500 spread across 10 addresses? Migration could eat 80% of his holdings in fees alone. The smaller your stack, the more quantum migration becomes economic suicide. This creates a two-tier system where whales migrate to safety while regular users get priced out of quantum protection. They'll have to choose between losing everything to quantum attacks or losing almost everything to fees. The real tragedy is that while we're having these technical discussions, most of the crypto space remains completely oblivious to what's coming. They're sleepwalking toward a cliff. Exchanges still generate raw private keys instead of mnemonics. Wallet developers don't understand their own architecture. Users have no idea their hardware wallets won't protect them from quantum computers that can derive keys from public addresses. The entire ecosystem needs education before the panic starts, but instead we get silence from leaders who should be sounding alarms. The community and developers need a wake-up call to start acting NOW, not waiting for quantum hardware announcements. Yet most talented Bitcoin developers are wasting energy on trivial battles. They're debating whether to disable OP_IF, arguing about uncapped OP_RETURN policies beyond 80 bytes, fighting over inscription formats. Meanwhile, post-quantum ML-DSA signatures will make blocks 100x larger than any ordinals inscription ever could. We're rearranging deck chairs while the iceberg approaches. We need innovation on quantum resistance, wallet standardization, UTXO consolidation strategies, fee market preparations for migration chaos. This should be a wake-up call to the entire community: We're fine tuning bicycles while quantum computers are building teleporters. Time to stop pedaling and start innovating. BIP360 needs attention, wallets need standardization, and we need to think about quantum resistant infrastructure TODAY, not when the breakthrough gets announced and panic has already begun. --------------------------------------------------------- *For context, I'm the CTO and co-founder of OPNet, a consensus layer bringing smart contracts to Bitcoin (not an L2). I've been working to ensure OPNet won't face the same architectural doom as Ethereum and Solana when quantum computers arrive. We'r also working on OP_WALLET to address the wallet UX issues mentioned above. Check my profile if interested in more technical details: xitter.cf/anakun/status/19787271… Here's my tweet from a few days ago about post-quantum: xitter.cf/anakun/status/19878243…