Bitcoin Zero-Knowledge Proofs Are Not Real (mostly)
What does it mean to verify a zero-knowledge proof on Bitcoin? We explore that + more in this week's issue.
Welcome to BitcoinFi Weekly. We cover where people use their BTC and what is changing in the Bitcoin world.
On this day, sixteen years ago, in the shadow of the greatest financial collapse of our generation, an anonymous internet user named Satoshi Nakamoto uploaded a whitepaper detailing a peer-to-peer electronic cash system called Bitcoin. What began as a vision for trustless currency has since spurred a revolution in finance, a whisper turned thunder, reverberating through economies and ideologies alike. Yet, as Bitcoin has grown, so too have the complexities and challenges of scaling it to serve a global population. Today, many herald zero-knowledge proofs as the key to Bitcoin’s next frontier, but the term “zero-knowledge” itself often rings hollow—a buzzword shrouding the simple desire for succinctness and efficiency.
This week, we explore what true zero-knowledge means for Bitcoin, examining implementations across StarkWare, BitcoinOS, and Citrea. We also catch up on major developments in everything BitcoinFi.
Vamos.
Here’s this week’s rundown:
🕵️♂️ Feature Piece: Bitcoin Zero-Knowledge Proofs Are Not Real (mostly)
🚀 tBTC Usage Across DeFi Rockets
⚡️ Stacks Nakamoto upgrade is Live
🌐 Nomic Launches BTC Staking Contract
Feature Piece: Bitcoin Zero-Knowledge Proofs Are Not Real (mostly)
Bitcoin’s limited scripting language and low transaction throughput make expanding the goal of global adoption a Herculean task. This reality has driven intense interest in scaling solutions, with zero knowledge proofs (ZKPs) emerging as a particularly promising avenue. However, the distinction between true zero-knowledge proofs and their cousin, succinct non-interactive arguments of knowledge (SNARKs), raises important questions about what's actually achievable within Bitcoin's constraints.
The Necessity of Scaling Bitcoin
With Bitcoin’s roughly 7-13 transactions per second capacity, each of the world's eight billion potential users would only execute two lifetime transactions if everyone adopted Bitcoin right now. Bitcoin layer 2s have proliferated to address this, yet Bitcoin’s foundational limitations make building a truly trustless, scalable layer 2 challenging. Introducing ZKPs could theoretically allow validity rollups on Bitcoin, verifying transactions without revealing private details, and offering a path to enhanced scalability and privacy.
However, integrating ZKP verification into Bitcoin’s mainnet is easier said than done. Bitcoin’s scripting language presents significant limitations for implementing any form of proof verification. This stack-based system only supports basic 32-bit arithmetic (addition and subtraction), lacks multiplication capabilities, and cannot concatenate stack elements—core functions required for ZKP. For instance, even a simple multiplication of two 254-bit integers requires a script of 77,000 bytes, just a fraction of the script size a complete proof verifier would need. Since Bitcoin blocks can contain a maximum of 4 MB in data, such operations would quickly exceed allowable script sizes. These constraints mean that verifying proofs directly on Bitcoin would be infeasible without major changes.
To implement these modifications, new OP_CODES would need to be introduced to Bitcoin’s codebase. OP_CAT, for example, would allow covenants and make verifying Merkel proofs in Bitcoin Script more practical. OP_CAT remains controversial due to its potential to increase MEV.
Verifying SNARKs on Bitcoin
The main reason to explore SNARKs on Bitcoin is to build rollups that can use Bitcoin natively. The end goal is a ZK rollup that could leverage Bitcoin as both a gas token and a settlement layer, removing the need to bridge Bitcoin to other platforms. However, the lack of general-purpose smart contract functionality means that verifying SNARKs on Bitcoin would require significant workarounds. Fear not—all is not lost! Enter BitVM.
BitVM circumvents Bitcoin’s script limitations by segmenting large computations into smaller chunks. This allows complex verifications to run as optimistic fraud proofs rather than directly executing on-chain.BitVM's fraud-proof system enables ZK proof verification within Bitcoin's existing constraints. While different from Ethereum's approach, it achieves similar security guarantees through an optimistic protocol where provers commit to computation results and face economic penalties for fraudulent claims. Recent succinct proof implementations by StarkWare, BitcoinOS, and Citrea demonstrate that ZKPs can be a real scalability game-changer.
🚨 An important nuance often overlooked in these discussions is the distinction between true zero knowledge proofs and just succinct proofs (SNARKs). While both offer compression of complex computations, true ZK proofs provide privacy guarantees that SNARKs don't necessarily ensure. Current Bitcoin scaling proposals often focus more on succinctness than zero knowledge properties.
Case Studies
1. StarkWare
StarkWare demonstrated STARK proof verification on Bitcoin's Signet testnet in early 2024 by developing Stwo, a specialized prover-verifier system. The verification process focuses on hash chains and Merkle tree verification through OP_CAT. The proof verified a Fibonacci sequence calculation on Signet.
Stwo addresses size limitations by using small-number arithmetic that fits within Bitcoin's stack requirements. The successful verification of the Fibonacci sequence calculation serves as a proof of concept that STARKs can be practically implemented within Bitcoin's existing constraints
2. BitcoinOS
BitcoinOS broke into the scene by successfully implementing a SNARK (Succinct Non-interactive ARgument of Knowledge) verification on Bitcoin's mainnet, one-upping StarkWare. While marketed using "ZK" terminology, the implementation specifically focuses on succinct proof verification rather than true zero-knowledge privacy aspects. By leveraging Bitcoin's UTXO model, BitcoinOS implemented a SNARK-controlled UTXO that locked both BTC and an Ordinal within a smart contract. This setup emulated covenants.
BitcoinOS demonstrated that Bitcoin can support efficient proof verification through SNARKs. In December 2023, Robin Linus's paper BitVM: Compute Anything on Bitcoin introduced a paradigm-shifting approach, enabling Turing-complete smart contracts on Bitcoin. While BitVM opened new possibilities for trustless Rollup bridges without consensus modifications, its general-purpose architecture introduced unnecessary complexity for specific applications like SNARK verification.
Recognizing these limitations, BitcoinOS developed BitSNARK as a specialized system focusing exclusively on SNARK verification. BitVM implements 55 instructions and complex memory management, while BitSNARK streamlines the architecture to just three instructions (ADD, SUB, MULBIT) specifically optimized for elliptic curve pairing operations. This simplification enables more efficient Bitcoin rollup bridges. Grail, implementing BitSNARK, demonstrates this efficiency by facilitating BTC transfers conditional on verifiable external events, while maintaining a straightforward two-phase challenge protocol compared to BitVM's six.
The BitSNARK protocol achieves this efficiency through a minimalist verification system: provers and verifiers agree on a pre-configured verification program handling approximately 350 bytes of input data. Rather than implementing complex memory consistency checks or general-purpose computation, BitSNARK focuses solely on optimizing the specific requirements of SNARK verification within Bitcoin's constraints. However, BitcoinOS is another example of how "ZK" terminology is often used in the space to refer to the broader family of succinct proof systems, even when the zero-knowledge property isn't the primary focus or fully implemented.
3. Citrea
Citrea, an EVM-compatible ZK-rollup, introduces a novel approach to Bitcoin scaling by verifying complex computations directly on the Bitcoin mainnet. Using RISC-0, Citrea achieves actual zero-knowledge properties and generates zkSNARKs to verify state transitions, enabling thousands of transactions to be bundled and validated with succinct, privacy-preserving proofs. Citrea anchors itself to Bitcoin by using Bitcoin as both a data availability and settlement layer, avoiding intermediary chains and enhancing trust-minimized validation.
The system operates through two types of proofs working in concert:
- Batch Proofs: Generated using RISC-0, these proofs validate both execution and blockspace. The batch proof circuit scans Bitcoin blocks for batch root inscriptions and proves the validity of L2 batches while maintaining zero-knowledge properties. Each proof outputs state differences, state roots, and Bitcoin blockhash data, which are then inscribed on Bitcoin.
- Light Client Proofs: These recursively validate the batch proofs, providing a single proof for the entire rollup history. The circuit inputs the previous light client proof, batch proofs with their inclusion proofs, and Bitcoin block headers, creating a chain of verified state transitions while preserving privacy.
To bridge the gap between these zero-knowledge proofs and Bitcoin's limitations, Citrea employs BitVM for on-chain verification. While BitVM itself provides optimistic verification through fraud proofs rather than direct ZK verification, it serves as the practical mechanism for anchoring Citrea's zero-knowledge system to Bitcoin. This creates a hybrid approach where the underlying computation maintains true ZK properties, even though the final Bitcoin-layer verification is optimistic.
The Future of ZK Proofs on Bitcoin – Reality or Pipe Dream?
Looking at current implementations across Bitcoin, true privacy-preserving succinct proofs remain more aspiration than reality. While projects like BitcoinOS and StarkWare demonstrate succinct proof verification capabilities, and Citrea utilizes RISC Zero to achieve some zero-knowledge properties, we're still in the early stages of delivering genuine zk proofs on Bitcoin. However, the path forward looks promising. The challenge now lies not in whether privacy-preserving proofs are possible on Bitcoin, but in optimizing their implementation within Bitcoin.
BitcoinFi Updates
tBTC Usage Across DeFi Rockets
tBTC has seen significant growth in recent months, eclipsing over $289 million in TVL, and its tBTC/WBTC pool showing near 100% utilization. The rising popularity of tBTC can be attributed in part to growing distrust around WBTC, leading hodlers to seek more decentralized and transparent alternatives. As the most decentralized option, tBTC allows Bitcoin holders to use their BTC across various DeFi platforms without sacrificing the principles of decentralization.
The protocol’s integration into DeFi powerhouses like Aave, Synthetix, and Compound has also propelled its growth. With over 4,399 tBTC circulating across Mezo, Wormhole, and Arbitrum, tBTC’s decentralized, trust-minimized model has seemingly resonated strongly with users.
Stacks Nakamoto upgrade is Live
Stacks, a Bitcoin L2, has successfully implemented its Nakamoto upgrade. The upgrade introduces full Bitcoin finality for Stacks transactions, meaning that transactions on Stacks now inherit the same level of irreversibility as Bitcoin's own network. This is achieved by anchoring Stacks' transaction ordering directly to Bitcoin’s, protected by Bitcoin's hash power. The upgrade also delivers notably faster block times, reducing transaction latency from 10-40 minutes to just seconds.
The Nakamoto upgrade establishes the technical foundation for sBTC, expected to launch within 4-6 weeks. sBTC aims to enable programmable Bitcoin functionality through a network of institutional signers, including Blockdaemon, Kiln, Luganodes, Copper, and Figment. While the core upgrade focuses on network security, developers plan to implement additional optimizations for network bandwidth and latency through non-consensus-critical node updates in the coming weeks.
Nomic Launches BTC Staking Contract
Nomic has introduced a new smart contract that enables Bitcoin decentralized staking through Babylon's protocol. While the Bitcoin LST space has grown significantly, many solutions have relied on centralized custody. Nomic's new implementation allows users and projects to stake ERC-20 Bitcoin directly through a single contract call, maintaining decentralized custody throughout.
Nomic's primitive enables the creation of Bitcoin stake delegations by specifying basic parameters like finality provider and staking period. Bedrock will be one of the first projects to implement this staking contract, promoting uniBTC, one of the first Bitcoin LSTs. Additionally, Nomic plans to implement dual-stake security using both staked $NOM and BTC via Babylon, with stakers earning both $NOM and nBTC rewards - a feature planned for deployment following Babylon's mainnet launch.
Closing Thoughts
As we stand at this precipice of history, sixteen years from Bitcoin's conception, we find ourselves witnesses to what may be its greatest renaissance. The thunder of approaching all-time highs mingles with the whispers of institutional adoption, while political uncertainties cast long shadows across traditional markets.
The upcoming Bitcoin Renaissance brings with it wealth, yes. But more importantly, an awakening—a return to first principles that places sovereignty and self-determination at the heart of this new frontier. What lies ahead is uncertain. Yet it is in these shadows that Bitcoin's light burns brightest. In this strange intersection of elections and economic highs, we glimpse, perhaps, a new light—a moment to reimagine who we are and who we might yet become.
Thank you for tuning in to this week’s BitcoinFi Weekly. See you next week.
If there's a topic you’d like us to cover or have questions, reach out at [email protected].
Learn more about Mezo at the following channels:
👾 Discord: https://discord.mezo.org
🕊 X: https://twitter.com/MezoNetwork
🖥 Website: https://mezo.org
🏦 Deposit Portal: https://mezo.org/hodl
ℹ️ Docs: https://info.mezo.org