As of February 2023, there seems to be a consensus among users that Bitcoin needs covenants. And Andrew Poelstra, as Director of Research at Blockstream, is one of the most experienced people in this field. As a Taproot co-author, he spent the last few years trying to expand the functionality of Tapscript. This research helped him discover ways in which covenants would greatly expand the expressivity of the scripting language. Naturally, new use cases would also emerge – while existing ones can get upgraded.

In a series of articles that he published on the Blockstream Research blog in 2021 and 2022, Andrew Poelstra explained how the integration of new Opcodes helped the Elements Alpha/Liquid fork achieve results that are interesting and useful for developers. And currently, Poelstra appears to favor the OP_CAT (Concatenation) proposal because of its small size, simplicity, and potency. It only has 13 lines of code and appears to be pretty powerful. As a matter of fact, the Blockstream Director of Research seems convinced that OP_CAT is the winning solution for recursive covenants, and will get soft forked into Bitcoin next.

OP_CAT used to be included in the original Bitcoin stack, but Satoshi Nakamoto disabled it in 2010 as part of CVE-2010-5137. Since OP_CAT allows for two strings of data to get combined into one, the Bitcoin creator was concerned that the opcode could be used to cause exponential growth in stack elements. This growth would potentially crash network nodes due to the large amounts of data overloading the access memory and storage. At the time, a combination between OP_CAT and OP_DUP had the power to concatenate a 1-byte value until it grew up to 1 terabyte.

However, OP_CAT was resurrected in October 2023 thanks to the contributions of Bitcoin Core developers Ethan Heilman and Armin Sabouri. As of February 8th 2024, the BIP doesn’t have a number yet. But it argues that the current implementation would get limited by a maximum script element size of 512 bytes (half a kilobyte). In order to advocate for the activation of OP_CAT, six use cases are presented:

1. Decentralized file hosting systems that get paid in bitcoin (Bitstream);
2. Tree signatures and generalized logical spend conditions;
3. Post-quantum Lamport signatures;
4. Payment channels via non-equivocation contracts;
5. Vaults;
6. A replication of CheckSigFromStack.

It’s worth mentioning that Andrew Poelstra is referenced in two of these claims – and at around the 30-minute mark of our interview he expresses a degree of gratitude that Ethan Heilman and Armin Sabouri for taking the time to formalize the ideas into a BIP. Poelstra has admittedly been working with CAT’s functions for years, but hasn’t expressed his public support for the proposal until recently.

Another interesting part of our interview concerns Andrew Poelstra’s views on OP_CTV (BIP 119). He is not against activating it in the future and presents no formal objection about it. However, he mentions its limits and the fact that it may cater to only about 90% of developer expectations – and therefore open up the gates for yet another covenant soft fork to get added on top. At around the 38-minute mark, Poelstra says:

“There’s just a whole ton of things that we’d like to be able to do with OP_CAT that are not even necessarily related to covenants versus something like OP_CTV. Where CTV is deliberately, narrowly tailored to allow you to do covenants and specifically to allow you to do non recursive covenants and not much else.

There’s a fear that maybe we activate CTV and it does 90% of what we want Bitcoin script to be able to do. And then we won’t be able to get that other 10%… because now the relative value of that last 10% of getting recursive covenants versus non-intrusive ones… that the relative value just won’t be there anymore, right? We’ve already got CTV. That’s good enough. Nobody wants to go through the effort of doing an upgrade. Or maybe we do go through the effort of upgrading, and then we’ve got the CTV thing, which is like this vestigial object from 2024. And here we are in 2034 saying like, why do we have to maintain that forever when we have this better solution that we just finally discovered? It just took us ten years, right? People don’t want to have that.”

It’s also interesting that Jeremy Rubin, creator of alternative covenant proposal OP_CTV (proposed as BIP 119), also argued in a July 2021 bitcoin-dev e-mail that OP_CAT makes Bitcoin quantum secure.

Bitcoin Takeover podcast season 15 is sponsored by Wasabi Wallet, Cryptosteel, Satochip and IVPN.

