S15 E58: Eagen, Linus & Jonas Nick on Shielded CSV

Some interviews start with a pitch from a PR agency. This one started with a direct message from Robin Linus that basically said: Bitcoin is not private, check this out. Attached was a paper. Not a whitepaper with a token sale stapled to the back, but a proper piece of cryptography research called Shielded CSV: Private and Efficient Client-Side Validation, written by Robin, Jonas Nick and Liam Eagen.

The timing was almost poetic. Client-side validation is an idea that Peter Todd wrote about many years ago, and the week we recorded, HBO's "Money Electric" documentary had just nominated Peter as its favorite Satoshi Nakamoto candidate. So, as I put it at the top of the show, we were talking about "a concept that was first created by someone who might just be Satoshi according to HBO," which was then made private with zero-knowledge proofs.

The lineup was a small dream team. Jonas Nick works on research at Blockstream and had been on the show once before, back in S6 E9 with Peter Todd and Alekos Filini. Robin Linus of ZeroSync and BitVM was making his second appearance of the season, after S15 E13. And Liam Eagen of Alpen Labs, a mathematician with great hair and an even greater beard, was joining me for the first time. What followed was almost two hours of shielded transactions, OP_CAT drama, block size heresy, quantum doom and, inevitably, rare Pepes.

What Client-Side Validation Actually Is

Liam took the first swing at the basics. A blockchain, he explained, is invented to prevent double spending, "but it actually does two things in the case of Bitcoin": it stops double spends, and it also validates every transaction published to a global public ledger. Client-side validation splits those jobs apart. Rather than putting whole transactions on chain, "we can keep them off chain and only put commitments to transactions on chain."

The catch is history. To trust a coin you receive, you have to check every transaction that came before it, and as Liam warned, "that history blows up exponentially over time." Another co-author picked up the thread and described how the receiver doesn't just verify one payment, but "essentially a whole graph of a whole tree of transactions." Without some cryptographic magic, the advantage over regular Bitcoin "is not particularly large."

That magic is recursive proofs. Shielded CSV builds on proof-carrying data, so every coin travels with a compact zero-knowledge proof that its entire past was valid. On the chain itself, each transaction leaves behind only a small piece of data that the paper calls a nullifier, which is enough to stop double spending and nothing more.

When I tried to translate this into pleb language by saying they were adding more state to Bitcoin, I got corrected immediately: "actually less state." Then came the elevator pitch I should have led with. The protocol "increases the on-chain throughput to about like a hundred transactions per second," and it hides both the transaction amounts and the transaction graph.

A Separate System That Still Needs a Bridge

One of the authors was honest about the elephant in the room. Shielded CSV borrows Bitcoin's blockchain for double-spend security, but "the Bitcoin system is a separate system." To actually bring privacy to bitcoin the asset, you need a way to move BTC in and out, which means peg-ins, peg-outs and a bridge.

That is where Robin's other famous project comes in. When I teased him about why there are so many versions of BitVM ("It's a hype topic," he deadpanned), he got serious quickly: "BitVM is definitely a real breakthrough because now we can build these bridges." Shielded CSV, he added, "would be much less interesting if we didn't have BitVM." A soft fork that allowed bridge contracts to be verified directly on chain could offer even better security, but that path depends on consensus nobody has yet.

As for how users would touch any of this, the answer was refreshingly unhyped. First they have to implement the protocol. Wallets come later. Atomic swaps between the Bitcoin main chain and Shielded CSV are supported in the design, and swaps with Lightning are possible too, but because shielded transactions are commitments in Bitcoin blocks, you still wait for confirmations. Instant, trust-minimized, Lightning-compatible shielded payments "are currently an open question."

Lightning as a Settlement Layer, Not a Consumer Product

Somewhere in that discussion, one of my guests dropped a line that will annoy a lot of Lightning maximalists: "lightning doesn't work for end users as well as people had wished." That, he argued, is why so many custodial solutions exist. But as a settlement layer between ecash, rollups, sidechains and protocols like Shielded CSV, "it can work really well."

