Connect with us


OP_CAT & Bitcoin Ossification With Blockstream’s Andrew Poelstra




In a recent interview with Bitcoin Magazine, Shinobi sat down with Andrew Poelstra from Blockstream to discuss his colleague Rusty Russell’s ambitious proposal. Rusty plans to restore several abandoned features from Bitcoin’s code, a bold move that could significantly enhance the functionality and expressivity of Bitcoin scripts.

Understanding the New Costing Model

One of the central aspects of the “Great Script Restoration” proposal is the introduction of a new costing model for opcodes. Currently, in Bitcoin, every operation costs the same, regardless of its computational complexity. This model, however, does not accurately reflect the true cost of script execution, leading to potential inefficiencies and limitations. Rusty’s new costing model seeks to address this by assigning different costs to opcodes based on their computational requirements. This approach is a significant departure from the existing model and aligns more closely with how computational costs are handled in other blockchain platforms like Ethereum.

Andrew Poelstra highlighted the potential benefits and challenges of this new model. “The new costing model is very interesting and it’s kind of a departure from the way that Bitcoin works today,” he noted. The new model would ensure that scripts are priced more fairly based on the resources they consume, potentially preventing spam attacks and other issues.

Challenges and Consensus-Building

Implementing this plan is not without its challenges. One major concern is the complexity of determining the execution time of scripts. In Ethereum, for example, transactions have a gas limit to prevent excessive computation. Poelstra acknowledged the similarities, stating, “I’m gonna say something kind of mean here and say this looks like gas, right?” However, he emphasized that unlike Ethereum, where running out of gas still costs the user, in Bitcoin, a failed transaction does not result in lost funds.

To move forward, the Bitcoin developer community needs to build consensus around this plan. Poelstra mentioned a noticeable shift in the community’s attitude toward script expressivity over the past few months. This change is partly due to the emergence of new use cases and the realization that restrictive approaches may hinder innovation. “There’s been a really interesting kind of mood shift in the Bitcoin developer community over the last, really like the last six months,” he observed.

Addressing Bitcoin Ossification

The path forward involves several key steps. Firstly, developers need to write up a proper proposal, including reference implementations and test vectors. This proposal will then be reviewed and discussed within the community to gather feedback and build consensus. Poelstra stressed the importance of this process, stating, “Initially the steps are pretty straightforward, right? You write up a proper proposal, you have a reference notation, you write test vectors, you get benchmarks.”

A significant part of the consensus-building process will involve addressing the debate around ossification—the idea that Bitcoin’s protocol should remain unchanged to preserve stability and security. Some community members, known as ossificationists, believe that Bitcoin should resist changes to avoid introducing potential vulnerabilities and maintain its current robustness. Poelstra recognizes this concern but argues that certain changes, like Rusty’s proposal, are necessary for Bitcoin’s continued growth and functionality.

The debate centers on whether the risks associated with changes outweigh the benefits. Poelstra pointed out that Bitcoin is already evolving, citing the emergence of ordinals and inscriptions as examples of how the network is being used in new, unanticipated ways. He emphasized that refusing to adapt could limit Bitcoin’s potential and that the economic incentives within the network will naturally sort out usage priorities.

“We need to talk to people who identify as ossificationists or who we might call ossificationists, right? People who don’t want Bitcoin to change. And I think we just got to argue passionately and correctly that this is something that would be good for Bitcoin,” Poelstra said. He believes that by clearly articulating the benefits of enhanced script expressivity and addressing the concerns of the ossificationists, a balanced and informed consensus can be reached.

Furthermore, Poelstra highlighted that while change comes with risks, it also opens up opportunities for essential improvements, such as better scalability, enhanced security through vaults, and more efficient use of blockchain space with mechanisms like coin pools. These enhancements can make Bitcoin more robust and adaptable to future needs.

The next steps involve not only the technical process of formalizing the proposal and conducting thorough testing but also engaging in a broader dialogue within the community. This dialogue will need to balance the preservation of Bitcoin’s core principles with the need for innovation and adaptation, ensuring that the network can continue to thrive and meet the evolving demands of its users.


Rusty’s plan to make Bitcoin script great again represents a significant step towards enhancing the expressivity of the Bitcoin network. While there are challenges to overcome, the potential benefits in terms of functionality and innovation are substantial. As the Bitcoin developer community continues to evolve and embrace new ideas, proposals like this will be crucial in shaping the future of the network.