Shielded CSV: A New Era of Privacy and Scalability for Bitcoin

Bitcoin development today focuses on two major issues: (1) scaling and (2) privacy. The usual proposals to Bitcoin involve adding new opcodes and scripting tools.

Bitcoin development today focuses on two major issues: (1) scaling and (2) privacy. The usual proposals to Bitcoin involve adding new opcodes and scripting tools. But an old idea is coming back, one that could make transactions more private and peer-to-peer.

Right now, every Bitcoin transaction is broadcast to the entire network for verification. It’s an effective way to prevent double-spending, but it also means more information is exposed than is strictly necessary. This leads to heavier computational demands, higher costs, and a system that struggles to scale.

But what if moving part of the transaction process client-side didn't just improve efficiency, but also unlocks a whole new era of privacy on Bitcoin?

In our recently published paper, Blockstream, in collaboration with Alpen Labs and ZeroSync, we introduce the Shielded CSV Protocol, an improvement on Client-Side Validation (CSV) that offers truly private transactions. This new protocol is a significant 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 we’ll cover in this blog post.

This post offers a high-level overview of the Shielded CSV Protocol, which aims to advance layer one blockchain performance while remaining fully compatible with Bitcoin. Developed by the combined minds of Jonas Nick, Liam Eagen, and Robin Linus. Here’s the backstory on Shielded CSV, and why it has the potential to change everything.

Bitcoin Then and Now

The Double-Spend Problem: How Bitcoin Solved It

Before Bitcoin, it was widely believed that creating a reliable digital currency was impossible without a trusted middleman. The double-spend problem meant there was no way to ensure a “digital coin” couldn’t be spent more than once. It was a fundamental flaw that kept digital currency from becoming a reality.

Then, in 2009, Satoshi addressed this problem by introducing the shared public ledger called the 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 this process:

During validation, nodes verify that the coins exist, check the validity of the signature, and enforce the critical double-spend rule—making sure each coin is spent only once.

The whole purpose of this ledger is to maintain order, showing clearly who owns which coins and when they moved.

The purpose of the ledger is to keep transactions in order, making it clear who owns what coins and when they were sent.

Since its inception, Bitcoin’s developers keep coming back to the same question: is this really the best and most private way to handle transactions? How can we make this system leaner, more efficient, and more private?

A Privacy Problem: Public Transactions

Bitcoin's biggest privacy challenge is that bitcoin transactions are out there in the open on the blockchain. Satoshi saw this vulnerability from the beginning. In the original whitepaper, he suggested a straightforward solution: users should create new keys for each transaction and avoid reusing addresses.

The idea was to make it harder to link transactions back to a single owner. But in practice, with all the advanced chain 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 intent on tracing user activity.

In response, privacy-focused protocols like Zcash have introduced novel ways to conceal transaction details using more advanced cryptography and things like zk-SNARKs. But these methods come with significant trade-offs: transactions are larger, making the verification process for nodes more resource-intensive and expensive to verify.

A Communication Problem: Communication is Inefficient

In Bitcoin’s design, mining serves two fundamental purposes: (1) proof-of-publication for transactions and (2) providing a consensus on the order of transactions. However, Bitcoins’ system also intertwines these core functions with less essential tasks, like transaction validation and coin issuance.

Across all blockchains, whether it’s Bitcoin, Ethereum, Zcash, or Dogecoin, the transaction process always looks the same: wallets sign transactions, broadcast them to the network, and full nodes validate them. But is validating every transaction directly on the blockchain really necessary?

We think there’s a better way. The idea traces back to a 2013 insight, when Peter Todd first mentioned Client-Side Validation. In this mailing list post he asks, ‘Given only proof-of-publication, and a consensus on the order of transactions, can we make a successful crypto-coin system? Surprisingly, the answer is yes!’

Instead of requiring every full node to verify every transaction, CSV allows you to send coins with proof of their validity directly to the recipient