The protocol is back. No more what ifs or artificial limits. April 7th is a massive line in the sand for BSV. Chronicle gives us the original toolkit, and now it’s up to the builders to show the world why that matters. The foundation is solid; time to go to work.
#BSV #Chronicle
Chronicle activates April 7th.
I want to take a moment to explain why this upgrade matters - not just technically, but personally.
First, huge thanks to everyone involved. The developers who did the actual work, and the community members who contributed to ensuring the scope was as airtight as possible while promoting stability. Maintaining stability while restoring the original protocol was a delicate balance, and the final release reflects all the hard work that went into ensuring that.
Why restore the original protocol?
This isn't just about completion for its own sake. Over the years, a lot of restrictions were added to Bitcoin. And in the same way that central planning can destroy an economy, centrally planning and limiting developer creativity means we have no idea what possibilities the original protocol actually enabled. We know it allowed more flexibility. We imagine that as better Bitcoin scripting engineers emerge and people learn more about the underlying protocol, they'll take advantage of use cases we can't even predict yet. Chronicle removes those artificial constraints. This is the core of the BSV Association's mandate. There should be no central person or group of people that tell you how you can build on top of the protocol.
Original Transaction Digest Algorithm (OTDA)
One of the most significant changes is the restoration of the Original Transaction Digest Algorithm. BSV will now support both the OTDA and the current BIP143 digest algorithm. Developers can opt into OTDA by setting the new CHRONICLE sighash flag (0x20). If you do nothing, existing behavior is preserved - BIP143 continues to work exactly as before. This gives developers the flexibility to choose which digest algorithm fits their use case, whether that's maintaining compatibility with existing systems or leveraging the original protocol's behavior.
Transaction malleability
Transaction malleability has been treated as this big scary problem throughout Bitcoin's history. There were a lot of patches added to Bitcoin over the years specifically to prevent it. But in doing so, they limited developer flexibility significantly.
Here's the thing: transaction malleability itself isn't actually a problem. It was only perceived as one because of how people were doing payments in Bitcoin - which was always wrong. Payments in Bitcoin were always meant to be peer-to-peer, then broadcast directly to the mining network. This is outlined in the Simplified Payment Verification section of the white paper. The work that has been done on all of the development tooling and the BRC-100 standard has enabled users and developers to utilize SPV.
Transaction malleability was a concern based on a misunderstanding of the payment flow, and a misunderstanding of nodes themselves. Because they misunderstood how payments should work and are convinced that miners will behave irrationally, they put in a bunch of restrictions on developers.
And here's the clever part: this is opt-in. Transactions using version 1 keep all existing restrictions. Only transactions with version > 1 get the relaxed rules. Existing applications remain completely unaffected. So if you are reading this and think "no way Connor is right about this" - then you can continue to ensure payments made with your wallet or application are not susceptible to malleability.
Restored opcodes
Chronicle re-instates several opcodes that were disabled years ago. Of note:
• OP_VER, OP_VERIF, OP_VERNOTIF — access the transaction version directly in script
• OP_LSHIFTNUM, OP_RSHIFTNUM — numerical bit shifting (restored to mimic the original behavior of OP_LSHIFT and OP_RSHIFT)
Business continuity
In line with BSV's commitment to stability: if you do nothing, nothing breaks. Existing applications using BIP143 without the CHRONICLE flag remain completely unaffected. The changes are all opt-in. This was deliberate - we needed to restore the original protocol while respecting that real businesses depend on the current state.
Personal note
I've been in BSV since day one. The uniting goal, shared with other community members, was always restoring the Bitcoin protocol and locking it. Set in stone. I'm proud to have played my part in that, and to have been involved in the actual work being done by the developers to enable it.
The work of the Association in doing this restoration is finally done. The protocol Satoshi designed is back.
This is cause for celebration. Let's build.