On chain data could be stored before Taproot, always.
Rolling back Taproot because it could store on chain data is the same as burning down your house to kill a cockroach.
You can just kill the cockroach (implement a relay policy)
Login to reply
Replies (10)
Exactly, targeting the specific problem makes way more sense than throwing out the whole upgrade.
(Btw, check my pinned post if you'd like to support my family in Gaza 🙏)
A lot of it comes from plain old mistrust of devs. "This code change happened and then bad things happened. Revert the code change!"
I'm honestly of the mind that no more code changes will be a good thing, security or otherwise.
Taproot has one useful function MuSig. Everything else is highly exploitable.
Except is wasn’t a big problem *until* taproot. You know this. 
WTF Happened in Feb 2023?
Bitcoin Spam and Blockspace in Feb 2023 | WTF Happened
How February 2023 Bitcoin spam crowded blockspace, raised fees, and exposed relay policy choices.
Sorry, I’m not interested in reading Claude slop.
The problem that the relay policy was not implemented. That is it. It is not an inherently Taproot problem and any upgrade could have had this issue.
It should have been implemented and there is no need to rollback Taproot
Then your definition of “exploit” is wildly different than mine
This will only accelerate the failure of Bitcoin if it is happening (likely yes) as it rapidly shifts from actually useable money to corporate hoarding asset.
Which relay policy? By who, to where?
Writing non-executing code via OP_IF is not an exploit?
K
Does Libre Relay make that irrelevant?