Introduction
Bitcoin development today focuses on two major issues: (1) scalability and (2) privacy. Common suggestions for Bitcoin include adding new opcodes and scripting tools. But an old idea is coming back, one that can make transactions more private and peer-to-peer. Currently, everything Bitcoin does is broadcast across the network for verification. It is an effective way to prevent double spending, but it also means that more information is disclosed than is really necessary. This leads to heavy computing requirements, high costs, and a system that struggles to scale. But what if moving part of the transaction process to the client side not only improved efficiency, but also ushered in a new era of privacy in Bitcoin?
In our newly published paper, Blockstream, in collaboration with Alpen Labs and ZeroSync, present the Shielded CSV Protocol, an advancement in Client-Side Validation (CSV) that provides truly private transactions. This new process is an important step in improving the privacy of Bitcoin transactions and has the potential to increase the volume of transactions from 11 per second to over 100 per second, with additional methods that we will cover in this blog post.
This post provides a high-level overview of the Shielded CSV Protocol, which aims to improve the functionality of a single blockchain while keeping it fully compatible with Bitcoin. Developed by the collective minds of Jonas Nick, Liam Eagen, and Robin Linus. Here’s the backstory on Shielded CSV, and why it has the power to 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 reliable middleman. The double-spending problem meant that there was no way to ensure that a “digital coin” could not be used more than once. It was a critical mistake that made digital currency unreal.
Then, in 2009, Satoshi tackled this problem by introducing a shared public ledger called blockchain. Instead of relying on a single trusted authority, Bitcoin uses a network of nodes in a shared public ledger, where all transactions are recorded and verified. This system ensures that each coin is unique, making it difficult to use 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.
- Nodes throughout the network validate transactions, making sure everything is checked.
- The transaction is then placed in a block, verified, and permanently recorded on the shared public bridge.
During verification, nodes verify that the coins are present, check the validity of the signature, and apply the important double-spending rule—ensuring that each coin is only used once. The whole purpose of this book is to keep order, to show clearly which coins and when they were moved.
The purpose of the ledger is to keep transactions organized, clear who owns which coins and when they were sent.
Since its inception, Bitcoin developers keep coming back to the same question: is this the best and most private way to handle transactions? How can we make this system smaller, more efficient, and more private?
The Privacy Problem: Social Transactions
Bitcoin’s biggest privacy challenge is that bitcoin transactions are transparent on the blockchain. Satoshi saw this weakness from the beginning. In the first white paper, he proposed a specific solution: users should create new keys for each transaction and avoid reusing addresses.
The idea was to make it difficult to link transactions back 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 new addresses, transactional links and identification patterns have 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 methods come with an important trade-off: transactions are large, which makes the verification process of nodes more resource-intensive and more expensive to verify.
Connection Problem: Connection failed
In the creation of Bitcoin, mining serves two main purposes: (1) publishing proof of transactions and (2) providing consensus on the order of transactions. However, Bitcoins system also combines these core functions with less important functions, such as verifying transactions and issuing coins.
In all blockchains, whether it is Bitcoin, Ethereum, Zcash, or Dogecoin, the transaction process always looks the same: wallets sign the transaction, broadcast it to the network, and full nodes confirm it. But is verifying all transactions directly on the blockchain really necessary?
We think there is a better way. The idea dates back to 2013, when Peter Todd first mentioned Client-Side Authentication. In this mailing list he asks, ‘Given only proof of publication, and agreement on transaction order, 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 proof-of-concept coins directly to the recipient. It means that even if the block contains an invalid transaction, full nodes will not reject it. The result? Less on-chain communication and a more efficient system overall.
CSV: A Peer-to-Peer Scaling Solution
CSV shifts responsibility for verifying transactions from all nodes in the network to individual transaction recipients. This makes Bitcoin equal peer-to-peer. Imagine if we didn’t need to use blockchain to store full transaction details. Instead of a detailed transaction, linked to the identity, you will only see a simple 64-byte object, completely useless to anyone looking at the public record on the blockchain, but important to the sender and receiver.
If every node is required to verify every transaction, it chokes the network and slows it down. By switching to client-side transaction verification, the amount of data stored on the blockchain can be significantly reduced—from 560 weight units (WU) on average to something closer to 64 WU, which is 8.75 times smaller, making the system simpler and more efficient. .
The compliance protocol gives Bitcoin a huge boost in scalability, allowing users to process nearly 10 times more transactions—close to 100 per second.
Bitcoin Tomorrow
You’re probably thinking, “That all sounds good, but how does this actually work, and what’s the trade-off here?”
How Shielded CSV Makes Bitcoin Private?
CSV protocols generally improve privacy over transparent blockchain transactions because some information is transferred on the client side. But in traditional CSV protocols like RGB and Taproot Assets, when a coin is sent, both sender and receiver can view the full history of the transaction.
In Shielded CSV, we use schemes like zk-SNARK to “suppress” the evidence, ensuring that no transaction information is leaked. This means that the transaction history remains hidden, providing better privacy compared to existing protocols.
What Is A Nullifier, And How Does It Prevent Double Nullification?
When making a payment, the sender gives the transaction directly to the recipient. A small piece of data found in a transaction, is written to the blockchain called a nullifier.
Full nodes in the network are only required to perform a single Schnorr signature verification with Shielded CSV passive. The recipient checks the validity of the coin and verifies that the passive is on the blockchain to stop double spending.
Some CSV protocols have reducers as well, but in most cases they are full Bitcoin operations, and not captured by “random blobs” like we have here. Secure CSV nulls make it difficult to perform string analysis.
Does Shielded CSV Need a Soft or Hard Fork?
Secure CSV does not require a soft or hard fork. It works with Bitcoin as it is. CSV separates transaction verification from consensus rules, allowing flexibility without changing the core 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 that contain irregular data. Instead, they only need to interpret data on the “client side” if it is relevant to them. By removing transaction verification, the main role of the blockchain is reduced: To verify transaction data in an agreed upon manner and to prevent double spending.
Does Shielded CSV allow me to work with Bitcoin?
Secure CSV works as a separate system, using the Bitcoin blockchain to record anonymous transactions and prevent double spending within the CSV protocol. But to integrate it directly with Bitcoin and allow seamless transactions, an integration solution is still needed. The current protocol does not go into depth on how BitVM bridging can work, but this area is a development that is still under active research.
Currently, bridging is possible through a trusted party or alliance, but the ultimate goal is a completely trustless system, eliminating the need for any intermediaries. Achieving this would mean authentic, seamless communication between Bitcoin and Shielded CSV, allowing users to enjoy enhanced privacy without compromising on the trustless value of Bitcoin. It’s a complex challenge, but one that could redefine how Bitcoin scales and secures its transactions.
Read the Full Paper
The Shielded CSV Protocol provides a way to improve the stability and privacy of Bitcoin, potentially ushering in a new era of more efficient, peer-to-peer transactions. By outsourcing client-side transaction verification, it significantly reduces on-chain data, allowing for greater transaction reproducibility and improved privacy—all without requiring a hard or soft fork. If you wish to learn more about how this legal process works and the tradeoffs involved, I highly encourage you to read the full paper, “Secure CSV: Confidential and Effective Client-Side Authentication”. This could be the future of Bitcoin.
This is a guest post by Kiara Bickers. The opinions expressed are entirely their own and do not reflect those of BTC Inc or Bitcoin Magazine.
Source link