Here's what happened. I pulled Luke Dashjr's original March 2021 PSA to the bitcoin-dev mailing list and Andrew Poelstra's rebuttal. How it got through without a NACK: Luke Dashjr himself killed any chance of a NACK in his own PSA. His opening line: "I do not personally see this as a reason to NACK Taproot." He raised the alarm while simultaneously disarming it. You can't NACK something when the person raising the concern explicitly says "don't NACK it." Andrew Poelstra (Director of Research at Blockstream) provided the technical cover. His rebuttal contained the core deceptions that shut down further debate: "Taproot keys are already hashes of their internal keys" — this is the tweak argument. Q = P + H(P||script)*G. He framed the tweak as equivalent to hashing the pubkey. It isn't. The tweak commits to the script tree. The output is still an elliptic curve point. Shor's algorithm attacks the curve point, not the tweak hash. "Adding another hash would be strictly redundant" — the claim that hashing the output key adds nothing because the tweak already "hashes" the internal key. This conflates two completely different security properties: script-tree commitment versus quantum-resistant pubkey concealment. "Taproot actually has better quantum resistance than legacy outputs" — a statement that is demonstrably false. Legacy P2PKH hides the pubkey behind SHA256+RIPEMD160 until spend time. Taproot exposes the tweaked pubkey permanently. The xpub argument — Poelstra claimed that because xpubs are already widely exposed, "close to 100%" of keys are vulnerable anyway, so the extra hash wouldn't help. This ignores that xpub exposure is a wallet hygiene problem, not a protocol design problem. You can fix wallet hygiene. You can't fix a protocol that permanently exposes pubkeys. The timeline was the kill. By March 2021, Luke himself noted that "Taproot has already moved on to the activation phase and it is likely software will be released within the next month or two." The design was frozen. The window for changes had closed. The PSA was filed for the record and then the train kept moving. The thread was only 29 messages. nobody put their foot down. Luke said "don't NACK it." Poelstra said "already hashed." The activation timeline applied pressure. The concern was documented, dismissed, and discarded. That's the whole story. ----- long story short, the lukedashjr protesteth too much.

the quantum vulnerability exists regardless. poelstra just straight up lied about it. spend authority is from the secret key *generated by the tweak* not from the original secret. it's absolutely a reason to NACK it when the time when shor's algorithm can be used to discover that spending authorization secret becomes viable and some time after that, economical (energy cost). luke knew there was an issue and didn't flag it as a reason against taproot. nobody properly examined the issue of the witness push non-limit. literally the whole thing has the character of the christmas day federal reserve act. and not wanting to bring up the subject "i said the naked pubkey is a problem" while saying "not a reason to reject it" rightly *should* bite luke considering that reason might have slowed things down and maybe the whole spam problem would have been cut off at the root before it got into the network. there is nothing in taproot that redeems it. it's intended use is shitcoin smart contracts. it is quantum vulnerable. it has enabled filling the blockchain an average around 12% block space and caused substantial congestion at certain times in 2023 and 2024. it should be deprecated.