idk. it sounds like BIP360 takes care of quantum stuff. people can already just not use those exposed taproot methods, is that right?
maybe this would be a good way that Taproot dies--people are too...
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.
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.
2❤️1
