introduction
Bitcoin development today focuses on two main issues: (1) scalability and (2) privacy. Typical proposals for Bitcoin include adding new opcodes and scripting tools. But an old idea is making a comeback, one that could make transactions more private and peer-to-peer. Currently, every Bitcoin transaction is broadcast to the entire network for verification. It’s an effective way to prevent double spending, but it also means revealing more information than is strictly necessary. This results in heavier computational requirements, higher costs, and a system that struggles to scale. But what if moving part of the transaction process client-side not only improves efficiency, but also opens up a whole new era of privacy on Bitcoin?
In our recently published paper, Blockstream, in collaboration with Alpen Labs and ZeroSync, we present the Protected CSV Protocol, an improvement to client-side verification (CSV) that enables truly private transactions. This new protocol is an important step towards enhancing the privacy of Bitcoin transactions and has the potential to increase transaction capacity from 11 per second to over 100 per second, through some additional measures that we will cover in this blog post.
This post provides a high-level overview of the Protected CSV protocol, which aims to improve the performance of a layer-1 blockchain while remaining fully compatible with Bitcoin. Developed by the combined minds of Jonas Nick, Liam Eganand Robin Linus. Here’s the backstory to the Shielded CSV file, and why it can change everything.
Bitcoin then and now
The Double Spending Problem: How Bitcoin Solved It
Before Bitcoin, it was widely believed that creating a reliable digital currency was impossible without a trusted intermediary. The double spending problem means that there is no way to guarantee that a “cryptocurrency” cannot be spent more than once. It was a fundamental flaw that prevented digital currency from becoming a reality.
Then, in 2009, Satoshi addressed this problem by introducing a shared public ledger called blockchain. Instead of relying on a single trusted authority, Bitcoin uses a network of nodes on a shared public ledger, where every transaction is recorded and verified. This system ensures that each coin is unique, making it impossible to spend the same coin twice.
When a Bitcoin transaction is added to the chain, it follows the following process:
- The user’s wallet signs the transaction and broadcasts it to the Bitcoin network.
- Full nodes on the network validate the transaction, ensuring everything is verified.
- The transaction is then included in a block, confirmed, and permanently recorded in a shared public ledger.
During validation, nodes verify the existence of coins, verify the signature, and enforce the crucial double-spending rule – making sure each coin is spent only once. The whole purpose of this register is to maintain order, and clearly show who owns the coins and when they were transferred.
The purpose of the ledger is to keep the order of transactions, showing who owns the coins and when they were sent.
Since its inception, Bitcoin developers have continued to ask the same question: Is this really the best and most private way to handle transactions? How can we make this system smaller, more efficient and more private?
The privacy problem: public transactions
The biggest privacy challenge in Bitcoin is that Bitcoin transactions are publicly available on the blockchain. Satoshi saw this vulnerability from the beginning. In the original white paper, he proposed a straightforward solution: users should generate new keys for each transaction and avoid reusing addresses.
The idea was to make it more difficult to link transactions to a single owner. But in practice, with all the advanced string analysis methods available today, maintaining privacy is much harder than it seems. Even with new addresses, linking transactions and identifying patterns has become easier for those who intend to track user activity.
In response, privacy-focused protocols like Zcash have introduced new ways to hide transaction details using more advanced cryptography and things like zk-SNARKs. But these approaches come with significant trade-offs: transactions are larger, making the verification process for nodes more resource-intensive and expensive to verify.
Connection problem: The connection is not working
In the design of Bitcoin, mining serves two primary purposes: (1) proving the publication of transactions and (2) providing consensus on the order of transactions. However, Bitcoins system also links these basic functions with less important tasks, such as validating transactions and issuing currency.
Across all blockchains, whether Bitcoin, Ethereum, Zcash or Dogecoin, the transaction process always looks the same: wallets sign transactions, broadcast them to the network, and full nodes verify their authenticity. But is validating every transaction live on the blockchain really necessary?
We believe there is a better way. The idea goes back to A Insight into 2013, when Peter Todd first mentioned client-side verification. In this mailing list post he asks, ‘Given only proof of publication, and consensus on the order of transactions, can we create a successful cryptocurrency system? Surprisingly, the answer is yes!‘
Instead of requiring each full node to verify each transaction, a CSV file allows you to send coins with proof of validity directly to the recipient. This means that even if a block contains an invalid transaction, full nodes will not reject it. The result? Fewer connections across the chain and a more efficient system overall.
CSV: A peer-to-peer scaling solution
The CSV file transfers responsibility for transaction validation from each node in the network to the recipients of individual transactions. This makes Bitcoin equal More peer-to-peer. Imagine if we didn’t have to use blockchain to store full transaction details. Instead of a detailed transaction tied to the identity, you’ll only see a simple 64-byte invalidation, completely meaningless to anyone looking at the public record on the blockchain, but important to the sender and recipient.
When every node is required to verify every transaction, it congests and slows down the network. By shifting transaction validation to the client side, the amount of data stored on the blockchain can shrink dramatically — from 560 weight units (WU) on average to something closer to 64 WU, which is about 8.75 times smaller, making the system even smaller. Larger and more efficient. .
The compliance protocol gives Bitcoin a massive scalability boost, allowing users to process nearly 10 times more transactions – nearly 100 per second.
Bitcoin tomorrow
You’re probably thinking, “This all sounds great, but how does this actually work, and what are the trade-offs here?”
How does a protected CSV file make Bitcoin more private?
CSV protocols generally improve privacy over transparent blockchain transactions because some information is transferred client-side. But in traditional CSV protocols like RGB and Taproot Assets, when a coin is sent, both the sender and receiver can view the complete transaction history.
At Shielded CSV, we use zk-SNARK-like schemes to “compress” proofs, ensuring that no transaction information leaks. This means that transaction history remains hidden, providing better privacy compared to current protocols.
What is a nullifier, and how does it prevent double spending?
When a payment is made, the sender delivers the transaction directly to the recipient. A small portion of data derived from the transaction is written to the blockchain which is called invalidation.
Full nodes in the network are only required to perform one Schnorr signature verification for each protected CSV invalidator. The recipient verifies the validity of the coin and ensures that a invalidator exists on the blockchain to stop any double spending.
Other CSV protocols have invalidators as well, but in many cases they are full Bitcoin transactions, not derived “random blobs” like we have here. Protected CSV invalidators make it difficult to perform string analysis.
Does a protected CSV file require a soft or hard fork?
A protected CSV file does not require a soft or hard file fork. It works with Bitcoin as is. The CSV file decouples transaction validation from consensus rules, allowing flexibility without changing the underlying protocol. Since Bitcoin blocks can store any type of data, different CSV protocols such as RGB, Taproot Assets, or multiple versions of Shielded CSV can coexist without conflict.
Nodes do not have to reject blocks containing unfamiliar data. Instead, they only need to interpret data on the “customer side” if it is relevant to them. By offloading transaction verification, the primary role of blockchain is reduced to: confirming transaction data with an agreed upon order and preventing double spending.
Will a protected CSV file allow me to transact with Bitcoin?
Shielded CSV operates as a separate system, using the Bitcoin blockchain to record revocations and prevent double spending within the CSV protocol. But to integrate it directly with Bitcoin and allow seamless transactions, a bridging solution is still needed. The current protocol does not delve into how the bridge works with BitVM, but this is an area of development that is still under active research.
Currently, bridging is made possible through the use of a trusted party or consortium, but the ultimate goal is a completely trustless system, one that eliminates the need for any intermediaries. Achieving this means real and seamless interaction between Bitcoin and Shielded CSV, allowing users to enjoy enhanced privacy without compromising untrusted Bitcoin values. It’s a complex challenge, but one that could redefine how Bitcoin is measured and its transactions are secured.
Read the full paper
The Protected CSV protocol provides a way to improve Bitcoin’s scalability and privacy, potentially leading to a new era of more efficient peer-to-peer transactions. By offloading transaction validation to the client side, it significantly reduces on-chain data, allowing for greater transaction throughput and enhanced privacy – all without the need for a hard or soft fork. If you are curious to read more about how this protocol works and the trade-offs involved, I highly encourage you to read the full paper,”Protected CSV file: Private and efficient client-side verificationThis may just be the future of Bitcoin.
This is a guest post by Chiara Beckers. The opinions expressed are entirely their own and do not necessarily reflect the opinions of BTC Inc or Bitcoin Magazine.