BitVM in a Nutshell
  • BitVM in a Nutshell
  • Introduction to BitVM
    • What Is BitVM?
    • How Bitcoin's Programming Works
    • How BitVM Enhances Bitcoin's Functionality
    • Bringing Computation to Bitcoin Through Off-Chain Execution
    • Conclusion
  • BitVM Applications & Use Cases
    • Introduction
    • Building Trust-Minimized Bridges
    • Beyond the Lightning Network
    • Sharing Bitcoin Security with Other Systems
    • Conclusion
  • BitVM Programming Paradigms
    • Introduction
    • How to Construct a BitVM in Practice
    • The Challenges of Compiling for Bitcoin
    • The Solution: Staging Compilation and Decomposition
    • Remarks and Future Directions
  • Existing Efforts related to BitVM
    • The Birth of BitVM
    • Making BitVM Practical: The Push for Efficiency and Automation
    • Real-World Applications: The BitVM Bridge
    • Conclusion
  • Future Work: Scaling BitVM in Production
    • Introduction
    • Developing Bitcoin-Friendly Cryptographic Primitives
    • Automating the Compilation Pipeline
    • Enhancing Security Through Formal Methods
    • Conclusion
  • BitVM vs. OP_CAT
    • What Is OP_CAT and Why Does It Matter?
    • How OP_CAT Could Boost BitVM
    • Why Isn’t OP_CAT Enabled Yet?
    • Conclusion
Powered by GitBook
On this page
  1. BitVM vs. OP_CAT

Why Isn’t OP_CAT Enabled Yet?

The potential of OP_CAT is undeniable. In fact, OP_CAT was originally included and enabled in the earliest versions of Bitcoin, but in 2010, Satoshi Nakamoto disabled it. Today, discussions about re-enabling OP_CAT reflect a deeper debate within the Bitcoin community, one that extends beyond OP_CAT itself and centers on Bitcoin's philosophy regarding stability versus innovation.

On one side, there are ossificationists who believe that Bitcoin should remain as stable as possible to preserve its reliability. They argue that even a seemingly small change like OP_CAT could unintentionally introduce security risks or disrupt Bitcoin’s core functions. For them, Bitcoin’s top priority is to stay secure and stable as a global payment system, so they’re cautious about any new features.

On the other hand, progressive developers see the need for Bitcoin to evolve and support more advanced functionality. However, even among those in favor of updates, there’s hesitation around OP_CAT. Many view it as a temporary workaround rather than a long-term solution—a way to mimic covenant-like behavior but with limitations and inefficiencies. They argue that using OP_CAT to simulate covenants requires awkward and complex scripting, whereas a dedicated covenant feature could achieve the same results more elegantly.

As a result, some community members are exploring alternatives that could introduce covenants more naturally. Introspection opcodes are one such idea. These would allow scripts to access transaction data directly, making it easier to enforce specific conditions without needing to concatenate and hash data as a workaround. Introspection opcodes could strike a better balance—simple enough to stay secure but expressive enough to support advanced applications.

However, adding new features to Bitcoin is a lengthy process. Every change requires extensive testing, community debate, and near-unanimous consensus. This means that any new feature must be truly impactful; if it doesn’t offer major benefits, it’s not worth the effort.

While the debate over OP_CAT continues, the broader trend toward expanding Bitcoin’s programmability is clear. The community is committed to finding the best way forward, with a shared vision of a more capable and secure Bitcoin that can support a wider range of applications in the future.

PreviousHow OP_CAT Could Boost BitVMNextConclusion

Last updated 6 months ago