Nostr Web Client

Disagree in principle for a few reasons, but I can't call this an unfair point.

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).

Reply to this note

Please Login to reply.

Discussion

HoloKat 1y ago

Is there and in-depth podcast on this somewhere that approaches it from pros and cons ?

jimbocoin 🃏 1y ago

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.

HoloKat 1y ago

🤔 thanks for sharing