Introduction
Bitcoin’s development today focuses on two major issues: (1) scaling and (2) privacy. General proposals for Bitcoin include adding new opcodes and scripting tools. But an old idea is making a comeback, which could make transactions more private and peer-to-peer. Right now, every Bitcoin transaction is broadcast to the entire network for verification. This is an effective way to prevent double spending, but it also means that more information is exposed than necessary. This results in heavy computational demands, high costs, and a system that struggles to scale. But what if moving the client-side portion of the transaction process forward not only improves efficiency, but also opens up a 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 over client-side validation (CSV) that offers truly private transactions. This new protocol is an important step towards increasing the privacy of Bitcoin transactions and has the potential to increase transaction capacity from 11 per second to 100 per second through some additional measures, which we will cover in this blog post.
This post provides 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 joint brains of jonas nick, Liam EggenAnd Robin LinusHere’s the back story of Shielded CSV, and why it has the potential to change everything.
bitcoin then and now
The double spending problem: how Bitcoin solved it
Before Bitcoin, it was widely believed that it was impossible to create a reliable digital currency without a trusted intermediary. The double-spending problem meant that there was no way to ensure that a “digital coin” could not be spent more than once. This was a fundamental flaw that prevented digital currency from becoming a reality.
Then, in 2009, Satoshi solved 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 this process:
- The user’s wallet signs the transaction and broadcasts it to the Bitcoin network.
- Full nodes on the network validate transactions, making sure everything has been checked.
- The transaction is then combined into a block, confirmed, and recorded permanently in the shared public ledger.
During validation, nodes verify that the coins exist, check the validity of the signature, and enforce the important double-spending rule тАУ ensuring that each coin is spent only once. The whole purpose of this ledger is to maintain order, clearly showing which coins belong to whom and when they were gone.
The purpose of the ledger is to keep transactions in order, making it clear who has which coins and when they were sent.
Since its inception, Bitcoin’s developers have come to the same question: Is this really the best and most private way to handle transactions? How can we make this system more streamlined, more efficient, and more private?
A Privacy Problem: Public Transactions
Bitcoin’s biggest privacy challenge is that Bitcoin transactions are openly available on the blockchain. Satoshi saw this vulnerability from the beginning. In the original whitepaper, they suggested a straightforward solution: users should generate new keys for each transaction and avoid reusing addresses.
The idea was to make it difficult to link transactions to a single owner. But in practice, with all the advanced chain analysis methods available today, maintaining privacy is more difficult than it seems. Even with the new addresses, it has become easier for those intent on tracing user activity to link transactions and identify patterns.
In response, privacy-focused protocols like Zcash have introduced new ways to hide transaction details using more advanced cryptography and things like zk-SNARKsBut 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 disabled
In Bitcoin’s design, mining serves two fundamental purposes: (1) proof of publication for transactions and (2) providing consensus on the order of transactions. However, Bitcoin’s system also combines these core functions with less essential functions such as transaction verification and coin issuance.
In 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 it really necessary to validate every transaction directly on the blockchain?
We think there is a better way. this idea comes back Insight from 2013, when Peter Todd first mentioned client-side validationIn this mailing list post he asks, ‘Given only proof of publication and consensus on the order of transactions, can we create 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 directly to the recipient with proof of their validity. This means that even if a block contains an invalid transaction, full nodes will not reject it. outcome? Less on-chain communication and a more efficient system overall.
CSV: A Peer-to-Peer Scaling Solution
CSV shifts the responsibility of transaction verification from each node in the network to the individual transaction recipients. This makes Bitcoin even more peer to peerImagine if we didn’t have to use blockchain to store complete transaction details. Instead of a detailed, identity-linked transaction, you’ll just see a simple 64-byte zeroter, which is completely meaningless to anyone looking at the public record on the blockchain, but important to the sender and recipient. .
When every node needs to verify every transaction, it clogs the network and slows it down. By moving transaction verification to the client side, the amount of data stored on the blockchain can be significantly reduced тАУ from an average of 560 weight units (WU) to about 64 WU, which is approximately 8.75 times smaller, making the system leaner and more efficient. It happens. ,
The compliance protocol gives Bitcoin a massive scalability boost, allowing users to process approximately 10 times more transactions тАУ closer to 100 per second.
bitcoin tomorrow
You’re probably wondering, “This all sounds great, but how does it actually work, and what are the trade-offs here?”
How does protected CSV make Bitcoin more private?
CSV protocols generally improve privacy on 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 see the full transaction history.
In Shielded CSV, we use schemes like zk-SNARK to “compress” evidence, ensuring that no transaction information is leaked. This means that transaction history remains hidden, providing better privacy than existing protocols.
What is Nullifier, and how does it prevent double spending?
When making a payment, the sender hands over the transaction directly to the recipient. A small piece of data obtained from a transaction is written on the blockchain in what is called a nullifier.
Full nodes in the network need to perform only one Schnorr signature verification per shielded CSV nullifier. The receiver checks the validity of the coin and ensures that the nullifier is on the blockchain to prevent any double spending.
Other CSV protocols also have nulls, but in many cases they are complete Bitcoin transactions, and not derived from “random blobs” as we have here. Shielded CSV nullifiers make series analysis difficult.
Does protected csv require a soft or hard fork?
Shielded CSV does not require soft or hard forkIt works the same way with Bitcoin. CSV separates transaction validation from consensus rules, allowing flexibility without changing the core protocol. Since Bitcoin blocks can store any type of data, multiple versions of different CSV protocols such as RGB, Taproot Assets, or Shielded CSV can coexist without conflict.
Nodes are not required to reject blocks with unfamiliar data. Instead, they only need to interpret the data on the “client-side” if it is relevant to them. By offloading transaction verification, the blockchain’s primary role is reduced: verifying transaction data in an agreed order and preventing double-spending.
Does Shielded CSV allow me to transact in Bitcoin?
Shielded CSV works as a separate system, using the Bitcoin blockchain to record nullifiers 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 in depth into how bridging might function with BitVM, but this area is a development that is still under active research.
Right now, bridging is possible through the use of a trusted party or federation, but the ultimate goal is a completely trustless system, eliminating the need for any intermediaries. Achieving this would mean true, seamless interactions between Bitcoin and shielded CSV, allowing users to enjoy enhanced privacy without compromising the trustless values тАЛтАЛof Bitcoin. It’s a complex challenge, but it could redefine how Bitcoin measures and secures its transactions.
read the full paper
The Shielded CSV protocol offers an approach to improving the scalability and privacy of Bitcoin, potentially ushering in a new era of more efficient, peer-to-peer transactions. By offloading transaction verification to the client side, it significantly reduces on-chain data, allowing greater transaction throughput and increased privacy тАУ all without the need for a hard or soft fork. . If you’re curious to learn more about how this protocol works and what tradeoffs are involved, I encourage you to read the full paper, “Shielded CSV: private and efficient client-side validationThis could be the future of Bitcoin.
This is a guest post by Kiara Bickers. The opinions expressed are solely their own and do not necessarily reflect the opinions of BTC Inc. or Bitcoin Magazine.