I reminded everyone that atomic swaps across chains were one of the original Lightning promises, a way to trade Bitcoin, Litecoin and even Monero without centralized exchanges. It never really happened. The answer pointed at a known culprit: the free option problem, which makes "these atomic swaps quite quite problematic in practice."

How It Compares to Zcash and Monero

Naturally, I had to ask how a Bitcoin-native shielded layer stacks up against the privacy coins I keep bringing on the show. Jonas said that part of the motivation behind Shielded CSV was to show that there is "an alternative approach to private cryptocurrencies that seems to be better in many dimensions." The privacy is essentially the same as in Zcash, with "some very minor" differences, but with one huge advantage: "there are no big zero-knowledge proofs on the blockchain."

Liam explained why that matters beyond saving block space. Because proofs travel peer to peer instead of living on chain, you can use heavier proof systems. A STARK that would be tens of kilobytes is unacceptable for an on-chain transaction, but "sharing it peer to peer is a negligible additional cost."

Then came my contrarian question. Why bother building something this complex on Bitcoin when you could just swap BTC for Monero or ZEC? The reply was short: "People want to use Bitcoin, no?" The market has spoken about which asset is most valuable, and Bitcoin "should be used as a currency." Swapping into Monero and immediately back doesn't really work either, as one of them noted, because the round trip itself can be correlated on chain. You'd have to actually hold Monero, and "most people, I don't think, want to hold Monero just to get privacy."

OP_CAT, STARKs and the Covenant Wars

Since StarkWare was sponsoring the show at the time, and since they were loudly campaigning for OP_CAT, I asked the panel what they thought about STARKs coming to Bitcoin.

The first answer framed the debate in terms of bridges. Whether you use BitVM, OP_CAT with a STARK verifier, or something else, the criticism "is not an argument so much against STARKs per se, as it is against like the concept of the bridge in and of itself." OP_CAT would allow a proper STARK verifier on chain, but "that does have significant on chain costs."

Another guest went further and refused to call CAT a covenant proposal at all. "It is true that CAT can emulate covenants in a very clunky and expensive and weird way," he said, but if we want covenants, we should discuss real covenant designs like TXHASH or the introspection opcodes that exist on Liquid. His bigger worry is scope: CAT "enables everything in at least some clunky way," which makes it "hard to reason what it can do and what it cannot do." Still, the conclusion was constructive. Bitcoin needs some way to verify proofs eventually, because "proof systems are the future for sure."

Later I noticed that nobody had mentioned CTV, and I said so. The strongest technical argument against it, I was told, is "that it's actually too limited." For BitVM in particular, a covenant that can commit to inputs would remove the trusted setup, and CTV only commits to outputs. The wish list that did come up was the Great Script Restoration, which brings back the opcodes from Satoshi's original implementation, along with big integer arithmetic. "Anything that gets us closer to SNARK verification would make bridges a lot simpler and a lot more secure," as one of them summed it up.

The Taint Question and the Economics of Privacy

Of course I had to ask whether coins that pass through Shielded CSV would come out "tainted" in the eyes of exchanges and the Michael Saylors of the world. The answer: an exchange only sees "that they receive a valid coin," with no visible history. They can refuse shielded coins outright, but they can't single out the bad ones, because "all of them look the same to them." Exits from the shielded system might be visible depending on how you do them, but the regular notion of taint doesn't apply.

Then came the part I found most hopeful. If the protocol is widely adopted, nobody can be blamed for using it. And because it is a scaling solution as well as a privacy tool, users "contribute to the anonymity set in a pro social way." In his words: "It's not like more expensive to be private, it's actually cheaper."

