Jonas Nick
Liam Eagen
Robin Linus
Shielded CSV
Private and Efficient
Client-Side Validation
Summary
Shielded CSV is a transaction protocol on top of Bitcoin.
| Bitcoin | Shielded CSV | |
|---|---|---|
| Privacy | 🥴 | ✅ |
| Blockspace per tx | ~600B, on average | 64B, always |
- SAME double-spending security as Bitcoin
- NO online requirement
- NO inbound capacity problem
- NO softfork required (*)
data is ignored by ordinary Bitcoin nodes, only interpreted "client-side" by nodes.
Alice: 3
Bob: 7
Client-Side Validation (CSV)
A 2-input, 2-output Bitcoin transaction
Shielded CSV transaction data is embedded in Bitcoin transactions.
Blockchain (PoW, ...)
Transaction Validation
"Layer 0.5"
"Layer 1"
Bridge examples:
- t-of-n federated bridge
- one-way peg
- BitVM
- validity bridge
- ...
Bridge
can be understood as an alternative L1
doesn't need a softfork, but it inherits the security of the bridge (which may be improved by softforks).
BitVM and new Script opcodes only benefit shitcoiners and JPEG degens!!
Liar! Shielded CSV proves that BitVM and better Script opcodes can add full privacy and 64 byte transactions to Bitcoin.
Full privacy with only 64 bytes on-chain sounds impossible?
Shielded CSV Approach
- Only post the minimal data necessary to prevent double-spending to the blockchain.
- Send "the rest of the transaction" to the receiver directly.
Basic Shielded CSV recipe
Sally the Sender
Ivy: 3
Roy: 7
- Create CSV Transaction. Consist of inputs and outputs, similar to Bitcoin transactions.
- Derive 64-byte "nullifier" from transaction
- Post nullifier to the blockchain
- Send "coin proof" to the receiver
Roy the Receiver
coin proof
Blockchain
nullifier
CSV transaction
Simplified Coin Proof
Sally the Sender
Ivy: 3
Roy: 7
Roy the Receiver
coin proof
Coin Proof: History of (CSV) transactions connecting to issuance transactions.
Harry: 10
Issuance: 6
Issuance: 4
Verify:
All txs in the coin proof
are valid.
(The exact details of issuance depend on the type of bridge)
Simplified Nullifier
The nullifier consists of:
- CoinID: Identifier of the output being spent. This is the hash of the CSV transaction creating the output & index in the transaction.
- TxHash: Hash of the CSV transaction being created.
The nullifier nullifies the coin, thereby preventing double spending
Preventing Double Spending
Blockchain
| CoinID | TxHash |
|---|---|
| <some CoinID> | <...> |
| <other CoinID> | <...> |
nullifier key-value store
Embed nullifier
Process nullifiers
Process nullifiers:
Ignore nullifiers whose CoinID is already in the KV store.
(<some CoinID>, <some TxHash>)
IGNORED by Roy
nullifier = (CoinID, TxHash)
Preventing Double Spending
Sally the Sender
Roy the Receiver
Coin, Coin Proof
Verify Coin Proof:
- All txs in the coin proof are valid.
-
Every coin spent in the coin proof must be present in the KV-store and the tx hashes must match.
| CoinID | TxHash |
|---|---|
| <some CoinID> | <...> |
| <other CoinID> | <...> |
nullifier key-value store
Preventing Double Spending
This design does prevent double spending with only a small nullifier!
(what we've seen is not the actual Shielded CSV nullifier, because it has a number of problems)
Publishing Nullifiers
- Publisher is a permissionless role, open to anyone able to make a Bitcoin transaction.
- If the nullifier ends up in the blockchain, the publisher reponsible is paid a fee within Shielded CSV.
Pete the Publisher
nullifier
aggregate nullifier
Blockchain
nullifier
nullifier
Problem: Sender shouldn't have to make a Bitcoin tx for every nullifier (overhead, requires having bitcoin).
Coin Proof
👷
Nullifier
AggNullifier
...
Block i + 1
Block i
Block i + 2
aggregates & publishes
processes
AggNullifier
| <...> | <...> |
|---|---|
| <...> | <...> |
nullifier key-value store
CSV Tx
Succinct & Private Coin Proofs
Solution: Replace new coin proof with a cryptographic proof that the incoming coin proofs and Sally's CSV tx is correct.
- Makes coin proof size and verification time independent of transaction graph size.
- Instantiated with recursive SNARKs or folding schemes.
CSV tx
new coin proof
coin proof
coin proof
zero-knowledge
succinct
Problem: Coin proof includes all ancestor transactions involved in creating the coin (size?, privacy?).
High-level rust spec
Whitepaper
Post-quantum
non-interactive publishing
prunable wallet state
PCD
Payment Channels
MEVil
TS-Accumulator
Instantiation
Light clients
Timelocks
Sign-to-Contract Schnorr Half-Aggregation
64-byte nullifier
Private and Efficient CSV
Communication Channels
Client-Side Validation Model
Accounts
"mempool"
Reorgs
Atomic Swaps
t-of-n Shared Accounts
Wallet State
🐙
🦑
🦈
Scriptable spending policies
- Shielded CSV is a transaction protocol to create an L1 on top of a blockchain that allows embedding arbitrary data (e.g., Bitcoin).
- It inherits double-spend security from the underlying blockchain.
- The amount of data embedded into the blockchain is 64 bytes per transaction.
- Coin proofs are sent directly to the receiver through a private one-way communication channel.
- Coin proofs are succinct.
- Shielded CSV is fully private.
- No softfork required. But security is inherited from the bridge.
Blockchain (PoW, ...)
Transaction Validation
"Layer 0.5"
"Layer 1"
🛡️
You've unlocked the backup slides
What is CSV really?
Insight: Transaction validation does not need to be part of the consensus rules.
... then transactions are only validated "client-side" and simply ignored if they are invalid.
Comparing CSV
Shielded CSV (Bitcoin2025)
By iamjon
