Four takeaways from OP_NEXT

12 November  2024 · Block Height 869953 · Bitcoin Price $87k (!)

Welcome back to the Blockspace Newsletter!

We’re recovering from our Bitcoin Scaling conference OP_NEXT, which we hosted last Saturday in Boston. And we’re beyond happy to hear feedback from attendees and speakers that it was quality programming and generated much-needed discussion – to all of those who attended and tuned in to the livestream, and to all of our sponsors, a huge THANK YOU!

We’re in the process of turning around the presentation and workshop recordings for our website this week, but in the meantime here are some of our initial key takeaways from the conference:

OP_CTV has near-universal support from developers

Jeremy Rubin’s OP_CHECKTEMPLATEVERIFY (CTV) “hasn’t really changed much in the past 4 years,” as he said during his presentation, but despite a failed campaign towards activation the covenant opcode continues to gain explicit support from developers. 

Even Peter Todd said “I actually don’t think CAT is the most popular opcode, I would argue CTV is,”during one of the conference’s closing panels. This makes sense – covenants are one of the most preferred scaling solutions right now and CTV checks all the boxes for narrowly defined covenants with little to no downsides. In fact, Rusty (Blockstream), Jay Beddict (Foundry), and Peter Todd all agree that concerns over CTV being used as a tool by entities which seek to control Bitcoin users are very misguided; not only is such an attack useless since CTV does not enable recursive covenants, but such an attack is less rational than methods currently available today.

Activation itself is probably more controversial than specific soft fork proposals

Almost everyone has something negative to say about previous activations, particularly Segwit and Taproot. Going even further than that, there was little-to-no agreement during the conference on what future healthy activation would look like. As Reardencode said, “[a soft fork] doesn't have consensus because it doesn't have consensus. Why doesn't it have consensus? Because it doesn't have consensus.”

To recap some of the discussions on this topic:

• Everyone agrees a soft fork needs widespread consensus

• Nobody agrees how we measure this consensus or how this consensus is supposed to arise

• Somehow, someone is supposed to try to build consensus, but at the same time nobody should pick up the mantle to try  – a frustrating catch 22

OP_CAT is going to happen whether we softfork or not

OP_CAT is so broadly useful that whether or not we get a soft fork it appears the wheels are already in motion to emulate it. Both through Bitcoin PIPEs and the recently published (but absurdly impractical) Collider Script research, OP_CAT and some other covenant opcodes are possible today if you have time and money. TL;DR: we can use fancy math and computers to accomplish the same things CAT does without a soft fork. 

The question is, who has the money or incentive to chase this rabbit cat? Multiple attendees at the conference claimed that the use of CAT is so desirable that the cost to emulate it is not a barrier. For example, Starknet spends upwards of $20 million per month in fees to Ethereum and doing comparable activity on Bitcoin with an “expensive” CAT emulation would probably be cheaper.

The role of developers is to propose softforks, but it’s controversial if they advocate for those forks

As Rusty Russell said during the panel on activation, “developers are naturally in the driver’s seat because we have a dominant reference implementation.” He said that, while Bitcoin Core developers may not drive soft forks, the can de facto veto them. We see this reflected both in history and the modern discourse: historical forks have been developer-led and attempts to fork that were not developer-led (Bitcoin Cash) resulted in a chain split. Currently, most soft fork discussion continues to be localized mostly to developer-heavy circles with the recent exception of OP_CAT, which has crossed the chasm into widespread retail support due to the Taproot Wizards campaigning.

However, opinions diverge on whether developers should take an active role in promoting their ideas. Look no further than Jeremy Rubin and CTV. CTV, while resoundingly popular today, received harsh pushback both on the proposal and arguably moreso on Jeremy himself, as Jeremy emphatically explained in his presentation. Ethan Hileman, OP_CAT coauthor, said during the conference that his “job is just to come up with proposals and educate on them,” indicating that he thinks it’s best for developers to stay out of soft fork campaigning (and Ethan largely has – most OP_CAT discussion we see are focused on the proposal, not Ethan and Armin, the coauthors of the BIP to reactivate the opcode).

If you liked this newsletter, please give it a share and reply with “OP_NEXT”!