Fees work through publishers, who batch shielded commitments into blobs, pay miners to include them, and collect fees from users. Regardless of how large the shielded transaction is, the commitment that goes on chain "is 64 bytes," far less than an average Bitcoin transaction, and that is where the speedup comes from. My dreams of fitting 60,000 transactions into 64 bytes were quickly crushed, though. To reach 100 transactions per second, "you would need to have a full block full of shielded transactions." The upside is that such a block is much cheaper for full nodes to verify than a block of normal transactions, and it doesn't bloat the UTXO set.

And if the receiver is offline? The sender can post the commitment on chain and leave the coin on a server, and if the server deletes it, the sender simply resends. That's a big difference from MimbleWimble-style protocols, where sender and receiver need back-and-forth communication and both have to be online in some sense at the same time.

Robin Asked God About the Block Size

This is where things got delightfully spicy. Because Shielded CSV transactions are so cheap to validate ("you just have to hash for them," with no signatures to verify) and don't load the UTXO set, Robin argued that "if that protocol catches on" we should think about increasing the block size. The bottleneck would become the network, but he believes networks will keep getting faster.

So I asked him for a number. "I asked God and God told me the perfect block size is of course 32 megabytes," he joked, before admitting that "it's up to debate." Another guest preferred caution: the environment is very different from the last time this question came up, so "I would rather see actual simulations and data before forming an opinion on that."

I used the opportunity for one of my favorite rants. People have been indoctrinated to believe that because Bitcoin rejected a block size increase back in 2015, it agreed never to raise it. In my view, many who said no back then objected to the terms and the pressure of the New York Agreement, not to bigger blocks in principle. With fees bound to rise, users deserve something better than "just use Liquid or just use custodial Lightning." I joked that I'd get my guests canceled for this conversation. I'm only half sure I was joking.

The block size also reappeared in the quantum section, because post-quantum signatures are much larger than today's. With a fixed limit, as someone pointed out, we might "only be able to fit one transaction per second into the Bitcoin blockchain."

Drivechains, Soft Forks and Rough Consensus

Jonas brought up rough consensus, which prompted me to admit that "I don't think anyone knows exactly what rough consensus means." The panel described the dilemma well. On one hand, if it were easy to change Bitcoin, "it would be very easy to attack it or to weaken it in ways that might be devastating," so the process must stay rigorous and slow. On the other hand, Bitcoin can't stand still while other chains innovate much faster.

Quantum Computers: Satoshi's Coins and Google's Hype

The quantum segment opened with a practical proposal: to protect Taproot outputs, Bitcoin needs a way to disable the key spend path, so that "even if you know the key you cannot spend from it, you can only spend from the script," and that script could hold a quantum-resistant signature scheme. A Rootstock developer had presented a Winternitz-style scheme in Frankfurt a couple of weeks earlier, which one of my guests described as "just a form of Lamport signatures essentially."

When I asked how imminent the threat is, someone immediately passed the ball: "Liam is the cryptographer here." Liam laughed that he's "not a quantum computer expert" and pointed to Scott Aaronson's recent warnings. The real problem in Bitcoin, the panel agreed, is that there's no plan that actually works yet.

We also went down the familiar rabbit hole of Satoshi's coins. Many early coins sit in pay-to-public-key outputs that a quantum computer could steal, while pay-to-public-key-hash outputs are safer until spent. Freezing vulnerable coins with a soft fork "could be considered stealing" too. One of them suggested a cleverer route: a protocol where you prove knowledge of the hash preimage and a signature without revealing them, "a snarky kind of post quantum solution."

Then the skeptics took over. Google, one of them noted, usually produces devastating results, like an AI that crushes a world champion and then a successor that beats the old system 100 to zero. On the quantum side, by contrast, they come up with "hand wavy, hype driven things" that "don't have much substance." Someone else pulled up the quantum records on Wikipedia: the largest number ever factored that way is 21. As in, three times seven. "Which is not very impressive."

Self-Custody, Threat Models and a TABConf Correction

