Grassroots Support for Bitcoin Improvement Proposals

Grassroots support for two Bitcoin Improvement Proposals (BIPs) appears to be emerging for Bitcoin’s next soft fork, centered around two candidates: BIPs 119 and 348.

BIPs are the formal method for discussion of proposed changes to Bitcoin. Theoretically, if a BIP gains sufficient widespread support, it will be added to Bitcoin via a soft fork or a routine update to Bitcoin Core. Often, these BIPs are referred to by nicknames and multiple proposals may be included in a soft fork. BIP 119 refers to OP_CHECKTEMPLATEVERIFY (CTV) while BIP 348 refers to OP_CHECKSIGFROMSTACK (CSFS).

This article first appeared on Blockspace Media, the leading Bitcoin industry publication dedicated to covering Bitcoin tech, markets, mining, and ordinals. Get Blockspace articles directly in your inbox by clicking here.

Bitcoin’s technical community typically debates these BIPs exhaustively. The Taproot Wizards, a Bitcoin development firm most well-known for its Bitcoin NFTs, put out a helpful graphic explaining the confusing and seemingly circular process of these discussions.

In short, the Bitcoin soft fork process requires a rough estimate of support from Bitcoin’s stakeholders, including developers, custodians, investors, and miners. The best proxy for this stakeholder support remains Bitcoin miners, who can flag support for an alteration to the codebase by signaling for changes in their mined blocks. Typically, Bitcoin Core asks for 95% of blocks over a period to signal for the change before locking in the update for activation.

Still, there’s no definitive heuristic for defining what “widespread support” looks like, and Bitcoin consensus is a constantly evolving, moving target. Miners are useful for signaling a change only because they are a truly ‘countable’ entity on the Bitcoin network. In other words, it’s difficult to gauge broad world consensus given Bitcoin’s decentralized structure.

Over the course of February and March, we’ve registered a definite shift as numerous developers gave their explicit support for the two BIPs.

What’s in a proposal?

Over the course of the last few weeks, numerous Western Bitcoin developers tweeted their support for CTV and CSFS—strong signals that at least the Twitterverse is coming together in favor of certain changes to Bitcoin.

CTV and CSFS allow new ways of writing Bitcoin script. Bitcoin script is Bitcoin’s lower-level programming language used for, among other things, creating and sending transactions. Proposed by former Bitcoin core contributor Jeremy Rubin, CTV has been around for more than half a decade, whereas CSFS was only formalized in November 2024 by Jeremy Rubin and Brandon Black.

These two BIPs would enable “covenants” on Bitcoin, which restrict how a wallet can spend bitcoin in future transactions. Covenants are generally expected to significantly improve the landscape for Bitcoin self-custody, fee management, and enhance existing Bitcoin tech like Lightning, Ark, and contract-based applications.

Additionally, developers consider these two proposals to be “narrowly defined.” In layman’s terms, this means, if activated, there is a low probability of users exploiting them for something unexpected. The Bitcoin developer community tends to cautiously deliberate any changes to Bitcoin. For instance, BIP 119 has remained unchanged for nearly half a decade, but there was a time not long ago when CTV was considered too aggressive for activation.

A long time coming

You may remember that Rubin’s prior campaign for CTV received strong pushback from Bitcoiners with large followings, including Adam Back and Jimmy Song. The criticisms evolved into significant resistance from many in the Bitcoin community, leading Rubin to take a step back from Bitcoin altogether.

So what changed? Recent advocacy for the OP_CAT opcode (BIP 347) seems to have widened the Overton Window of acceptable Bitcoin proposals, framing CTV & CSFS as comparatively “conservative” options. Most OP_CAT supporters are also in favor of BIPs 119 and 348 (and most proposals in general).

What can we expect next?

For one, more conversation. Developers are expected to gather at a few technical conferences such as OPNEXT in April, BTC++ in July, and TABConf in October. Once developers begin to form rough consensus, then the actual activation of the soft fork moves to the miners, community, and investors.

However, there isn’t a formalized process for “how to soft fork Bitcoin.” We are left with many open questions. For example, will a potential soft fork include just CTV and CSFS? Will OP_CAT, often included in this opcode suite, join the conversation? How will an actual soft fork activation happen? And will other stakeholders like Bitcoin miners take note?

Only one thing is clear: you’re going to have to get comfortable with lots of abbreviations.