Disagree in principle for a few reasons, but I can't call this an unfair point.
Discussion
No worries, Iām probably the only ordinal disrespector whoās marginally pro OP_CAT. Itās an unpopular opinion.
Iāve heard that OP_CAT enables hashrate escrow. This would be a reason to oppose it, but I want to understand how that works before passing judgement.
The hashrate escrow concept of BIP300 is why I oppose Sztorcian Drivechainsānamely because hashrate escrow incentivizes miner centralization. In Bitcoin, your keys = your coins. Hashrate escrow breaks this tenet by putting unlocking power in the hands of miners, and BIP300 enshrines this into the core protocol.
I do not care for or about ordinals, inscriptions, runes etc. The value of the Bitcoin unit (sats) derives from the fact that the data is the thing itself. Bitcoin is the first and most rival, excludable, digital good. It is not an IOU and depends on no counterpartyās performance. Using blockspace to record non-monetary data, especially IOUs, is wasteful, IMO.
My interest in OP_CAT is the expansion of programmability for the development of monetary technology, for the benefit of users.
I remain open to arguments that the costs are too high or benefits too low/nebulous. For example, if enabling OP_CAT made it more expensive to run a node, that would be a strong argument against. If it incentivized miner centralization at scale, that would make it a non-starter. I have not heard anyone make these arguments however.
The arguments Iāve heard so far are of the form āit may enable new things I donāt likeā. But it also probably enables new things our adversaries donāt like (new privacy options, for example).
Is there and in-depth podcast on this somewhere that approaches it from pros and cons ?
The closest podcast Iāve heard was the relatively recent What Bitcoin Did episode with Shinobi. His primary critique (as I understood it) was that to him, OP_CAT complicated future assessments of other soft-fork proposals. That is, because OP_CAT is so flexible, itās hard to predict how it will interact with other new features.
Incidentally, that flexibility is also the principal benefit. OP_CAT-based scripts are almost certainly going to be costlier in bytes than a specific OP code for a specific task (like OP_CTV). It may enable new denser transactions for exotic use cases, but itāll never be denser than a purpose-built OP.
Personally, the only risk to Bitcoin that I consider to be catastrophic is a fast crack of ECDSA. In Bitcoin, your keys = your coins, but only because ECDSA is secure. A fast crack (either by quantum computer or conventional) breaks the your keys = your coins paradigm.
Among other things, OP_CAT enables (costly) quantum-resistant signatures. So if we enabled OP_CAT, I would have confidence that Bitcoin could survive even a fast crack of ECDSA. Quantum pirates may make off with Satoshiās stash, but users could defend themselves by consolidating into new addresses. Prudent users could do so in advance. Without this, weād need to rapidly deploy a soft-fork to provide a new signature scheme under extreme duress.
Note that a fast-crack, zero-day exploit of ECDSA is unlikely and would cause many other, serious implications besides breaking Bitcoin sovereignty. More likely, if ECDSA is to be cracked, itāll happen slowly, so weāll still have time to adapt.
But like I said, what I like about OP_CAT is that it gives tools to users to protect themselves from various different kinds of attacks, at the expense of transactions that are somewhat larger than they might optimally be.
š¤ thanks for sharing