After the Hodling.ch read, I asked what kind of setup an average long-term holder should use. "Complexity is the enemy of security, that's for sure," came the first answer. Twelve words alone isn't good enough, but "some multisig setup would be good, but like not some complicated thing." And it all depends on your threat model: if yours includes a malicious hardware wallet manufacturer, you need multisig or no hardware wallet at all.

That reminded me of a well-known developer who lost coins kept on an internet-connected server, reported it to the FBI, and whose case ended with a conference in Atlanta being asked for attendee email addresses. For the record, and Michael Tidwell made me promise to say this: it was not TABConf. Two of my guests had assumed it was. "Don't flame TABConf," we agreed, and someone added that it's awesome and they should sponsor the show.

Timeline, Business Models and the Federation Idea

How long until Shielded CSV exists as software? There's a big gap between a proof of concept and mainnet. The paper deliberately doesn't even pick a hash function. As one of them explained: "We just tell you the properties that a hash function should have." That research, along with choosing the recursive proof system, has to happen before implementation can really start.

Business model? This might be the least VC-friendly answer in my show's history. Transaction fees won't make anyone rich unless you process "billions and billions of transactions." One guest said flatly, "I don't believe in any bullshit business model that creates all kinds of bad side effects." Publishers could earn small fees, but "anyone can become a publisher," so it's "essentially a race to the bottom." The same goes for offline-receiver servers and BitVM operators. The purest path, they agreed, would be research grants.

One interesting alternative did surface. Commitments don't have to live on the Bitcoin blockchain; they could be sent to a federation while still bridging to Bitcoin, with trust-minimization tricks so that a coin confirmed long enough can't be stolen. That would mean no Bitcoin fee per 64-byte commitment and instant confirmations. My reply: there's a reason Liquid and Rootstock didn't get much traction. They're not really trust minimized.

They also confirmed that while their Rust specification supports a single asset, multi-asset support would be "quite easy," including Tether. Yes, technically you could mint Vladcoin on it. No, they don't see "a legit reason why you would add a token."

Why Client-Side Validation Might Be the Future

When I wrapped up by saying they weren't very good at selling their own work, one of them objected: "I disagree, by the way." Client-side validation, he said, "will probably be the future of blockchains, at least when it comes to payments," because "it's vastly superior to most other approaches." Global-state applications like AMMs are a different story, but for processing payments, it's the best approach we know.

So why the delay? "Without SNARKs, it's essentially a bit of a joke," because the history grows too quickly. Combining CSV with SNARKs "is what gives you the breakthrough," and it only became possible recently, with Plonky2 described as "probably the first proof system that is fast enough to enable client-side proving" on consumer hardware.

Liam, who was a little sick that day, admitted he also struggles with self-promotion, at which point a co-author jumped in: "I don't struggle with Liam promotion. Liam is awesome." Robin also clarified his views on proof of stake: classical proof of stake "tries to secure itself with itself which is kind of absurd," while Bitcoin-backed staking interests him because it uses an external resource.

Rare Pepes, Phil Zimmermann and Pieter Wuille Facts

No Bitcoin Takeover episode is complete without a detour. One of my guests' girlfriend draws rare Pepes for people, not inscribed or tokenized, just drawn, and we briefly wondered whether our numbers are prime. I used the moment to vent about a run-in with PGP creator Phil Zimmermann, who lectured me about Pepe as a hate symbol, which struck me as ironic given that PGP itself was once framed as dangerous technology in the hands of America's enemies.

There was also a lovely moment about learning. One of the guests said he answers every good question people send him on Twitter or Telegram, because that's how he learned: people like Pieter Wuille and Andrew Poelstra "were super approachable on IRC," and he feels obligated to pass that on. Which led me to confess that I'd tried hard to book Pieter Wuille, pitching him on reacting to the Chuck Norris-style facts website about him.

If you want to follow the project, the code and paper live on the Shielded CSV GitHub, and the paper's introduction and technical overview are, as they promised, "not too complicated." You can find Jonas as @n1ckler on X (he said I can call him Nick, but it makes him feel like he's back in the army), Robin as @robin_linus, and Liam under his own name. And if you watched this far, they asked for one thing: leave a comment with a shield emoji.

