My final thoughts on BIP-110:
TL;DR: I believe BIP-110 activating smoothly is preferable to and less disruptive than a hard fork away from the network. I hope 110 activates smoothly in the coming days, but I will not follow a hard fork away from Bitcoin if it fails. I will remove BIP-110 from my handle, admit I was wrong, and move on.
I also advise everyone not to submit transactions that are likely to be mined in the blocks immediately after activation to minimize the potential for disruption or undesired outcomes.
I went from supporting 110 to opposing it, back to supporting again. Here's why:
I've always seen something wrong with arbitrary data on Bitcoin, and I've been intuitively against the need to grow adoption through new use cases. At the same time, I really felt that Bitcoin Core overstepped their mandate by changing the OP_RETURN default in v30, and I largely agree with Hodlonaut's assessment of that saga in his article series on the topic.
BIP-110 felt like a real way to influence the network back towards one that repudiates arbitrary data and doesn't leave node developers free reign to make changes to the protocol as long as there is no change to consensus code. I was involved in early discussions on the soft fork, and started running the client when it became available on Start9.
Still, I never felt that 110 was perfect. I thought it was incongruous for every limit to be set at 256 bytes except for OP_RETURN itself, and that it would be more consistent to apply a 256 byte limit there, also. Banning OP_IF and therefore breaking some functionalities of Miniscript also never seemed ideal, and I would have preferred finding a way to avoid that. Still, a fix to avoid OP_IF in Tapscript has been produced, so it's completely possible to avoid that disruption. Compromise and attempting to better achieve consensus would have been preferable to me.
I had conversations with many people, supporters and opponents, for months. I realized that much of my position came from my industrial cybersecurity experience, and the idea for my Bitcoin cybersecurity book, Defending Bitcoin, was born. I spent 6 months writing that book, and I'm proud of it. I just released it for free as a response to the Coldcard hack. I firmly believe in the importance of Bitcoin security education, and I hope my contribution is valuable to the space. For me, no matter what happens, this book was born from 110, and I'm glad it exists.
In the process of writing Defending Bitcoin, I evaluated the consequences of forks and chain splits on Bitcoin, and what these events look like from a risk perspective. These events are chaotic, messy, and potentially disruptive. Avoiding a chain split at all costs became my overriding position.
At the same time, I saw that consensus wasn't forming. Multiple groups of opposition have formed. One is technical, objecting to disruptions to applications using the restricted functions and to the limits on scriptability. Another is more philosophical, arguing that any restriction on "valid transactions" would constitute censorship. Yet another group was concerned mostly about the implications for Bitcoin's governance, what it would mean if a minority can force a change to Bitcoin.
I currently push back against all of those categories of objections, which I'll get to in a moment, but the bottom line is that I saw serious opposition emerging. Certainly not consensus. I was writing a book on risk analysis where I argue that a chain split or a fork without consensus is chaotic, messy, and risky. That's where I pulled my support for 110, and began advocating against following it. Bitcoin Mechanic said at one point that either 110 would succeed spectacularly or it would fizzle out quickly. I saw fizzling out quickly to be more likely and less disruptive than a prolonged fork scenario.
Still, my "opposition" was somewhat half-hearted. I still agreed with the goals of 110, and I disagree with many of the arguments against it. I never stopped running Knots with 110, mostly out of inertia. But, publicly, I did not support 110. I focused on finishing my book, and I got to have conversations with many 110 opponents with perhaps more clarity and willingness than if I were a 110 supporter.
After my book launched, however, I turned back towards the 110 debate and discussion. I re-evaluated the situation, and, just as there was staunch opposition, there were staunch proponents. Just as I spoke to opponents over the preceding few months, I also met many plebs who were running 110 for one reason or another. BIP-110 wasn't going anywhere, and that realization changed my thinking.
My Current Game Theory View
The entire proposition of 110 is that the miners will be compelled to signal by nodes threatening to throw away their blocks. One option involves risk of wipeout, and the other doesn't. That's the choice miners are faced with.
There also isn't any opposition in code. No URSF doesn't mean there's no opposition, or that there is consensus for 110. But it means that miners have no side saying "I'm going to reject your blocks if you signal for 110".
Therefore, either the nodes enforcing 110 with the economic weight backing them is enough to convince the miners to signal and comply, or it isn't. BIP-110 will still either succeed or fail spectacularly and quickly. It will never catch up if it falls behind. Bitcoin isn't the longest chain. It's the longest chain of valid, accumulated proof-of-work. If the non-110 chain takes the lead and has majority hashrate, it's never giving it up.
Meanwhile, now there is talk of a proof-of-work change and a forced hard fork if 110 doesn't succeed in activating and becoming the longest chain. In the category of potential disruptions, I put that above all else.
Why A Hard Fork Would Be Bad
A hard fork off of Bitcoin would be terrible for the network. It would be centralizing in all possible metrics.
All nodes that follow the fork or turn off would be a loss for the Bitcoin network. That's a centralizing factor.
All plebs would had been mining and building their own blocks who choose to follow the fork or simply stop mining will no longer be mining on Bitcoin. That's a centralizing factor.
And, finally, all the monetary maximalists who believe Bitcoin's monetary properties need to be defended against use-case creep and crypto affinity scams who either follow the fork or decide to otherwise stop participating in Bitcoin would give up Bitcoin's governance to David Bailey, Michael Saylor, and the Core-industrial complex. That's a centralizing factor.
For all these reasons, I believe a hard fork is a bad outcome, and, therefore, 110's smooth activation is preferable.
Arguments Against Arguments Against 110
I said above that I disagree with most arguments against 110. I'll briefly state my counterpoints, just for the record.
First, the technical objections. Largely, these consist of opposition to "breaking" Miniscript, and opposition to limits on data embedding for scripting purposes. As mentioned, there's a fix to the Miniscript problem. Scripting limits is a more meta question and a bit of a philosophical difference.
Many of the developers I've spoken with want a large explore space to discover potential use-cases for Bitcoin. Murch recently described the situation as (light paraphrasing) "if Bitcoin is exciting to develop cool smart contracts, there has to be data embedding". In my view, and many others in the pro-110 camp, Bitcoin doesn't need to be "exciting" for developers. It needs to be functional money.
I attended Bitcoin++ in Vienna and was on a panel with Seedor Chris, Knut Svanholm, Matt Corallo, and Tiero, where we agreed that the vast majority of users just want to take their Bitcoin into self-custody and use it to pay for things. There is plenty of work to do to make taking self-custody easier, as we saw with the recent, massive Coldcard breach, and make medium-of-exchange better, as we saw with the shutdown of Boltz.
So, I don't agree that Bitcoin needs massive explore space on the base layer. Furthermore, I believe that practical limits are a positive security control to reduce attack surface and to reduce the viability of arbitrary-data embedding on Bitcoin. Ultimately, all security requires tradeoffs. It might become slightly more difficult to create "exciting smart contracts" on Bitcoin with BIP-110's rules, but those limits would serve other purposes.
Regarding the objection that BIP-110 threatens Bitcoin's censorship-resistance and permissionlessness, I believe that this is a total red herring.
BIP-110 doesn't prevent anyone from transacting, from moving UTXOs from one address to another. BIP-110 also does not introduce a third party you ask permission from in order to transact. In fact, Bitcoin's permissionlessness is a bit misleading. While it's true that you don't ask permission of anyone to transact on the network, you absolutely ask permission of the nodes to accept your transaction, and you ask permission of the miners to include your transaction in a valid block.
In other words, you always have to follow the rules of the protocol. And, if the network chooses to adjust those rules so that certain transaction patterns aren't allowed, you need to follow those rules in the future.
There's also a security angle here. If Bitcoin cannot roll back or restrict any "currently valid" transaction type, Bitcoin will eventually be killed by the unforeseen consequences of some future upgrade. Taproot has been in place for over 5 years, and its negative consequences were apparently after less than 2 years. More than 99% of Taproot outputs are dust. The outcome of Taproot is clear: it's primarily being used for data embedding activity that has nothing to do with Bitcoin's monetary purpose. Rolling back some of the unrestricted data embedding capability of Taproot is a perfectly valid security response, especially after multiple years.
Finally, addressing the governance question: this is the objection that convinced me the most in preceding months. Voices like Giacomo Zucco and Samson Mow have argued that the precedent set by BIP-110 would be bad for Bitcoin in the long term. That a minority being able to change the network without widespread consensus would be viewed negatively.
My response and pushback here is that users are running software. If some minority percentage of nodes running new software is enough to convince the miners to signal and comply with the new rules, then that's Bitcoin's consensus mechanism working as designed. The precedent might not seem nice, but it was entirely within the realm of possibility.
Put another way, if BIP-110 succeeds, we'll learn that there is some threshold of nodes with some amount of economic weight that is enough to get miners to comply with their new rules. If there are future soft-fork proposals that portions of the network disagree with, they'll need to object in code and run a URSF.
What If 110 Fails?
I fully acknowledge that it's possible for the miners to simply not signal. BIP-110 will be dead in the water if it maintains the current signaling past the activation point.
A large part of the argument that 110 will succeed is based on the precedent from the block size wars, where BIP-148 succeeded in compelling miners to activate SegWit. But, if 110 doesn't succeed, we will have learned that the lesson from 2017 was something different.
In 2017, the miners tried to force a block size increase on the nodes, agreeing to adopt SegWit, but only if paired with a 2x block increase. The nodes, through BIP-148, rejected that increase, and insisted on SegWit's activation regardless. SegWit has broad consensus at that point, even with miners. Later, Bitcoin Cash implemented the block size increase and forked off from Bitcoin. The nodes rejected the change, they didn't necessarily force a change themselves.
If 110 fails, it will be because the miners can reject a change proposed by a minority of nodes. 110 proponents will need to similarly conduct their own hard fork and form a new chain if they want to enforce their rules into the future.
Bitcoin will have proven its resistance to change, again. And that, I believe, is the only silver lining here.
However, I won't be happy to see many bitcoiners I respect choosing to abandon Bitcoin and follow a hard fork off the network. Many of them say that it's the rest of the chain forking off. I reject that framing. A minority changing the rules to get rid of the proof-of-work algorithm and reject all the ASICs currently mining Bitcoin is a new chain. They can say that it's more true to Bitcoin's purpose, but it won't be the canonical Bitcoin. I don't think there's any value in pretending that the outside world will view the fork as Bitcoin's successor. Engage honestly with reality.
I won't be following a hard fork away from Bitcoin. I don't know that I'll have the same enthusiasm to engage with Bitcoin from that point forward, especially if many people from the space that I respect choose to leave.
This is another reason why I'm happy that I produced Defending Bitcoin when I did. I hope that contribution ends up being valuable to bitcoiners regardless of the outcome of this fork. Even if I step back from contributing to Bitcoin education or adoption, that book will be out there.
What To Do At Activation Day
My concrete advice is to avoid transacting leading up to the activation height and through until we have clarity. I don't believe that clarity will take long. Either 110 will get overwhelming, essentially unanimous support immediately, or it will maintain its current level of hashrate and be dead in the water. That's a prediction. It's possible it takes longer to resolve. But I believe it will be quick.
Then, once we know the outcome either way, move on. Transact as normal. Either BIP-110 is in effect for a year, or it isn't. I will be turning my attention 100% to BTCHEL just around the corner, and after that, who knows? BIP-110's outcome will likely have a lot to do with my plans going forward.
Regardless of anything else, I'm going to be glad for this all to be over.
