Chronicle and the 16-year restoration of Bitcoin’s original protocol

The views expressed in this article are those of the author and do not necessarily reflect the position of CoinGeek.

I am an entrepreneur and a journalist in the Bitcoin space, but before any of that, I am a historian. When a moment matters, I notice because I care about Bitcoin’s chronology. When an industry finally delivers something it spent sixteen years promising to deliver, we should all pay attention, so here’s an opportunity to do just that!

At block 943,816, on April 7, 2026, the BSV mainnet activated its most philosophically significant protocol change since Genesis [chronicle.bsvblockchain.tech]. Chronicle restores the last of the original Satoshi opcodes, reinstates the Original Transaction Digest Algorithm, raises the script number limit from 750KB to 32MB, and selectively strips away the malleability handcuffs that BTC Core bolted onto the protocol over a decade ago.

Put plainly, this is the closest the Bitcoin protocol has come to what Satoshi shipped in 2009 since the opcodes were yanked from the reference client in 2010.

The parentage problem

Every living protocol has a family tree, and Bitcoin’s is messier than most people want to admit.

Bitcoin 0.1 launched on January 9, 2009, the day after Satoshi announced it on the Cryptography mailing list. The client shipped with a rich scripting language. String opcodes (OP_SUBSTR, OP_LEFT, OP_RIGHT), arithmetic opcodes (OP_2MUL, OP_2DIV, OP_LSHIFT, OP_RSHIFT, OP_MUL, OP_DIV, OP_MOD), bitwise opcodes (OP_AND, OP_OR, OP_XOR, OP_INVERT, OP_CAT), and version opcodes (OP_VER, OP_VERIF, OP_VERNOTIF) were all live and usable.

Then the panic came. In July 2010, CVE-2010-5137 exposed a crash bug in OP_LSHIFT. The patch landed in Bitcoin 0.3.5, and in the versions that followed, a broad sweep of opcodes was disabled out of caution. The Bitcoin Script wiki is blunt about why: opcodes were removed “out of concern that the client might have a bug in their implementation.” The full programmable Bitcoin palette was stripped down because the dev team was afraid of their own code. Version 0.3.4 is the last time a released reference client could halve a number natively or branch on the transaction version. Sixteen years ago.

BTC Core is the name that crystallized with version 0.9.0 on March 19, 2014, when the reference client was formally renamed from Bitcoin-Qt. By then, the protocol had been chained to a 1MB block size and aimed at becoming a settlement layer for a future L2 economy that never arrived.

BTC ABC split off on August 1, 2017, at block 478,559, creating Bitcoin Cash with an 8MB block cap and an on-chain scaling thesis. ABC was led by Amaury Séchet and bankrolled by Bitmain’s Jihan Wu. It broke the stalemate, but it did not restore the full script set, and bickering ensued quickly thereafter in the BCH economy.

Bitcoin SV was maliciously split from BTC Cash on November 15, 2018, via a checkpoint scheme in the ABC client during the infamous hash war. SV stood for “Satoshi Vision.” The team, at the time, made an explicit commitment: restore the original protocol and let developers actually build what the opcodes were written for in the first place.

Quasar activated on July 24, 2019, lifting the default block cap to 2GB and confirming the network could handle it by mining six consecutive 2GB blocks shortly after.

Genesis activated on February 4, 2020, at block 620,538. Genesis did the heavy lifting: it restored OP_CAT, OP_SPLIT, OP_AND, OP_OR, OP_XOR, OP_MUL, OP_DIV, OP_MOD, OP_LSHIFT, OP_RSHIFT, OP_INVERT, OP_NUM2BIN, and OP_BIN2NUM. It removed default block size caps and deleted P2SH entirely. Most of the script limits that Bitcoin Core had imposed got reset at the same block. Genesis is the moment BSV became programmable again.

But Genesis left four opcodes still disabled: OP_2MUL, OP_2DIV, OP_VERIF, and OP_VERNOTIF. It kept BIP143 as the only transaction digest algorithm, because the original digest had taken the blame for transaction malleability for years. And it kept the malleability-era stack and encoding rules in place.

Dynastic deserves a footnote. It was not a protocol upgrade. Dynastic was the name given to SV Node software version 1.0.7, released in February 2021, which extended ancestor transaction chains from 25 to 1,000 and untangled architectural cruft inherited from BTC Core. It was a node software milestone, not a consensus rule change. Worth knowing if you are telling the history honestly.

Back to the top ↑

Chronicle is the consensus change that Genesis did not finish.

What Chronicle actually does

