The advice that stuck with me from Southern Bitcoiner's February 11, 2026 video on quantum computing is how ordinary it turns out to be. A sufficiently powerful quantum computer could take a bitcoin public key, reverse engineer it into the private key, and use that key to move the coins. He skips the new coin and the new hardware and goes straight to three wallet habits that most good wallets already follow.
How quantum computing and Bitcoin keys interact
Every bitcoin wallet rests on a pair of numbers. The private key is the secret that authorizes a spend. The public key is derived from it, and the address you hand out is a shorter form of that public key. The flow runs one way, from private to public, and you cannot work backwards with an ordinary computer.
A quantum machine of enough power would run it backwards. It could take the public key and derive the private key from it, which is the same as handing over the coins. The creator's comparison is an email account that could be broken into with only the email address and no password. That is not how email works, and it is not how bitcoin works today either, which is the point he is making about scale. The gap between an address and a public key is what all of his advice hangs on, because an address on its own gives an attacker nothing.
He is careful about what he claims: "I'm not here to argue whether quantum is a real threat or what the time frame is. I'm here to tell you some of the measures you can take to defend yourself against quantum today."
So the rest is a set of precautions. At the time of the video, quantum computers could not break Bitcoin keys, and he said so more than once. The rest of his advice follows from one asymmetry: receiving bitcoin puts less on the chain than spending it does, and a wallet can shorten that second exposure if you let it.
Why the public key is the thing to hide
Public keys are meant to be public, which is why the exercise is temporary. Today an attacker holding your public key can do nothing with it. The exposure only bites if the machines get strong enough to reverse the derivation. The name is the tell: a public key is not a secret today, and treating it like one only buys time.
You cannot keep a public key hidden forever and still move the coins. A valid spend publishes the key along with the signature, so the moment you send from an address, that address's key sits on the chain for anyone to read. The practical aim is to shorten the time a key is exposed and to keep a key that has already been exposed from holding the rest of your balance.
I find it cleaner to treat the three steps as one idea with three applications. A key you have not used yet is private. A key you have used is public. Keep your money behind keys you have not used.
Wallet habits cannot settle the larger question of whether quantum machines ever arrive. What a wallet can do is limit how much sits behind a key you have already spent from, and that limit is the whole payload of the advice.
Which address type to use: bc1q, not bc1p
Bitcoin addresses come in more than one format, and the first characters tell you which one you are looking at.
| Prefix | Address type | What the creator says about it |
|---|---|---|
| bc1q | Native SegWit | Use it. Receiving reveals only the address, not the public key. |
| bc1p | Taproot | Avoid it for now. |
Most wallets default to Native SegWit, so plenty of people are covered without doing anything. If a fresh receive address starts with bc1q, that step is finished. If it starts with something else, move to wallet software that hands out Native SegWit addresses.
The reasoning is narrow. When you receive bitcoin to a Native SegWit address, only the address is revealed, so there is no public key on chain for a quantum machine to work on. Taproot is the one to avoid for now. A Taproot output is built from a public key, which puts it in a different position under this threat model, and the advice is to leave bc1p addresses alone until the picture is clearer.
That caution is not a verdict on Taproot's other trade-offs. The creator is talking about one risk, and his advice is explicitly a "for now". I would check the prefix before changing anything else, because it is the cheapest test in the whole list.
The three steps, in order
The instructions reduce to a short checklist. I would run it once with your main wallet open, because each step takes a minute.
- Open your wallet and generate a fresh receive address. If it starts with bc1q, you are on Native SegWit and there is nothing to change. If it starts with something else, move your balance to a wallet that gives you bc1q addresses.
- Find the change setting and confirm that change goes to a brand new address. In Sparrow, the Change Addresses list should show fresh bc1q addresses rather than ones you have already spent from.
- Generate a new receive address for every payment you ask for. Do not paste the same address into two invoices, and do not publish one address for people to reuse.
- If your wallet cannot do any of the above, replace it. The creator names Sparrow Wallet and BlueWallet as examples of wallets that handle these rules by default.
Step two is the one people miss, because good software does it silently. You never see the change address in a normal send, so the only way to check is to go looking. None of this requires a new wallet if yours is current; the list is mostly about confirming what your software already does.
Change addresses and how UTXOs work
Bitcoin does not keep a running balance the way a bank account does. A wallet holds UTXOs, short for unspent transaction outputs, which are chunks of coin left over from earlier transactions. When you send, the wallet spends whole chunks. One part goes to the recipient, and the rest comes back to you as change, minus the fee.
A small transaction shows the mechanics.
| Output | Amount |
|---|---|
| UTXO spent as the input | 0.00096658 BTC |
| Sent to the recipient ("Bob") | 0.000423 BTC |
| Change back to the wallet, to an address starting bc1q7j2p | 0.00054217 BTC |
| Transaction fee | 0.00000141 BTC |
The three outputs add up to the input: 0.000423 + 0.00054217 + 0.00000141 = 0.00096658 BTC. The change does not return to the address the wallet just spent from. It goes to a different one. The spent address now has a public key on chain; the new one does not. The wallet does not create the amount you typed out of thin air. It picks chunks it controls and pays the difference back to itself.
Send the change back to the old address and you have moved the balance behind a key anyone can already see. The rule is that the change address should be fresh, with a public key that has never been exposed. Good wallets pick that address for you. A wallet that recycles spent addresses is the one to watch, because every send leaves more of your balance sitting behind public keys.
This is also where the privacy benefit shows up. Anyone reading the chain can follow the history of an address, so a wallet that keeps generating new ones for receives and for change helps on two fronts at once. You get the quantum precaution and the privacy at the same time, from the same setting.
The mempool window
A transaction does not confirm the instant you broadcast it. It waits in the mempool, the queue where unconfirmed transactions sit until a miner picks one up and puts it in a block. The usual wait is around 10 minutes, sometimes longer. Ten minutes is an average, so the window can run longer.
That wait is the one place where the quantum story turns concrete. While the transaction is pending, the public key is visible on chain, and in theory a machine fast enough could derive the private key and broadcast a competing spend before the original confirms. The window is short, which cuts both ways: there is not much time to work in, but the coins are moving through it in the open.
I read this window as less important than the addresses you leave untouched for years. A key that appears on chain and then goes quiet is exposed for as long as the coins sit there, not for ten minutes. The creator's argument points the same way. He also said that cracking a key inside a 10-minute window was a long way off, even in the scenario where the machines arrive.
He is clear about where things stand: "This is all just something you need to be aware of, and these are precautions you can take today for a threat that doesn't exist yet."
What the habits do beyond quantum
None of this is exotic. Address reuse has been bad practice for as long as there has been a public ledger, and the reason has nothing to do with quantum machines. A reused address ties every payment to the same owner, so anyone watching the chain can build a picture of who paid whom and when. Fresh addresses break those links, and change to a fresh address stops a single spend from connecting your new balance to your old one.
That is why the creator calls these habits best practice that happens to help with quantum. If you already run a wallet the way Bitcoiners are told to, you have most of the protection without thinking about physics at all.
The habit scales in a way willpower does not. A wallet that generates a new address per receive and per change does the work in the background, which is why the advice ends with choosing the right wallet rather than trying harder. I would rather have the privacy than the quantum insurance, and the same setting gives me both.
What the precautions do not fix
The creator does not sell this as a complete answer. Bitcoin itself would need to change if the threat became real, and no wallet setting can rescue coins already sitting behind a public key that has been revealed. Once an address has been spent from, its key is out, and the only fix is to move the balance somewhere fresh before anyone can act on it.
He puts no date on any of this. The timelines people throw around for quantum hardware are guesses, and I would not wait for a firm one before checking a wallet.
The video stops at naming Sparrow Wallet and BlueWallet, so read your own wallet's documentation on change addresses and address type before you assume it behaves the way he describes.
What to check in your own wallet
Open your wallet and generate a receive address. Look at the first four characters. If they are bc1q, you are on Native SegWit and the main exposure is handled. If they are bc1p, avoid receiving there for now, and if they are something else entirely, it is worth moving to software that produces Native SegWit addresses.
Then look at a past transaction and find the change output. It should sit at an address you have never used before. If your wallet sends change back to the address you spent from, that is the setting to fix, and if it cannot be fixed, the wallet is the thing to replace. I would run this check on a small wallet first, before moving a balance you care about.
The thing to remember is short: bc1q for receives, a fresh address every time, and around 10 minutes in the mempool. When the next quantum headline appears, the useful questions are whether it describes a machine that exists, whether that machine could beat a 10-minute window, and whether the fix is a wallet habit or a change to Bitcoin itself. The first two you can judge from the reporting. The third tells you whether there is anything for you to do this week, which is the only part that involves your coins.
