Sean Bowe

Zcash developer and crypto researcher, Encrypted Money at Planetary Scale (

[Sean Bowe @ebfull]

Project Tachyon: Scaling Zcash with Oblivious Synchronization.

https://t.co/jmUAjougrB

[Roman Storm 🇺🇸 🌪️ @rstormsf]

@mert https://t.co/LOqeHvQqPx
Has unified zcash address

[Sean Bowe @ebfull]

@badcryptobitch @zksecurityXYZ if we need MPC for something we'll do the smart thing and DM you

[Sean Bowe @ebfull]

Late last year, we decided to use simpler and more conservative cryptography for Tachyon to reduce the chance of bugs. Earlier this year, we hired @zksecurityXYZ to help configure our circuits for formal verification.

Zcash's future shielded pools will all be provably sound.

[Project Tachyon @TachyonZcash]

As we blogged about last month, the new shielded pool we're developing for Zcash will use formal verification, more conservative cryptography, a simple arithmetization, robust APIs, fuzzing, and extensive auditing from humans and AI.

And much more: https://t.co/H3bwCnzuLY

[Sean Bowe @ebfull]

@badcryptobitch @zksecurityXYZ Our older pools only needed witness indistinguishability, but we achieved perfect zero-knowledge anyway (w/ subversion ZK in the past where applicable.)

There won't be any ECC DH key exchange in Tachyon, and signatures remain perfectly re-randomized.

[Sean Bowe @ebfull]

@badcryptobitch @zksecurityXYZ Yep, that's a requirement. The pool needs to be plausibly post-quantum private. The proofs (esp. being DLOG-based) are actually the easiest thing to make information theoretically private. (Our other proofs in Zcash are as well.)

[Sean Bowe @ebfull]

@JohnAlanWoods @oodegen Soundness bugs are hard to spot because ZK circuit code tends to look as though the invariant is being preserved when it isn't.

https://t.co/e8CqD9gvcN

All of them look "outrageously messy" if you just frame it from the perspective of the broken invariant...

[Cypherpunk ($CYPH) @cypherpunk]

Tachyon is bringing battle-tested security to Zcash.

With formal verification every circuit comes with a mathematical proof that it does what it's supposed to.

It will literally become impossible to find bugs in Zcash circuits moving forward.

[CipherScan @cipherscan_app]

Zcash was never down. Our nodes were upgrading to support the NU6.2 network upgrade.

You can verify the chain is healthy right now: https://t.co/cJX5mZM7be

Full thread below on what happened and what we learned.

[Josh Swihart 🛡 @jswihart]

Zcash was never down.

Many block explorers have been using unpatched nodes. Happens with every network update.

Fight the FUD.

https://t.co/dsCHPHMlhw

[Dev 🧪 @zkDragon]

Where were going:
- Every circuit formally verified
- Written in R1CS, the simplest arithmetization
- Automated fuzzing
- Over-audited by humans and an army of AI

[Sean Bowe @ebfull]

Shielded Labs has now funded efforts that helped to discover and remediate at least two major vulnerabilities in Zcash before they could be used by the bad guys!

[Sean Bowe @ebfull]

@zkDragon @yxNomad @zodl_co The key is generated deterministically at startup by all clients.

[Zcash Open Development Lab @zodl_co]

@DefuseSec @ZcashFoundation Excellent work, Taylor. Thank you for helping keep the Zcash ecosystem secure. 🫡

[Taylor Hornby 🛡❤️ @DefuseSec]

Zcash unambiguously has the best security response in the world, thanks to @zodl_co and @ZcashFoundation engineers.

[Project Tachyon @TachyonZcash]

As we blogged about last month, the new shielded pool we're developing for Zcash will use formal verification, more conservative cryptography, a simple arithmetization, robust APIs, fuzzing, and extensive auditing from humans and AI.

And much more: https://t.co/H3bwCnzuLY

[Zcash Open Development Lab @zodl_co]

https://t.co/oRMstGLqp5

[Dev 🧪 @zkDragon]

Zcash's "internal viewing key" and "external viewing key" separation were done in 2022 to ensure a quantum attacker _could not_ leak privacy for when you spend your funds.

Pretty cool to know this has always been accounted for.

[Cypherpunk ($CYPH) @cypherpunk]

The shielded and transparent pools in Zcash are mathematically independent.

Even if 99% of ZEC were transparent, the privacy of the shielded 1% would be determined only by the shielded pool itself.

Transparency doesn't dilute encryption.

Very few *actually* understand this.

[Sean Bowe @ebfull]

> In the current Tachyon design, would it still be possible for a user to reasonably operate completely independently by running their own full archival/proving/PIR stack, or would the resource burden make third-party service dependency inevitable in practice?

It needs to remain possible and permissionless for anyone (with the resources) to run an archival/full node. Clients already do proving, and PIR's main purpose is to have a way to query an external archive node privately, so you don't need it at all if you have your own.

I do think the resource burden will be too high for the average person to do this, though, at some scale. But the average person will not do it even if they could, and so because you can rely on RPCs using PIR without giving up custody or privacy, I'm not sure that it matters...

[Sean Bowe @ebfull]

I don't think we really disagree about that. Was there a part of my post above that contradicted anything you just said?

I tried to be careful to say "recovery from seed from blockchain" precisely to distinguish from mere "recovery from seed" because the discussion was about using the blockchain to recover access to your on-chain wallet history, not really about custody.

My argument is that:
1) it's not sustainable for the network, because the blockchain is not an ideal permanent storage location for every person's transaction history for the entire planet
2) even if it were sustainable, most people will use third party services to interface with the chain in order to recover from it anyway (for several practical reasons), so if your goal is to solely rely on blockchain availability I think you've already lost for 99% of people
3) if third party services are needed for most users, I don't see the moral distinction between using them to interface with the chain and using a third party service to help you recover from off-chain backups. There would be a distinction if the trust model is different, but I don't think it needs to be: you don't need to trust these services (in either case) with your privacy or your custody to maintain wallet history backups for you. It's encrypted, it can be replicated...
4) my final conjecture is that a substantial class of users will find more intuitive models for backup & restore, and those will inevitably require the help of third-party services. I use this as supporting evidence for the philosophy, not necessarily as an endorsement for those models. (I think self-custody and trust minimization are very important! I practice them too.)

FWIW many new scalable (private) payment protocols (Shielded CSV, Lightning, etc.) also cannot rely on on-chain backups either, for this exact same reason, or for even more compelling ones. And it has nothing to do with whether those protocols incorporate seedphrases somehow, which they do!