Next scheduled rescrape ... in 5 days
Version 1
Last scraped
Scraped on 06/05/2025, 16:34:28 UTC
As I've already written before, "fixing what's being exploited", is simply not possible. If you filter / block use cases like Ordinals you would direct the same spam into potentially more harmful mechanics.
Sadly I somewhat agree with this, which is what I've warned about before; and it's only because the core devs didn't act when they should have acted!If they had fixed the exploit in a patch shortly after the Ordinals Attack was introduced, it would not have grown so much to "fester" and establish a market. After all before this attack began we weren't seeing people spamming or using "other more harmful mechanics" to inject arbitrary data into the chain at large scale. So preventing it would have never led to it either.
But I still don't see how encouraging people to inject arbitrary data of any size and without limit
As gmaxwell already wrote those who exploit Taproot via Ordinals usually do that with a profit expectation.
demand from this market could be directed significantly more into the OP_RETURN "channel" instead of the Taproot and "fake address" channels.
They are indeed driven by profit, and to make profit from the garbage they create they'd look to minimize their costs. Even more so during the mempool congestion times where fee rates shoot up significantly. Using the exploit to inject their large date into witness is significantly cheaper compared to using OP_RETURN. I doubt they can be directed to using it instead.demand from this market could be directed significantly more into the OP_RETURN "channel" instead of the Taproot and "fake address" channels.
And like I always say bitcoin is not a cloud storage, so we should make it harder for them to use it as such not easier (ie. removing OP_RETURN limit).
Original archived Re: Removing OP_return limits seems like a huge mistake
Scraped on 06/05/2025, 16:29:24 UTC
As I've already written before, "fixing what's being exploited", is simply not possible. If you filter / block use cases like Ordinals you would direct the same spam into potentially more harmful mechanics.
Sadly I somewhat agree with this, which is what I've warned about before; and it's only because the core devs didn't act when they should have acted!If they had fixed the exploit in a patch shortly after the Ordinals Attack was introduced, it would not have grown so much to "fester" and establish a market. After all before this attack began we weren't seeing people spamming or using "other more harmful mechanics" to inject arbitrary data into the chain at large scale. So preventing it would have never led to it either.
But I still don't see how encouraging people to inject arbitrary data of any size and without limit into bitcoin blockchain which would be treating it like cloud storage is a good idea. It sounds like a disaster not a solution.
As gmaxwell already wrote those who exploit Taproot via Ordinals usually do that with a profit expectation.
demand from this market could be directed significantly more into the OP_RETURN "channel" instead of the Taproot and "fake address" channels.
They are indeed driven by profit, and to make profit from the garbage they create they'd look to minimize their costs. Even more so during the mempool congestion times where fee rates shoot up significantly. Using the exploit to inject their large date into witness is significantly cheaper compared to using OP_RETURN. I doubt they can be directed to using it instead.demand from this market could be directed significantly more into the OP_RETURN "channel" instead of the Taproot and "fake address" channels.
And like I always say bitcoin is not a cloud storage, so we should make it harder for them to use it as such not easier (ie. removing OP_RETURN limit).