Listen to Andrew Poelstra talk about OP_CAT vs OP_CTV on Spotify, Apple Podcasts, YouTube & X!

Not a fan of big tech platforms? No problem! Use this free player to get much better privacy without the need to sign up to any service. Better yet, open it in the Tor browser for maximum privacy. And if you’re a fan of hikes or driving outside of the internet coverage areas, you can also download the audio file for offline enjoyment.

This episode’s time stamps:

Covenants and their applications (00:02:22) Explanation of covenants and their applications, including the concept of a vault and regulatory implications.

Controversy and fears surrounding covenants (00:06:56) Discussion on the tension and fears related to covenants, including the potential for misuse and the debate about their necessity.

Disabled opcodes and the power of OP_CAT (00:15:29) Explanation of OP_CAT, its disabling by Satoshi, and its potential for enabling new functionalities in Bitcoin script.

Covenants and Schnorr Signatures (00:22:33) Andrew Poelstra explains the technical details and implications of using OP_CAT and OP_CTV to enable covenants in Bitcoin script.

Benefits of OP_CAT (00:23:40) Exploration of the benefits of using OP_CAT in Bitcoin script to enable direct constraints on transaction data and the historical context of using Schnorr signatures for covenants.

Use Cases of CAT and CHECKSIGFROMSTACK (00:24:52) Explanation of how OP_CAT and CHECKSIGFROMSTACK from stack can be used for various applications, such as oracle inputs and sports gambling, to move funds conditioned on specific outcomes.

History and Evolution of Covenants (00:27:07) Andrew Poelstra discusses the historical development of OP_CAT and CHECKSIGFROMSTACK in Elements Alpha, and the recent advancements in using Schnorr signatures for covenants.

Challenges in Implementing OP_CAT (00:28:12) Andrew Poelstra explains the challenges and delays in implementing OP_CAT in Bitcoin, including the process of writing a BIP and the consensus needed for activation.

Comparison with Previous Soft Forks (00:31:45) Comparison of the technical complexity and controversy surrounding OP_CAT with previous soft forks, such as SegWit and Taproot.

Technical Simplicity of OP_CAT (00:34:40) Andrew Poelstra emphasizes the technical simplicity of OP_CAT, highlighting its minimal impact on the script interpreter and the potential for straightforward activation.

Potential Use Cases Beyond Covenants (00:37:24) Discussion about the broader utility of OP_CAT beyond covenants, including its potential for arbitrary precision arithmetic and other script enhancements.

Concerns and Opposition to OP_CAT (00:43:26) Exploration of the opposition to OP_CAT, including concerns about adding soft forks that may not be universally useful for all users, and the pitch for its functionality to average users.

Covenants in Bitcoin (00:44:30) Andrew Poelstra discusses the limitations of OP_CAT for recursive covenants and the complexity of building covenants with OP_CAT.

Challenges with Covenants (00:45:20) Andrew Poelstra highlights the limitations of OP_CAT machinery and the impact of the 201 OPcode limit on building real covenants.

Benefits for Ordinary Users (00:46:21) Andrew Poelstra explains the benefits of covenants for ordinary users, including vaults for long-term storage and improved efficiency in the Lightning Network.

User Control Over Transactions (00:47:20) Andrew Poelstra discusses how covenant proposals can give users more control over transaction fees and the impact on the fee market.

Future Soft Forks and Protocol Changes (00:53:49) Andrew Poelstra shares insights on the potential for future soft forks, including OP_CAT and the need for real covenant proposals.

Sidechains and Incentive Structures (01:01:06) Andrew Poelstra discusses the history and challenges of sidechains, emphasizing the complexities of incentive structures and the limitations of relying solely on incentives for system integrity.

The incentive-based component of Bitcoin (01:05:20) Discussion on the historical controversy and technical implications of Bitcoin’s incentive-based component.

Extension blocks and MimbleWimble (01:06:30) Explanation of extension blocks and MimbleWimble, their trade-offs, and the technical details of transaction compression.

Adapter signatures and lightning on mobile (01:08:57) Insights into adapter signatures, their role in Lightning on mobile, and their implications for Bitcoin’s scalability.

