Paul Sztorc's June 10 Twitter Space: Zcash, The Ideal Block Size & the Cultural Battle for Ecash
Two months out from the August 2026 hard fork, Paul Sztorc hosted another two-hour Twitter Space on June 10. The call was lighter on hard announcements than recent weeks but heavier on philosophy, technical reasoning, and one of the most heated exchanges of the entire run-up to launch.
Below is a summary of what was actually discussed, in roughly the order it came up.
Warsaw Film Fest Ecash Posters
Vlad opened the call by celebrating the slasher-style movie posters that ran at the Bitcoin Film Fest in Warsaw, which was held next door to MoneroKon. He estimated over 500 attendees walked past them, and the organizer sent a video showing small groups stopping to discuss the imagery.
Sztorc, who is half Polish, was amused that he ended up portrayed as something between a serial killer and "the undertaker of Bitcoin." The broader point was that the posters generated conversation in physical space, which Sztorc views as essential ahead of the August fork.
The Zcash Bug Panic
The first substantive question came from JCB, who asked Sztorc to make sense of the recent Zcash price crash. Sztorc framed it as a case study in the new reality of AI-assisted code auditing. The Zcash team hired auditors, one of whom used LLM tooling to find a bug, the team patched it quietly, and then disclosed it. Disclosure, rather than the bug itself, is what triggered the price collapse.
Sztorc compared it to the parable of painting a white stripe on a healthy gazelle: even a fundamentally fine animal gets hunted down by the pack once it stands out. His objective reading was that Zcash did everything correctly, but in the current environment, the market punished transparency.
This led naturally to a discussion of how AI changes the security landscape. Humans struggle to read code; LLMs inhale it. Sztorc expects AI auditing to become dominant, and he expects more projects to face Zcash-style episodes.
Why Ecash Does Not Need a "Cavalry" of Developers
JCB followed up by asking what Ecash's developer bench looks like. Sztorc said the team has about ten developers, some enthusiastic about AI tooling and some skeptical, and he considers that healthy. But the deeper point was structural: Ecash is designed to not depend on a cavalry of in-house developers.
The L1 will be essentially Bitcoin Core with the minimum changes required to split the network and name it differently. The L2s will inherit from their upstream projects. The Zside drivechain, for example, simply uses the Orchard Rust crate; when Zcash patches it, Zside patches it. Sztorc framed this as having the cake, eating it, and getting paid to eat it. He cited Bitcoin Cash's struggles with funding Amaury Séchet through coinbase allocations as an example of how dependence on a small in-house developer team has historically destroyed projects. Drivechains, by contrast, let L2s compete with each other, which he believes will hold quality in line without any central coordination.
KREV23 and the Layer 2 Custodian Argument
A caller going by KREV23 came up to argue that L2s are inherently a legal trap, because anything operating "above" the base network looks like a custodian to regulators. He cited Tornado Cash prosecutions as evidence that legal ambiguity gets weaponized regardless of technical reality.
Sztorc partially agreed, in the sense that those prosecutions were unjust, but pushed back on the blanket framing. Not every L2 is custodial. Some clearly are, some clearly are not, and treating them as uniformly dangerous gives regulators more power than they actually have. He also noted that early Bitcoin Core developers were similarly convinced they would go to prison, and that the predicted prosecutions of Vitalik Buterin for Ethereum's launch never materialized. The legal terrain is arbitrary enough that paralysis is the wrong response.
KREV23 returned several times throughout the call, eventually advocating a return to CPU mining and arguing that the entire L2 ecosystem is a Federal Reserve-friendly capture mechanism. The exchanges got progressively more heated.
Drivechains as a Bandwidth Bet, Not Originally a Scaling Bet
Justin asked the most analytically interesting question of the call: among all the scaling solutions Sztorc evaluated, why did drivechains win?
Sztorc's answer reframed the entire premise. In 2015, when he designed BIP 300, he was not thinking of drivechains as a scaling solution at all. He was thinking about the block size war and trying to answer one question: can the small blockers and large blockers both get what they want simultaneously? Drivechains were originally a peace treaty, not a throughput play.
Two things changed his view over the following decade. First, the other scaling ideas mostly failed. Lightning, which he once expected to work well, he now considers a cultural problem more than a technical one. Federated systems like Liquid and Fedimint cheat on custody. Spider Chain just announced its shutdown. Second, the bottleneck shifted. In 2015, bandwidth was the binding constraint, particularly upload bandwidth and Tor bandwidth. Today, with Starlink and routine 120 GB game downloads, the bandwidth concern is essentially obsolete. The remaining bottleneck is software maturity and user attention.
He concluded that drivechains turned out to be sufficient for scaling to eight billion users, and that the right path forward is for developers to fork existing L2 drivechain node implementations and improve them, rather than inventing new mechanisms for packing more transactions into L1.
Why Node Costs Are a Time Bomb but Mining Costs Are Not
KREV23 pressed on why small blockers obsess over node bandwidth but not over mining costs, given that ASIC concentration is itself a centralization problem. Sztorc's response was one of the cleanest expositions of the asymmetry he has offered publicly.
Mining cost increases produce a self-correcting feedback loop. When mining gets too expensive, miners exit, difficulty falls, and equilibrium restores. The system has a steering wheel. Node costs do not work this way. They accumulate permanently. If nodes become too expensive to run, the network silently enters an unrecoverable state because there is no feedback mechanism to pull people back in. He compared it to the Futurama joke about dropping a bigger ice cube in the ocean each year to solve global warming.
He also took a swipe at Peter Todd, recalling a TabConf moment where he asked Todd whether he would support removing upward difficulty adjustments, given Todd's stated worry that drivechains would make mining too expensive. Todd, predictably, could not say yes.
A Live Debugging Session With Shomari
A builder named Shomari came up to report that the Cygnet test network had reset roughly 40 hours earlier and his Bitwindow installation was stuck on block 400 or so. This led to an extended, surprisingly productive live troubleshooting session. The Cygnet challenge value had changed after the recent bug bounty fixes, and Sztorc had communicated the update only in the Telegram group. Shomari, who deliberately does not use Telegram, had been relying on dev.txt as his source of truth.
Sztorc admitted he had been too lazy to update dev.txt, partly because he had no confirmation anyone actually read it. Shomari said he checks it multiple times a day and described it as his gospel. Sztorc updated it during the call. Shomari also reported a Bitwindow bug on macOS where version .113 and .114 hang on the seed phrase import screen while version .77 works correctly. He posted a screenshot in the chat for the team to investigate.
The exchange was notable mostly for what it revealed about the project's state: real builders are now testing real wallets against the live testnet, finding real bugs, and getting them fixed in real time.
Mining Pools as Disappointing Cultural Actors
JK asked whether mining pools might eventually fund Ecash development the way Carnegie or the Medici family funded research and art. Sztorc was openly pessimistic. With the partial exception of Marathon's media operation and Luxor's analytical work under Nick Hansen, mining pools have proven culturally passive, sometimes counterproductive.
Saylor's attempted Mining Council went nowhere. Foundry's anti-environmental-FUD efforts fizzled. Sztorc attributes this partly to the block size war training miners to have no opinion, and hopes a new chain with a new culture might produce different behavior.
Sidechain Activation Mechanics and Launch Day Chaos
GB asked whether the 256-sidechain cap could be reduced to address concerns about a flood of low-quality drivechains tarnishing the category. Sztorc said miners can effectively impose any limit they want by refusing to vote for additional sidechains. He also recounted that Matt Corallo, back around 2019, had suggested that each new drivechain should require Bitcoin Core review. Sztorc considered this then rejected it, viewing drivechains as fundamentally a hedge against Bitcoin Core remaining rational, a quality he believes has declined.
On activation, the 90 percent miner-signaling threshold from BIP 9 remains in BIP 300. Sztorc defended it on the grounds that miners benefit from activating drivechains via fee revenue, so they should be biased toward activation. If 90 percent cannot be reached over two weeks, achieving the three-month withdrawal threshold becomes implausible anyway.
Launch day will be chaotic. The difficulty reset means blocks will fly through quickly, then potentially overshoot into 30-minute blocks before adjusting back. Sztorc seemed unbothered, calling the chaos part of what keeps the project punk. The current plan is to activate all seven sidechains essentially simultaneously through a one-time forced signal, similar in spirit to how BIP 148 helped activate SegWit.
Exchange Outreach Strategy
GB also asked whether exchanges were being approached about the airdrop. Sztorc said yes, but in the correct order: first the bug bounty rounds, then the software polish, then outreach building from small wallets and swap services upward. He wants the exchanges to receive a gift-wrapped product, not a moving target. The technical integration should be trivial because the L1 is just Bitcoin Core. Larger exchange pushes will likely happen around 30 days before the fork.
The Final Confrontation Over L1 Block Size
The most heated portion of the call came at the end. Joe asked whether reducing the L1 block size below Bitcoin's would create ugly UX, particularly for users moving savings between drivechains via L1. Sztorc admitted his thinking has shifted considerably. He originally proposed a smaller L1 block size as a rhetorical point against Bitcoin Cash and BSV, demonstrating that Ecash could out-small-block BTC while still offering scale through drivechains. He now thinks almost no one cares about this argument, and that keeping the L1 identical to Bitcoin Core is both more honest and a cleaner experimental design. The August fork should be a referendum on BIP 300 alone, not a mishmash of changes.
This was when KREV23 returned with full force, accusing Sztorc of listening to small-blocker "retards," insisting fees must be in single-digit pennies on L1, and arguing that drivechains plus cheap L1 fees is the actual killer combination. The exchange got personal, with KREV23 attacking Sztorc's audience selection and Sztorc closing the call shortly after. The disagreement was real, but Sztorc's stated direction now aligns more with KREV23's position than it did a year ago, which neither party seemed to fully register in the heat of the moment.
Satoshi Was Assassinated and Replaced?
KREV23 also offered an unexpected theory: that Satoshi was assassinated shortly after Bitcoin's launch and replaced by an impostor who introduced the one megabyte block size limit. Sztorc engaged with it more graciously than expected, noting it would require the impostor to have matched Satoshi's distinctive writing style across hundreds of forum posts. Sad Scholar pressed on whether KREV23's view changes if there was already an effective 32 megabyte cap built into the original message structure. KREV23 maintained it was a belief rather than a theory.
On coin types, Sztorc reluctantly conceded that Ecash will adhere to SLIP-44 standards for BIP 44 derivation paths despite his personal contempt for the spec, because the alternative is breaking compatibility with every wallet on earth. For the L2 derivation, he successfully argued for using sidechain numbers directly.
What This Call Revealed
Compared to the May 27 and June 3 calls, this one had less news and more texture. The Warsaw posters landed. The bug bounty is producing real findings. Real builders are now writing real wallet code against the testnet. Sztorc's L1 block size position has quietly migrated. The exchange outreach is being staged deliberately. And the cultural arguments, particularly around Lightning, around mining pool passivity, and around Bitcoin Core's declining rationality, are now treated as settled background rather than active claims requiring defense.
The single most important shift from earlier weeks is Sztorc's open admission that he was wrong about smaller L1 blocks being a useful design choice. Whether that change makes it into the actual August fork code remains to be seen, but he sounded fully persuaded by the end of the call.