No, the protocol is not locked

Getting your Trinity Audio player ready...

i’m making this

the stable protocol is too important for there to be any confusion over what should be included

i’ll pay $10 per change that still needs to be reverted/unfucked in BSV

list them below https://t.co/7OJKRieOaJ

— syn·fo·naut (@synfonaut) January 4, 2021

Recently Brad Jasper aka @synfonaut started a list of all the pending changes needed to truly revert to the original Bitcoin protocol v0.1. Technically the Bitcoin SV protocol is not locked, despite the assertion being repeated ad-nauseam. In this article I will review those pending changes, some detail and history behind them, but why this fact is not something developers should be worried about when it comes to building on BSV.

Difficulty adjustment algorithm

This is the most radical change from Satoshi’s original protocol and the one that has had profound effects on miner incentives since its modification by BCH developer Amaury Sechet in August 2017. I have written about this in the past. On Brad’s repository, Dean Little adds more reasons why it should be reverted (especially now with the ancestor limit raised):

SIGHASH_FORKID

The second most impactful deviation is the addition of a FORKID in the sighash algorithm which adds replay protection, ensuring that transactions spent on BCH would not necessarily need to be spent on BTC. This was another French man special that likely has had unforeseen consequences. Adding replay protection could be interpreted as an admission of defeat by BCH at the time. This move allowed transactions to be broadcast selectively on either chain, ensuring a permanent split persisted.

Additionally, if any offline transactions were created with the nLockTime feature prior to August 2017, then those transactions are now un-spendable on the BCH and BSV chains. The implications are quite interesting given a certain Australian’s fascination with nLockTime, offline transactions and trusts.

Opcode changes

Lastly several opcodes are still disabled. The most mysterious of which is OP_VER, whose purpose is still largely unknown. In the slide below Craig Wright presents that it could be leveraged to implement ‘secondary consensus’ rules (custom opcodes?) which is fascinating considering that one of the huge topics of debate was over an opcode (OP_CHECKDATASIG) during the BCH/BSV split may have been totally unnecessary!

Along with OP_VER, OP_VERIF and OP_VERNOTIF are also going to be re-enabled in the Chronicle update. Two more opcodes, OP_2MUL and OP_2DIV are supposedly going to be re-enabled but are unnecessary as the same functionality can be replicated by using OP_MUL or OP_DIV (multiplication and division) of any value by two (OP_2).

what does it mean for the BSV protocol to be stable?

— syn·fo·naut (@synfonaut) January 4, 2021

In conclusion, the above changes will eventually need to be implemented but for the purpose of the ‘set in stone’ narrative, the protocol is just that. My definition mirrors with Elas Digital’s statement below:

That the network's rules never change in such a way that something I built ceases to function in the way I built it.

— Elas (@elas_co) January 5, 2021

Each of the changes I have reviewed may impact different parties in various situations but will not disrupt any businesses being built today in the future. If anything, these restorations can only increase the possibilities of what can be built on Bitcoin, not take away. The future Chronicle update does not yet have a date, but is anticipated to unlock even more potential from Bitcoin.