Some of us still want private, bitcoin payments
Amidst paper bitcoin summer, an upcoming bitcoin privacy project is being under-discussed…
During the craze of Paper Bitcoin Summer, the Bitcoin Conference released talks from the open source stage at Las Vegas. The talks covered a number of topics from new L2s to consensus changes, but one thing caught my eye in particular.
Transaction protocols that enable near-perfect privacy.
Shielded CSV (and its sister protocol zkCoins) is a payment protocol that can be built on top of any blockchain. But, its developers are focusing on leveraging it for scalable, fully private bitcoin payments. It leverages zero-knowledge proofs and only embeds a small amount of data on bitcoin. Basically - it’s a way to do Zcash-style payments that scales well.
Personally, I think it’s one of the most exciting things happening in the bitcoin layers space. Its sister protocol with a similar architecture, zkCoins, might have a reckless mainnet this year. These protocols combine scalability, privacy, and all the ZK magic that can help bitcoin scale with limited interactivity…
In my world, people are constantly discussing “new L2s”, their capabilities, and why we should change bitcoin to make them better. Unfortunately, systems like Shielded CSV and zkCoins are rarely brought up.
So this post is my attempt to explain its design and make more people aware of the construction…
This blog is based on reviews of both Shielded CSV and zkCoins. For this blog, I’m primarily referring to Shielded CSV. It’s my understanding that they are very similar, and if I swapped “zkCoins” for “Shielded CSV”, most of the blog would still hold. Also note, any implementation of what’s laid out here might use a different name in the future.
Shielded CSV’s design philosophy
Shielded CSV is a token transfer protocol. Really, you can think of it as another Layer 1 transaction protocol that is built on top of a data availability layer. This is similar to how bitcoin’s transaction execution layer is built on top of bitcoin’s blockchain and consensus engine.
It operates under a simple principle – only post a minimal amount of data to the blockchain to prevent double-spending. The rest of the transaction data should be sent directly to, and solely verified by, the receiver.
This approach significantly minimizes the amount of data that is posted to bitcoin. Shielded CSV transactions only require 64 bytes of data. The average bitcoin transaction contains an average of 600~ bytes of data.
How it works
Client-side validation
Client-side validation is a mechanism where users only need to validate the history of coins, and corresponding transactions, that they individually interact with. There is no need for keeping a record of anyone’s coins, or transactions, outside of your own.
In bitcoin, full nodes must keep a record of the entire UTXO set and validate all transactions that have ever been recorded on the blockchain. Shielded CSV is the opposite of this dynamic – you’re only responsible for validating data related to your coins’ histories.
This minimizes the amount of data that is posted on bitcoin, with the tradeoff that users are responsible for keeping a copy of their individual state (more on this later).
Nullifiers
Shielded CSV as a protocol has transactions and nullifiers. Nullifiers are commitments to bitcoin that ensure a specific coin can no longer be spent in the Shielded CSV protocol.
Users don’t post a nullifier for each individual coin they hold when they conduct a transaction. Shielded CSV introduces “accounts” that contain an account state. During a transaction, users submit a nullifier of an account state that nullifies their ability to spend a coin that was a part of a previous account state.
How Shielded CSV’s nullifiers might work
This is a stab at outlining the nullifier construction highlighted in the Shielded CSV paper. Future production protocols might have different designs.
The nullifier consists of the nullifier public key and a Schnorr signature. The signature commits to the hash of the Shielded CSV transaction that created the nullifier.
Users maintain a nullifier accumulator that stores nullifiers related to Shielded CSV account state transitions. Each time that a Shielded CSV transaction is made, it nullifies a prior coin that was created in the protocol. The accumulator adds the new nullifier, which makes it impossible for that coin to be spent again.
Nullifiers are committed to in bitcoin blocks. Shielded CSV nodes scan bitcoin to find updates. When they find new nullifiers, each nullifier is verified as a Shielded CSV commitment, and is then added to the accumulator.
These commitments are 64 bytes in size. To get it down to this size, the whitepaper outlines some techniques using Sign-To-Contract and signature half-aggregation. For a detailed description of the nullifier, check out the whitepaper.
Tl;dr - we post a commitment to bitcoin that prevents double spending in the protocol.
Zero-knowledge proofs
Zero-knowledge proofs are proofs that provide an argument, which do not reveal the contents of the argument, outside of proving the argument to be true. The end goal is to convince a counter-party of the current state of some system. In payments related use cases, they are used to send proofs that a certain payment abides by the rules of a system without revealing the sender, the receiver, and the amount spent. This obscures the transaction graph and creates a system with high levels of privacy. They also have scalability benefits as they can compress entire transaction histories into a compact, succinct proof that recursively updates as needed.
In shielded CSV, this can be used to send a user the history of a coin, convince them that said history is valid, enable them to verify they are the new owner of the coin, and keep the size of the coin history compact and constant.
Shielded CSV, as a concept, does not rely on any given proving scheme. Numerous schemes could be leveraged in this design.
Combining them
When you combine these concepts together, you’re able to create a client-side validation system where transaction graphs are obscured and the history of coins is kept constant size, making them more efficient to validate. Users only validate transactions related to their coins.
This means that the network benefits from the unchangeable ordering of transactions in bitcoin blocks. Shielded CSV users are able to rely on bitcoin for keeping a record of all nullifiers, making them available to clients & nodes, and being able to finalize Shielded CSV transactions based on this ordering.
The transaction lifecycle
Now that we’ve got the key concepts covered… Let’s talk about the transaction lifecycle.
Transaction creation
Alice wants to pay Bob. To do this, she generates a shielded transaction. This transaction attests to Alice's previous account state and all of the coins she held in this state, and then generates a new account state related to the new coins. One of these new coins is for the receiver. Then, Alice derives the nullifier nullifying her previous account state and committing to the new account state.
Reminder: When an account performs a state transition (i.e. makes a transaction), the single Account ID is associated with a number of coins and the state of that account is updated and a nullifier for solely the account state transition is published.
Submitting the nullifier to bitcoin
Alice submits a bitcoin transaction containing this nullifier. This nullifier is embedded into bitcoin as arbitrary data, and from the vantage point of bitcoin full nodes, it doesn’t mean anything. The data is interpreted by Shielded CSV users as they scan bitcoin to find the nullifiers related to the coins they’ve been sent.
Receiving the coins
After Alice has submitted the nullifier to bitcoin, she needs to send a “coin proof” to Bob through a private communication channel (i.e. a wallet, messaging app, etc.). But first, Bob scans bitcoin, processes all nullifiers related to Shielded CSV, verifies their signatures, and updates his nullifier accumulator client side.
After this, Alice sends a coin proof, attesting to the history of the coin being transferred, to Bob. Bob verifies this coin proof to ensure that it 1) attests to a valid transaction 2) follows the Shielded CSV consensus rules and 3) commits to an entry recorded in his nullifier accumulator. He also verifies that all previous transactions in the coin’s history were valid and cannot be double spent.
After transaction validation, and after the block containing the nullifier has sufficient proof-of-work behind it, both Alice and Bob can consider the payment final.
Because the coin proof is a zero-knowledge proof, none of the information about the sender, receiver, or amounts is made public. Only an argument that a valid transaction occurred is public.
That’s it… but some stuff can make it better
This is basically how a Shielded CSV-style protocol would work. Still, there’s things that can make the protocol better suited for bitcoin-denominated payments:
Bridges
In the example above, you may have noticed that I never said “Alice sent Bob bitcoin”. Well, that’s because Shielded CSV is an alternative network that needs bitcoin to be bridged over to use it.
I’m not here to convince you that bridges are good or bad, or which one is the best. But, we can cover some designs that we could use to create a two-way peg for Shielded CSV:
T-of-N multisig: A multisig where T-of-N signers need to secure deposits and process withdrawals to users who want to leave Shielded CSV. Used widely today.
BitVM: A bridge where a set of operators need to secure deposits and process withdrawals. A minority of them need to be honest and a distributed set of watchtowers (maybe permissionless) can force them to be honest. Multiple teams building this.
Native Proof Verification: With additional opcodes, you could construct a bridge that verifies proofs attesting to the current state of balances in Shielded CSV. If the proof is valid, the bridge can execute withdrawals based on this state.
There are different tradeoffs related to these bridges, and even how they compare with other L2s (such as Lightning). But, analyzing that is for an upcoming post…
Third party publishers
Publishing nullifiers on bitcoin requires a bitcoin transaction. Having to submit a bitcoin transaction every time you do a Shielded CSV? Pretty bad UX. And, what if you don’t have any bitcoin to start off with? You wouldn’t have the funds to submit the transaction containing the nullifier.
Insert publishers - service providers who post nullifiers on users’ behalf. The publisher role collects nullifiers from many users, aggregates them, and then submits them as a batch to bitcoin. They receive a fee, on Shielded CSV, in exchange for posting the nullifiers on users’ behalf. Even within batches, users are still able to derive an individual nullifier associated with a coin they spent or received.
Why use a third party? First, you may not have some bitcoin. Shielded CSV, as a payments layer for bitcoin, should be able to onboard users who have never, and maybe can’t, use the L1. An active network of publishers means some users may never even have to interact with bitcoin itself; a win for scaling. Also, you may not want to wait around for bitcoin’s block times for lower value payments. Publishers might be set up to accept transactions nearly instantly. You can see that the publisher accepted the nullifier, and if you trust that they’ll post it to bitcoin, you can be on your way.
Third party publishers can offer some performance benefits as they post aggregated nullifiers, not individual nullifiers one by one. There’s likely some neat compression techniques you could employ to reduce the cost of submitting these nullifiers onchain (which is useful in a high fee environment).
Service providers have an incentive to not censor you through fees. And if they do, publishing the nullifier is permissionless. You just need a little bit of bitcoin to do so.
Remember, these service providers cannot steal your funds. They can only refuse to post the nullifier, which means your transaction can never finalize and you’d need to use another publisher or publish it yourself.
UX - some notable design tradeoffs
Some nice tradeoffs
Shielded CSV has some unique UX benefits when compared to other bitcoin payments protocols. First, it can rely on bitcoin’s ordering of Shielded CSV nullifiers to enforce double-spend resistance. If someone tried to spend a previously spent coin, the transaction validation in Shielded CSV would fail based on the nullifier data that bitcoin made available to Shielded CSV nodes.
The interactivity requirements are minimal. After a sender submits their nullifier to bitcoin, and the coin proof to the receiver, the receiver can come online at any time after the fact and validate the coin proof and corresponding nullifiers. The interactivity requirement is that the receiver needs to come online to receive the payment.
And finally, there’s no inbound capacity problem. Users do not need to free up liquidity, or have existing liquidity at all, in order to receive a Shielded CSV payment. With the use of publishers, they don’t even have to interact with bitcoin at all.
Some not so nice tradeoffs
In these styles of systems, users must keep backups related to their own coin histories. If they lost any of these backups, then the data related to their own tokens would be permanently lost. In Shielded CSV, you are the only person who has access to this state. Don’t lose it!
Generating and verifying zero-knowledge proofs on a mobile phone also might be infeasible. But, proving systems are rapidly improving. And, protocols like Zcash, for example, can generate zero-knowledge proofs client-side to send shielded transactions. I’d be very surprised if we couldn’t run a Shielded CSV-style protocol on mobile phones in the next couple of years.
Also, full nodes have to keep track of all nullifiers related to Shielded CSV transactions which are 64~ bytes in size. This is potentially a scaling bottleneck down the road. Zcash is currently researching different ways to lessen this burden on full nodes, and some of the tricks may be applicable to a Shielded CSV construction.
Lastly, because the system requires a bridge, bitcoin’s current scripting capabilities prohibit users from unilaterally exiting a Shielded CSV-style protocol. T-of-N multisigs are permissioned in practice, so they are more vulnerable to censorship vectors. For example, they could use a surveillance oracle against OFAC sanctions list that forces bridge operators to censor specific addresses if they’ve been flagged (this exists today).
BitVM is an interesting approach that reduces the assumption to a minority of operators, but users still trust, at least one in theory, operator to facilitate withdrawals. While most implementations might have training wheels in their first production release, it has the potential to create a more trust-minimized set up that is ideal for systems that require more censorship resistance – like Shielded CSV.
So… soft forks for “spam”?
As Shielded CSV co-creator, and Blockstream researcher, Jonas Nick pointed out, all bitcoin transactions are spam. Classifying the arbitrary data associated with Shielded CSV nullifiers as spam is short-sighted. Even so, what most people call spam are transactions associated with speculative token protocols and data related to systems who offer smart contracts for shitcoin lovers. The protocol I’m describing above isn’t that in practice.
It’s a payments system that does not require a soft fork to build on top of bitcoin. You can build a shielded CSV-style system that inherit ordering guarantees from bitcoin today. But, for the system to be truly censorship resistant, for bitcoin payments, we need a mechanism to construct a trust-minimized bridge to and from bitcoin.
Some teams are looking to accomplish this via BitVM. This is likely the best we can do right now. But, as Jonas Nick also pointed out, this system could be improved if we are able to natively verify validity proofs on bitcoin (within the block size limit). This would require a soft fork. Which soft fork proposal? I don’t know. That’s above my pay grade.
But it’s not above yours! If you’re interested in ZK research, click the link below learn more about the upcoming ZK conference in Istanbul. Got an interesting talk or workshop about native zk on bitcoin? We’re currently accepting talks → Apply for a talk here.
But, what’s described above is a fully-private payments system that takes some worthwhile UX tradeoffs compared to what exists today. When we discuss new layer 2s coming to market, and “which layer 2s” could benefit from potentially making script more expressive, protocols such as Shielded CSV should be considered.
–Janusz