Key Highlights
- Bitcoin researcher Jonas Nick highlighted Compact Shielded CSV, drawing attention to its approach to reducing on-chain transaction data.
- The proposed design records 96 bytes of hashes for a single-input transaction, while transaction proofs and signatures remain off-chain.
- A mechanism called a degriefer is designed to help distinguish legitimate spending transactions from conflicting transactions.
Bitcoin researcher Jonas Nick has drawn attention to Compact Shielded CSV, a post-quantum blockchain proposal that records three 32-byte hashes on-chain for a single-input transaction.
In an October 13 post on X, he wrote, “I’ve always thought the CSV model is attractive in a PQ setting: the blockchain only stores the nullifier, so miners don’t have to verify a signature before it gets into a block. Compact Shielded CSV goes a step further: the on-chain nullifier carries no signature at all, only what they call a “degriefer”. Pre-quantum that’s more than Shielded CSV’s 64 bytes, but post-quantum it’s much less.”
Nick’s post discusses a preprint dated September 25, 2026. Its authors are Dragos Ioan Ilie of Orbs and Uri Lee, Iain Stewart, Jonathan Zhu, Elliot Jones, and William J. Knottenbelt of Imperial College London. The paper has not been peer-reviewed and describes a proposed protocol rather than a live blockchain network.
Jonas Nick highlights the 96-byte design
Compact Shielded CSV builds on client-side validation, an approach in which users exchange transaction proofs off-chain rather than storing the full proofs on the blockchain. For a single-input transaction, the proposal records 96 bytes of hashes. Nick compared this with the roughly 64-byte footprint of the earlier Shielded CSV proposal before a post-quantum transition.
The additional 32 bytes come from a third hash, called a degriefer. The authors propose this mechanism to help distinguish legitimate spends from conflicting transactions. This trade-off could become relevant if post-quantum cryptography increases transaction sizes.
How compact Shielded CSV works
For a single-input transaction, the proposal records three 32-byte hashes:
- Nullifier: Identifies a coin being spent and helps prevent double-spending.
- Transaction commitment: Commits to the spending transaction.
- Degriefer: Helps distinguish the intended spend from conflicting transactions designed to interfere with it.
For a transaction with (N) inputs, the authors give an on-chain footprint of ((2N+1)) hashes.
The design builds on client-side validation, an approach proposed by Peter Todd in 2013. Under this model, transaction proofs are exchanged off-chain, while the blockchain records information needed to track spending and prevent double-spending.
Degriefer addresses conflicting transactions
Moving transaction proofs off-chain creates a potential problem: someone observing a pending transaction could copy its nullifier and submit a competing transaction, interfering with the legitimate spend. The paper describes this as a griefing attack.
The degriefer is calculated using the nullifier, the owner’s secret key, and the spending transaction. According to the authors, only the owner can generate the correct value.
The protocol permits the same nullifier to appear more than once on-chain. When the owner supplies proof of the intended spend, the degriefer values help distinguish the legitimate transaction from conflicting copies.
The authors say the mechanism helps distinguish valid spends from conflicting transactions without requiring a full signature on-chain.
Why the proposal uses a separate blockchain
Compact Shielded CSV proposes a separate blockchain partly because its design relies on an economic penalty for miners who include transactions that cannot be proven valid. According to Nick, miners on the proposed chain could lose their block reward and transaction fees for including such transactions. Bitcoin does not impose the same direct penalty for including a conflicting nullifier.
Nick said adapting the degriefer mechanism to Bitcoin would therefore require additional safeguards. Multiple conflicting transactions could also increase the proof data needed to resolve a disputed spend.
The incentive mechanism has not been demonstrated in a production implementation.
Chain reorg remains an open question
Nick noted that the Compact Shielded CSV paper does not discuss chain reorg, in which a blockchain replaces previously confirmed blocks with a different chain history. He said reorg handling is an important part of the existing Shielded CSV design. Incorporating the degriefer mechanism into Shielded CSV would require accounting for those safeguards as well.
The preprint does not specify a consensus mechanism for Compact Shielded CSV or explain how a complete implementation would handle reorg.
What the researchers proved
The authors say they formalised the protocol in Lean 4 and proved two properties within their model:
- Safety: Coins cannot be spent twice, and the total value in circulation cannot exceed the block subsidy.
- Liveness: A valid, unspent coin cannot be permanently blocked by a griefing transaction.
These results apply to the formal model and its assumptions. They do not establish that a complete implementation would be secure against every real-world attack.
Stellar previously outlined a post-quantum plan
Other blockchain projects are also preparing for potential quantum threats, although their approaches differ.
In June, the Stellar Development Foundation had introduced a Quantum Preparedness Plan outlining a phased transition towards quantum-resistant cryptography. The plan targeted support for quantum-resistant signing in enterprise wallets in 2026, followed by a protocol upgrade intended to allow existing accounts to add quantum-safe signers by the end of 2027.
The Stellar plan focuses on upgrading signing infrastructure within an existing network. Compact Shielded CSV instead proposes a separate blockchain designed to limit the transaction data stored on-chain.
Limitations remain
The preprint identifies several unresolved issues that would need to be addressed before the design could be evaluated as a practical system.
Proof delivery: Senders must provide receivers with the off-chain data needed to validate coins. A receiver could deny receiving the data, and the authors say they do not yet have a satisfactory solution.
Growing node data: Nodes must maintain an index of previously seen nullifiers. The authors say this index cannot be pruned and will grow as more coins are spent.
Miner incentives: The design relies on economic penalties to discourage miners from including transactions that cannot be proven valid, rather than cryptographically preventing such inclusion.
Model assumptions: The formal proofs treat hash collisions as impossible and do not cover privacy or all proof-system implementation details.
The authors list coin-join-style multi-party transactions, scripting, payment channels, multi-signature authorisation, cross-chain atomic swaps and off-chain smart contracts as areas for future research.
Compact Shielded CSV remains a research proposal, with no reported prototype or performance benchmarks. Its practical feasibility will depend on resolving outstanding questions around proof delivery, node-data growth, miner incentives and chain reorg.
Also Read: CertiK, Moore Hong Kong Explore Risk Services for Digital-Asset Firms
