jimbocoin on Nostr: The closest podcast I’ve heard was the relatively recent What Bitcoin Did episode ...
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.
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.