Taproot at nine: the key path still spends loud

Taproot key path still closes the box at spending

Updated 6 October 2026

That is a key path spend. It is not a script path spend. And the difference is the difference between publishing your box's lock for everyone to study, and only opening one specific door on it.

What the key path actually publishes

TAPROOT OUTPUTS, defined in BIP 341 and activated in November 2021, carry a single tweaked public key on chain at the moment coins are received. The tweak is a hash of the script tree, so the on chain key commits to whatever scripts could have been used but does not reveal them. That is the elegance of the construction: most observers see a plain segwit address that looks identical to any other single key output. The magic happens at spending time.

There are two ways to spend a Taproot output. The first is the key path. You construct a signature with the internal key, apply the same script tree commitment tweak to the signature, and present it to the network. The full, tweaked, 32 byte x only public key is published as part of the witness. Anyone running a full node, or anyone who later downloads the blockchain, sees that key.

The second is the script path. You reveal only the scripts you actually executed, plus a Merkle proof that those scripts sit inside the committed tree. The internal key is not published. The other scripts in the tree are not published. Only the parts of the box that you actually use become visible.

For nine years the Bitcoin community has argued about which path is better. From a post quantum angle, the argument has a clean answer. The key path is the loud spend. It is the spend that hands a future attacker the exact public key they need to run Shor's algorithm against, in the event that the secp256k1 discrete logarithm problem falls to a cryptographically relevant quantum computer.

Why the on chain key is the quantum liability

A quantum computer running Shor's algorithm against a published secp256k1 public key recovers the private key in time roughly polynomial in the key size. The current academic estimates for breaking a 256 bit elliptic curve key cluster around the low thousands of logical qubits, with a runtime measured in hours to days once the machine exists. IonQ's 26 day estimate for secp256k1, which CatBitcoin covered earlier, sits inside that envelope and assumes error corrected qubits at scale.

The crucial word is published. Shor needs the public key as input. It does not need a transaction hash. It does not need a script. It needs the 32 byte x only point that, when combined with a chosen nonce, would have produced a valid signature. If the public key is still hidden, the only attack surface is the hash preimage, and that is where SHA 256 stands between the attacker and a working forgery.

Today, October 2026, every pay to taproot address that has been spent via the key path has had its tweaked public key committed to the blockchain in plaintext. Those keys cannot be unhashed. They cannot be retracted. They sit in the UTXO set's history and in every full node's block index. The longer the chain grows, the more such keys accumulate. The more they accumulate, the larger the prize for whoever crosses the quantum threshold first.

The script path does not save you on its own

A common reaction is: fine, I will use the script path and never touch the key path. That is good practice, but it is not a complete defence. The script path reveals the scripts you spend, and those scripts can include raw public keys as part of hash locked or signature locked conditions. If you constructed a script path with a 2 of 3 multisig using raw, unaggregated public keys, then spending that script path will publish all three keys on chain.

The fix is structural. Replace raw key material in scripts with hash commitments. Spend a script path only after the scripts have been committed to by a hash that is itself quantum resistant. The standard advice in 2026, repeated by the BIP 360 working group and by several wallet teams, is that any Taproot script that contains a public key should wrap that key in a hash, so that revealing the script at spend time does not reveal the key.

This is awkward. It pushes users toward constructions like OP_SHA256 followed by an OP_CHECKSIG against a hashed key, which most wallets do not yet support in a user friendly way. The honest summary is: the script path is quieter than the key path, but it is only safe if you designed it to be safe at construction time. Once the script is on chain, the design is fixed.

What a post quantum BIP 360 address looks like in practice

BIP 360, as currently drafted, proposes a new witness version, P2MR, that commits to a post quantum public key hash at the address level. The address starts with a different HRP and uses a different bech32m variant. A P2MR output can be spent only by revealing a post quantum signature, which today means a lattice based scheme such as ML DSA (formerly CRYSTALS Dilithium) or a hash based scheme such as SLH DSA (formerly SPHINCS+).

The signatures are large. A ML DSA 65 signature is roughly 3.3 kilobytes. A SLH DSA 192s signature is roughly 16 kilobytes. Compare that with a Taproot key path spend, which fits a 64 byte Schnorr signature plus a 32 byte x only key into a witness that totals under 100 bytes. The on chain cost of a post quantum signature is real, and the fee market in October 2026 has not been kind to large witnesses.

For users holding Taproot coins now, the practical question is not whether to move to P2MR today. The P2MR output type is not yet consensus activated, and consensus activation is a multi year process even on a fast schedule. The practical question is whether to keep using the key path for ongoing spending, knowing that every key path spend publishes a key that will be forgeable in a post quantum future.

A custody checklist for late 2026

If you are a self custodian holding Taproot coins that you expect to remain untouched for a decade or more, the conservative move in October 2026 is to migrate them to a construction that does not rely on the key path. That usually means a multisig inside a Taproot tree where every key is hash wrapped, or a held output whose only spendable branch is a script path with a time lock and a hash committed key.

If you are spending Taproot coins actively, accept that every key path spend is a public commitment of a future breakable secret. Treat those funds as having a finite quantum shelf life. Move the proceeds to a fresh output whose key has never been published. Cold storage that has only ever received and never spent is, in this framing, the safest shape a Taprow output can be: the public key is hidden behind a hash, the address is a hash, and the box is still closed.

If you are a business receiving Taproot payments to a fixed address, the address is still a hash. The risk crystallises at first spend. A common pattern in 2026 is to spend each incoming payment into a new, hash committed output, so that the published key is, by policy, immediately deprecated. It costs fees. It costs operational complexity. It costs you the elegance of Taproot's silent key path.

If you are running a Lightning channel using Taproot, the situation is more delicate. A Lightning commitment transaction that closes unilaterally will, in the cooperative case, hit the key path. Anchor channels and the latest musig constructions can route around this, but every cooperative close on a standard channel publishes two tweaked keys, one per party, on chain. Lightning in late 2026 is a quantum leaky abstraction by default.

The wider point about boxes and locks

CatBitcoin's box model is useful here because it separates the address (a label on the outside of the box) from the lock (the cryptographic puzzle that holds the box shut) from the key (the secret that opens the lock). A pay to taproot address is a hash. The lock, after BIP 341, is a tweaked Schnorr public key. The key path is the path that opens the box by revealing the lock itself. The script path is the path that opens the box by demonstrating a satisfying argument against a sub lock, while keeping the master lock hidden.

Publishing a public key is not, today, a security failure. The discrete logarithm problem on secp256k1 is hard for classical computers. It will be hard for classical computers for as long as no cryptographically relevant quantum computer exists. The October 2026 concern is about the shape of the failure when that assumption breaks. A key that is never published fails safely: the box stays closed, because there is no lock for the attacker to pick. A key that is published fails completely: the attacker picks the lock, signs a transaction, and walks away with the contents.

That asymmetry is the entire argument for treating the key path as a temporary, transactional convenience rather than a long term storage structure. It is the argument for keeping the box closed, and for being deliberate about every time you choose to publish its lock.