Four things, all of them philosophically loaded.

First, the Original Transaction Digest Algorithm (OTDA) is back. Developers can now opt into the pre-BIP143 digest by setting a new CHRONICLE [0x20] sighash flag. BIP143 still works. Nothing existing breaks. But if you need the structural properties of the original algorithm, you can have them back.

Second, script numbers can now be up to 32MB, up from 750KB. That is a 42x expansion. It is the consensus-layer change that quietly enables the biggest swing: on-chain cryptographic verification of arbitrarily complex constructions. Very cool!

Third, six malleability restrictions are removed for transactions with a version number greater than 1. Minimal encoding, Low S, NULLFAIL/NULLDUMMY, MINIMALIF, clean stack, and the “data only in unlocking script” rule are all optional when your transaction version is 2 or higher. Version 1 transactions keep the old rules. Developers opt in.

Fourth, the last disabled Satoshi-era opcodes come back. OP_VER, OP_VERIF, OP_VERNOTIF, OP_SUBSTR, OP_LEFT, OP_RIGHT, OP_2MUL, and OP_2DIV are restored, and two new shift opcodes, OP_LSHIFTNUM and OP_RSHIFTNUM, round out the bit manipulation toolkit.

Back to the top ↑

What becomes possible

This is where most writers start making things up. I will not.

The most concrete use case is already under construction. On July 19, 2024, the nChain cryptography team deployed a Groth16 zkSNARK verifier on BSV mainnet using the BLS12-381 curve. The locking script ran 480KB, the unlocking script 40KB, and each verification cost about $0.015, [ESORICS 2024]. The team explicitly stated that recursive Groth16 was the next goal. Recursive SNARKs verify proofs of proofs, and they are the building block for scalable zero-knowledge applications. Chronicle’s 32MB script number ceiling is the change that removes the operational constraint that made that work painful.

The only novel use case publicly named by BSV leadership is overlay network versioning via OP_VER. Connor Murray, Director of Stewardship at BSV Association, stated that OP_VER lets developers “build overlay-type networks and transactions” by giving locking scripts a native primitive for branching on the spending transaction’s version. BSV already relies on overlay services for tokens and data, and OP_VER turns versioning from a social convention into something enforced on-chain.

OP_CODESEPARATOR in unlocking scripts was already demonstrated by the sCrypt team to cut sighash preimage size by up to 80% in certain contract patterns, before Chronicle even landed. Chronicle expands on where and how this optimization can be applied, because functional opcodes are now legal in the unlocking script.

Beyond those, the ground is unclaimed, and that is the interesting part. While none of this has been publicly explored, things like on-chain JSON field parsing using OP_SUBSTR and RSA accumulator membership proofs leaning on the new 32MB script number ceiling could be interesting uses of the new primitives and the new space to work with. Nobody has published a proposal yet. Chronicle is just hours old as I write this, so the interesting work is in front of us.

Back to the top ↑

Why this matters, and what you should do about it

Chronicle is the end of a fifteen-year apology. In 2010, a small handful of developers panicked about bugs and chose caution over capability, which was maybe reasonable at the time, but became malicious as Bitcoiners were told just to ignore the original capabilities of “The Internet of Money.” That single decision shaped every year that followed. The scaling debates, the L2 detours, the whole “Bitcoin is digital gold” consolation prize all flow downstream from that choice.

Chronicle undoes the choice.

But, and this is a BIG BUT, consensus rule upgrades and protocol restoration are meaningless if nobody builds with them. A restored opcode that nobody uses is a museum piece. A restoration that does not disrupt the real economy is a ceremony dressed up as progress.

If you are a developer, build something on Chronicle that could not be built on any other chain. If you are an entrepreneur, find the business problem that actually needs a 32MB script number, a restored OTDA, or an overlay network with on-chain versioning, and solve it. If you are a miner, sell the new capacity to customers who need it instead of treating it as a risk surface. If you are an investor, stop waiting for the next narrative and put capital into teams that are building on the only Bitcoin protocol that ever got to run the full Satoshi toolkit.

Chronicle is live, and the excuse bank is empty.

Be good to each other. And go build something with the tools we finally have back.

This opinion piece is published to encourage discussion. The author’s views are their own and do not constitute legal, procurement, or policy advice, nor do they represent the positions of CoinGeek or its partners.

Back to the top ↑

Watch: Bitcoin’s Ultimate Use Case Explained

title=”YouTube video player” frameborder=”0″ allow=”accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share” referrerpolicy=”strict-origin-when-cross-origin” allowfullscreen=””>