Are Taproot addresses quantum vulnerable?

Yes, and not because of a bug. A Taproot address is a public key written straight into the output, where every other common address type writes a hash. That design choice is what makes Taproot cheap and private, and it is also what leaves every funded bc1p address open to a future quantum attack at rest, whether or not it has ever spent. This article explains why, what the famous “tweak” does and does not protect, and what a Taproot user can sensibly do today.

What a Taproot output actually contains

Take the three most common output types and ask what is written into the transaction output that holds the coins.

• P2PKH (1…) and P2WPKH (bc1q…, 42 characters): a 20-byte hash of the public key. The key itself appears only in the transaction that spends.
• P2SH (3…) and P2WSH (bc1q…, 62 characters): a hash of a script. The script, and every key inside it, appears only when it spends.
• P2TR (bc1p…): a 32-byte public key. Not a hash of it. The key.

This is the whole difference. BIP-341, which defines Taproot, puts it plainly: the output script is the witness version followed by the 32-byte public key Q. Anyone reading the chain can read Q. And Q is a point on the secp256k1 curve, which is exactly the kind of object Shor's algorithm is built to break.

So the rule from our first article applies with no exceptions: a hashed address that has never spent is protected at rest; a Taproot address holding coins is exposed at rest, from the day it received them.

Does the tweak help?

This is the question every Taproot user asks next, and it deserves a real answer rather than a hand-wave.

The key in the output, Q, is not your wallet's internal key P directly. It is P plus a “tweak”: Q = P + t·G, where t is a hash of P together with the Merkle root of any scripts you committed to, and G is the curve's generator. The tweak is what lets a Taproot output commit to a whole tree of alternative spending conditions while looking like a single ordinary key.

It does not hide anything from a quantum attacker. To spend by the key path you sign with the private key that corresponds to Q, which is p + t. An attacker running Shor's algorithm does not need to know P, or t, or that any tweak happened at all. They take Q from the chain, solve its discrete logarithm, and obtain p + t directly. That is a valid key-path signing key. The tweak is a commitment mechanism, not an encryption of the key, and it offers no protection here.

Why Taproot made this trade

It is worth saying clearly that this was a deliberate, well-understood choice, not an oversight.

Exposing the key instead of a hash saves space: a key-path spend needs only a 64-byte signature in the witness, with no key to reveal because it is already in the output. It improves privacy: a single-signature wallet, a multisig using key aggregation, and a complex script-tree contract all look identical on the chain if they spend by the key path. And it makes the script tree possible at all, because the tweak is what binds the tree to the key.

The quantum question was raised during Taproot's design, around 2018 to 2020, and the judgement at the time was that a cryptographically relevant quantum computer was far enough away that the benefits were worth taking. Whether that judgement still holds is exactly what the BIP-360 discussion is about: Pay-to-Merkle-Root is, in short, Taproot with this one property removed.

How much is actually held in Taproot

Less than the discussion would suggest. Taproot activated in November 2021 and wallet support has been gradual. Large custodians in particular have mostly not moved their cold storage to it. In our report on the hundred largest Bitcoin addresses, only two of the hundred were Taproot outputs, holding about 30,000 BTC between them, against 65 addresses exposed the old-fashioned way, by spending from a hashed address and then receiving on it again.

That gives the honest shape of the problem. Taproot exposure is real and it is growing as adoption grows, but for the balance already on the chain today, address reuse is the far bigger exposed set.

A nuance for multisig and script-only Taproot

Not every Taproot output has a spendable key path. Some setups, especially multisig and vault-style scripts, deliberately use an internal key that is provably unspendable, a so-called NUMS point, so that the only way to spend is through the script tree. In that case the key Q on the chain corresponds to no private key anyone holds, and solving its discrete logarithm gains an attacker nothing: there is still no valid key-path signature, because the tweak is applied to a point with no known discrete log and the attacker would recover a value that is useless without it. The keys that matter are the ones inside the scripts, and those stay hidden until the script is revealed by a spend.

This is a genuine exception, and we would rather say so than pretend the rule is simpler than it is. It also has a practical consequence for our own tool: the ShorWatch scanner flags every bc1p address as exposed, because from the outside it cannot tell whether the internal key is a real key or an unspendable point. If you know your wallet uses an unspendable internal key with script-path-only spending, your at-rest exposure is limited to what a spend reveals, and the scanner's verdict is conservative for you. If you use an ordinary single-signature Taproot wallet, which is what almost every consumer wallet offers, the verdict is exact.

What a Taproot user can do today

Nothing about this is urgent, and it should not be treated as urgent. It is a decision about where long-term coins sit, and the sensible version is calm.

1. Keep using Taproot for coins that move. A spending wallet, Lightning, anything that will be spent within months: the at-rest exposure barely matters, because the short-range attack that would hit a transaction in flight is beyond any foreseeable machine, and the coins are not sitting still long enough for the long-range attack to be the relevant threat.
2. For long-term storage, prefer a fresh hashed address. A never-used bc1q address gives you today, at no cost, the protection at rest that BIP-360 is designed to give tomorrow. It costs a little more per byte when you eventually spend, and you give up Taproot's privacy benefits for that output. For coins meant to sit for years, most people will find that a fair trade.
3. If you hold a large balance in a Taproot output already, decide with numbers. One transaction moves it to a fresh hashed address. That links the two outputs for anyone watching the chain and costs a fee. Whether it is worth it depends on the amount, how long you intend to hold, and how you weigh a distant but permanent exposure. Check the split first; the decision is much easier once you can see which of your coins are on keys and which are on hashes.
4. Do not reuse addresses. This is the advice that matters most and applies to every address type. A Taproot address is exposed once; a reused hashed address becomes exposed and stays that way, and it is by far the more common way to end up with coins on a public key.

On the timeline, again

We say this in every article because it is the part most often misrepresented: no computer today can run Shor's algorithm against a 256-bit curve key, the engineering gap is measured in orders of magnitude of error-corrected qubits, and anyone selling you a date is guessing. What is knowable is which of your coins are on keys. For Taproot the answer is all of them, and that is simply a fact about the address type, to be weighed calmly alongside its real advantages.