Taproot and MimbleWimble (01:11:04) Explanation of the benefits of Taproot and MimbleWimble, including their trade-offs and implications for Bitcoin’s scripting system.

Scalability and solvency with extension blocks (01:12:02) Discussion on the potential impact of extension blocks on Bitcoin’s scalability and solvency, including the trade-offs involved.

Social media and contact information (01:14:58) Information on how to keep up with Andrew Poelstra’s work, including his presence on GitHub and IRC.

Andrew Poelstra Explains Covenants in Bitcoin

The concept of covenants in Bitcoin is a game-changer for the way we think about transactions and control over coins. Andrew Poelstra shed light on the limitations of the current Bitcoin script and the necessity for covenants to dictate where coins can move post-transaction. Classic applications, such as vaults for secure long-term storage and exchange withdrawals, were discussed – thus highlighting the practical benefits for users.

However, covenants are not without controversy. Fears of potential misuse and regulatory concerns loom over their implementation. Andrew and I explored these fears, addressing the need for a balanced approach that maximizes utility while minimizing risks.

The Revival of OP_CAT and Its Capabilities

The episode took an intriguing turn when we delved into the disabled opcode OP_CAT. Originally introduced by Satoshi Nakamoto, OP_CAT was removed due to significant issues. Andrew explained the technicalities of OP_CAT and its potential to revolutionize Bitcoin script by enabling arbitrary precision arithmetic and cryptographic operations on signatures.

We also touched on the historical context of disabled opcodes and the implications of reintroducing OP_CAT. The most popular proposals for Bitcoin covenant soft forks, including OP_CTV, O_CAT, and LNHANCE were evaluated, revealing their strengths and limitations.

Andrew Poelstra Explains Why OP_CAT Is A Simple Solution for Complex Needs

Andrew Poelstra emphasized the simplicity and effectiveness of OP_CAT, advocating for its ability to cater to a wide array of needs within the Bitcoin ecosystem. The contrast between OP_CAT and other proposals, such as OP_CTV, was striking – at least in terms of the complexity to utility ratio. also We discussed about the concerns surrounding the adoption of new opcodes.

The potential impact of OP_CAT on various user groups, including businesses, developers, and average users, was a focal point. At around the 43-minute mark, I raised the question of how to communicate the benefits of such technical advancements to those who may not be deeply involved in Bitcoin coding but could still reap the rewards of software development.

The Challenges and Future of Covenants

The conversation took a critical turn as we discussed the limitations and challenges of using covenants in Bitcoin. The 201 opcode limit and the complexity of building covenants with existing tools were highlighted, alongside the need for new opcodes to enhance functionality.

Andrew pointed out the benefits of covenants for ordinary users, especially in the realms of vaults and the Lightning Network. The potential effects on fee markets and user control over transactions were also explored.

Looking ahead, we discussed about some future developments in Bitcoin, such as new opcodes, arithmetic improvements, and first-class covenant support. The challenges and risks associated with sidechains and the debate over various software proposals were also addressed.

Andrew Poelstra On Incentives, Extension Blocks, and MimbleWimble

Andrew Poelstra’s insights into the incentive-based component of Drivechains and the controversy surrounding them were particularly thought-provoking. He expressed concerns about the use of incentives in complex systems and the potential for trolling and griefing.

The technical details and trade-offs of extension blocks and MimbleWimble were explained, along with their potential benefits and drawbacks. Andrew also introduced adapter signatures, which facilitate Lightning on mobile and fast image revelation. This directly showcases how Taproot can enhance Bitcoin’s capabilities.

Personal Perspectives and Contact Information

In the concluding part of our episode, Andrew shared his personal journey in shifting excitement from one proposal to another. His preference for Bitcoin and Taproot was evident, as were his reservations about extension blocks and their potential impact on Bitcoin’s transaction structure.

Andrew also shared his contact information, including his GitHub and IRC presence, alongside Blockstream Research’s Twitter feed. His preference for old-school communication channels resonates with many Bitcoin developers, who value a more direct form of technical discourse.