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.

What's so great about that? Well, it allows for much better privacy and much smaller transactions.

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.

ShieldedCSV 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.

Some of the nice trade offs:

• 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 of the not nice trade offs:

• 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).

Takeaway