Nostr Web Client

What *doesn’t* it enable? The scope of OP_CAT and what it can do seems so arbitrarily large as to make discussion of it difficult. Not to mention developing with it is unintuitive and creates very complex scripts for very simple functions.

Everything I’ve seen suggests it is a recipe for messy development, technical debt, long term bugs/faults that aren’t obvious at the outset, and an avalanche of scams that aren’t secure, decentralized, or anything else we care about but that bring the “crypto” world flooding into Bitcoin selling the same garbage with a fresh coat of paint.

If you have a different perspective and can argue it, be my guest, I’m happy to learn something.

jimbocoin 🃏 1y ago

I have a less-pessimistic appraisal of OP_CAT. Yes, it enables more use-cases. Like anything, there are costs and benefits.

What I like about it, personally, is that the additional flexibility provides space for developers/users to defend against attacks. It may enable new and better CoinJoin solutions to mask transactions from censors. It could provide novel vault solutions. It opens up alternative signature schemes potentially with better properties for some kinds of attacks. Defense against a discovered weakness in ECDSA for example.

However, OP_CAT solutions tend to be costlier for the user than the would-be alternatives. An OP_CAT vault will take more bytes than an OP_VAULT TX for instance. But this is OK. Someone who wants the expensive functionality can pay for the bytes. If that type of transaction becomes popular, we can always fork in a specific OP later to reduce costs.

Having said all of that, I don’t think OP_CAT is something that should be rushed through. It’s not urgent. Consensus is paramount. I just don’t share the net-negative appraisal of most hardcore Bitcoiners here.

Reply to this note

Please Login to reply.

Discussion

Guy Swann 1y ago

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

jimbocoin 🃏 1y ago

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

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

Ademan 1y ago

Bad news about OP_VAULT https://twitter.com/reardencode/status/1756185478716657830

(I have not checked Brandon's work on this, but you can see that I had the intuition about it independently)

Ademan 1y ago

I want to remind everyone that CTV alone enables vaults https://github.com/jamesob/simple-ctv-vault

(jamesob designed OP_VAULT around the problems with these simple vaults, so that's not to say they're perfect, but I believe they are useful. In fact, I believe simple vaults gives us 90% of what we want anyway.)