Blockspace had boots on the ground this past week Austin, Texas for BTC++, a technical Bitcoin conference that attracts the brightest developer minds across the Bitcoin ecosystem.
The theme of the conference? “Bitcoin Script”. Most users on Bitcoin don’t know what Bitcoin script is, but you’ll definitely be hearing a lot more about it this year, because Bitcoin developers are in the early stages of discussing changes to Bitcoin script which would result in a soft fork.
It has been over 3 years since Bitcoin soft forked with the Taproot upgrade. Since then it has been difficult to get broad developer consensus on what might be next for Bitcoin, meanwhile the don’t-change-anything-ever-again (“ossification”) crowd seemed to have dominated the narrative…. at least until this past week.
The devs might actually “do something” this time. There is conversation around bringing back some Bitcoin script that Satoshi themselves once had in Bitcoin, and possibly adding some new ones.
For the layperson, Bitcoin Script is the code that builds the logic of the transaction. Script dictates how a transaction works, where it goes, what it can (and can’t) do. “Opcodes” are the commands & functions that power Bitcoin script.
Specifically, the conversation this past week was surrounding adding opcodes, or new functions, into Bitcoin script. The opening talk by Rusty Russell was appropriately called “The Great Script Restoration Project”.The conference was kicked off with a proposal to “bring back scripts”
There are over 100 opcodes in Bitcoin script, but Satoshi originally included more opcodes in the early days. Satoshi removed some opcodes for various technical or security reasons. Rusty’s proposal is to bring back those opcodes which would require a soft fork.
Why is this a big deal? Bitcoin soft forks & hard forks are often contentious to say the least. Forks require broad support across multiple stakeholders in the Bitcoin ecosystem. Typically, a soft fork would begin as a discussion among developers but then have to be accepted & endorsed by a majority (or supermajority) of miners, users, other stakeholders. To oversimplify, a soft fork stakeholder process might look like developers → miners → users.
The limitation for additional forks the past several years has primarily been that all proposals couldn’t even get into the “developer” stage. This is because developers haven’t been able to agree on anything for one reason or another. Take a look at the Taproot Wizard’s “BIP Land” project for a window into the confusing & difficult process to even bring new ideas into the discussion.
Developers aren’t in total agreement, it just looks like discussion is actually moving forwards. Sometimes you just have to get everyone in the same room and united towards a common goal. Our assessment of this past week is that most Bitcoin devs want to change Bitcoin and most devs are willing to consider accepting “big tent” changes to Bitcoin script — changes that accomplish something productive towards the multitude of different goals developers are championing. Yes, this probably looks like OP_CAT. But it may also look like OP_CTV or LNHANCE. It is unclear how the discussion will progress.
Our main takeaway is that the discussion is actually progressing forwards for the first time in years and it no longer looks like a pipe dream to pass the first hurdle of “broad developer support for a Bitcoin soft fork”.
Of course, Blockspace will be covering this story very closely this year. We will talk to the devs and translate for the Bitcoin miners + users. It’s a very exciting time to be in Bitcoin!
