Four takeaways from our Bitcoin Scaling conference, OP_NEXT
Here's our initial insights on what developers discussed at our scaling conference 🧵 subscribe below to read the full newsletter this morning!
✅ OP_CTV has near-universal support from developers
@JeremyRubin'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
@peterktodd said “I actually don’t think CAT is the most popular opcode, I would argue CTV is”. 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.
@rusty_twit @Blockstream,
@JBeddict of
@FoundryServices, 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.
✅ Activation itself is probably more controversial than specific soft fork proposals
Everyone has something negative to say about previous activations, particularly Segwit and Taproot. Also there was little-to-no agreement during the conference on what future healthy activation would look like. As
@reardencode put it -- to have consensus we need consensus 💀. 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
The wheels are already in motion to emulate it. Both through Bitcoin PIPEs (
@nemothenoone) and the recently published (but absurdly impractical) Collider Script research (Poelstra,
@Ethan_Heilman, Viktor & Avihu
@StarkWareLtd), 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.
Are these methods practical? It probably depends. Our takeaway is that CAT may be so desirable to certain groups that the cost & impracticality may not matter.
✅ The role of developers is to propose softforks, but it’s controversial if they advocate for those forks
“Developers are naturally in the driver’s seat because we have a dominant reference implementation.” - Rusty Russell.
While Bitcoin Core developers may not drive soft forks, they can de facto veto them. 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.
Opinions diverge on whether developers should take an active role in promoting their ideas. Look no further than
@JeremyRubin 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
@Arminsdev, the coauthors of the BIP to reactivate the opcode).