Two years later, this episode reads like a time capsule from the moment Bitcoin privacy research quietly got exciting again. If you want more Robin, go back to S15 E13, then jump forward to S17 E4 on BitVM optimizations, where Robin and Liam returned together.

Listen to Liam Eagen, Robin Linus & Jonas Nick on Spotify, Apple Podcasts, YouTube, and More

Watch on YouTube

Time stamps:

00:00:51 – Introduction
00:02:09 – What is Client-Side Validation?
00:04:20 – Trade-offs in Client-Side Validation
00:05:18 – Comparison with Existing Protocols
00:09:21 – On-chain Throughput and Privacy
00:09:55 – Connecting Bitcoin and Shielded CSV
00:11:07 – User Interaction with the Protocol
00:12:22 – Challenges with the Lightning Network
00:14:56 – Atomic Swaps and Compatibility
00:16:12 – Shielded CSV vs Monero & Zcash
00:19:28 – Discussion on STARKs
00:21:46 – OP_CAT and Covenants
00:24:03 – OP_CAT and Functional Encryption
00:25:21 – Exploration of BitcoinOS
00:26:11 – Potential of BitVM
00:28:21 – Bitcoin as a Currency
00:30:40 – Funding for CSV Projects
00:31:14 – Taint Concept in Shielded Transactions
00:34:08 – Adoption and Privacy Protocols
00:35:08 – Transaction Fees in Shielded Transactions
00:36:04 – Throughput and Base Layer Efficiency
00:38:12 – Node Behavior During Transactions
00:39:41 – Comparison with MimbleWimble
00:40:29 – Cryptosteel’s New Device
00:41:04 – Drivechains
00:43:51 – Concerns Over Soft Forks
00:45:04 – Rough Consensus Definition
00:46:15 – Challenges of Soft Fork Implementation
00:47:29 – Balancing Stability and Innovation
00:48:38 – Miner Incentives and Fee Structures
00:49:44 – Future of Post-Quantum Proposals
00:50:00 – Increasing Block Size for CSV
00:53:08 – Ideal Block Size Debate
00:59:02 – Quantum Computing Threat
01:00:24 – Potential Consequences of Quantum Attacks
01:02:23 – Post-Quantum Solutions
01:02:50 – Quantum Computing Timeline
01:03:31 – Complexity of Quantum Computers
01:05:44 – Quantum Records and Limitations
01:06:12 – Chat Question on Shielding Protocol
01:06:45 – Hodling.ch
01:09:15 – Self-Custody Security
01:09:58 – Threat Models in Security
01:10:33 – Hardware Wallet Cautionary Tale
01:12:05 – Conference Discussions
01:13:58 – Shielded CSV Funding and Development Timeline
01:15:29 – Prototype Development Outlook
01:17:31 – Concerns Over Adoption
01:19:34 – Scalability vs. Privacy Debate
01:22:04 – Tether on Shielded CSV?

01:22:22 – Revenue Models Discussion
01:23:25 – Transaction Fees and Profitability
01:24:16 – Publisher Fees in CSV Protocol
01:25:40 – Competition and Business Models
01:26:07 – Soft Fork Proposals for Improvement
01:27:30 – Script Restoration and Arithmetic Improvements
01:37:23 – Future of Shielded Client-Side Validation
01:38:44 – Keeping Up with Developments
01:41:05 – Self-Promotion and Team Dynamics
01:42:51 – Proof of Stake?
01:43:56 – Rare Pepes in Shielded CSV
01:46:18 – Acknowledgment of Guests
01:47:57 – Call to Action: Shield Emoji
01:48:07 – Importance of Learning Bitcoin
01:48:31 – Resources for Learning Bitcoin
01:49:26 – Commentary on Pieter Wuille
01:50:02 – Block Size Debate
01:51:05 – Optimizing Bitcoin for Global Use