A few months later - a Quantum Safe Bitcoin tx on mainnet: https://t.co/qbrXRYXTd6
Thanks to StarkWare's @giladi_tom85141 taking this to the finish line and @MARAFoundation_ Slipstream mining this non-standard tx
Also @robin_linus & @Ethan_Heilman on previous work led to QSB
Today, we're publishing BIP SHRINCS, the first concrete proposal for a post-quantum signature scheme designed specifically for Bitcoin.
The BIP draft turns what began as a rough idea into exact algorithms with an executable reference implementation.
This is an important milestone: the discussion can now focus on analyzing, criticizing, and improving a concrete proposal.
The BIP makes choices ranging from major design questions, such as whether to support flexible XMSS and how to balance signature size against verification time, to the many smaller decisions involved in saving a byte here or there.
All of these choices are up for debate.
Big thanks to Mike Casey, @conduition, @Ethan_Heilman, @kudinov_mikhail, @olkurbatov, Boris Nagaev, and @remix7531 for their contributions to the BIP.
A lot more work lies ahead:
- The draft BIP specifies only the cryptography. Using SHRINCS in Bitcoin Script will require a separate BIP.
- We are working on a security proof for the exact construction and parameters.
- Wallet integration and user experience, for example around backups and recovery after state loss, are still at an early stage. The design space remains wide open.
SHRINCS is not intended to be Bitcoin's "final" signature scheme, and it is not optimal along every axis.
I do think it is a very good trade-off among the options we have now.
bitcoin-dev post:
https://t.co/BHYMfQ5c97
Draft BIP:
https://t.co/rl3X7VdbRy
Goodbye, Poseidon!
An epic 8-year, 8-figure rabbit hole in post-quantum cryptography reaches its dream conclusion. The Ethereum Foundation is abandoning Poseidon for L1, pivoting to SHA or BLAKE. This milestone unlocks ultimate security for lean Ethereum and foreshadows a golden era of hash-based cryptography.
Since 2018, the Ethereum Foundation has invested in magic cryptographic bricks, so-called "SNARK-friendly hashes". In 2019, Poseidon was born. It held strong and became the dominant SNARK-friendly hash, securing billions via zkrollups and zkVMs.
In a stunning reversal, breakthrough SNARK designs show that SNARK-friendly hashes aren't necessary after all. Off-the-shelf traditional hash functions like SHA2 and BLAKE2s can now match Poseidon in a SNARK. In hindsight the key was not SNARK-friendly hashes, but hash-friendly SNARKs.
The secret is doing maths over the smallest prime number: 2. So-called "binary fields" natively speak the language of bits, aligning with the boolean operations inside traditional hashes. This is a stark departure from "prime fields", where awkward large-prime arithmetic makes bit manipulation painfully expensive.
We're talking sci-fi cryptography. 1M traditional hash calls proven per second, on a laptop. Just 100x overhead vs native CPU boolean compute. Nobody predicted such performance, not even the handful of binary-field visionaries. Hat tip to the research geniuses: Jim and Ben with Binius in 2023; Ron, Benedikt and William with Flock in June.
With SHA2, the lean aesthetic of minimal assumptions reaches its climax. The EF's principled stance on pure hash-based cryptography has aged like fine wine. We now enjoy foundations the world can trust for decades and centuries, foundations worthy of the dream of an internet of value.
Speed of deployment is a secondary win. There's no longer a need to wait years for Poseidon cryptanalysis to bake. Emile and Thomas from the EF post-quantum team are moving at breakneck speed with binary fields. The strawmap now points to a production-grade leanVM in 2027, with CL, DL, EL deployments in 2028.
As AI becomes exceptional at cryptanalysis, the contrarian bet to avoid riskier structures like lattices and isogenies is visibly paying off. The past weeks have been brutal. Lattice-based "HAWK" and isogeny-based "SQIsign", both signature schemes in NIST's Round 3, have suffered blows. Sources I trust say more blood is coming.
On AI, the open autoresearch trend kicked off by ECDSA[.]fail is spreading fast, with amazing outcomes from zk[.]golf and SNARK[.]fast. Days ago SNARK[.]fast crossed 1.8M BLAKE3/sec proven on an M3 Max. Stay tuned for fresh autoresearch challenges dropping tomorrow.
Also tomorrow: Ethproofs call #10, dedicated to binary fields. Possibly the most noteworthy Ethproofs call yet. Experts leading the charge will present the future of hash-based SNARKs at 2pm UTC. What an incredible time to be alive. To witness history, DM me for a calendar invite :)
Today I can confidently claim that hash-based cryptography has won out for blockchain post-quantum signatures. SNARK succinctness compresses arbitrarily many signatures into one small proof per block. SNARK flexibility yields k-of-n threshold signatures, complex multisigs, and more.
Ultimate security. Uncompromising performance. Full programmability.
Believe in something. Believe in hashes.
I updated my 2023 roadmap diagram to overlay where the items that were there sit in the current Strawmap ( https://t.co/I35mrXutP2 ).
In general, a lot of overlap, but:
* Some things got reshuffled in order (eg. quantum safety up-prioritized)
* Some things deprioritized (eg. VDFs; many EVM improvements)
* Some things replaced with superior constructions (eg. Verkle -> unified BT -> PBT; state expiry -> new state types)
What's most striking, however, is that some completely new things are in the strawmap that are NOT in this diagram, because they were not in the 2023 roadmap at all. These reflect changing priorities.
Notably:
* First-class attention to strong privacy. This covers: keyed nonces and recent roots, aspects of FOCIL, lean privacy pool & wormholes
* Aggressive scaling in the context of post-quantum. This covers: leanSPHINCS signatures and aggregation, zkzk frames (see https://t.co/ibrOpMxMfO )
* Lean-ification of the spec, to assist in formal verification (full FV of everything is only possible because of modern AI)
* Blob and gas futures (this idea just didn't exist back in 2023)
* Native rollups (SNARKs were nowhere near mature enough to even consider this back in 2023)
* A more open design space for the "future of the EVM". zkzk frames already implies that the protocol will expose to users some ISA that's not the EVM - current leading candidates are leanISA and RISC-V. These ISAs are more simple, modern and efficient than the EVM. Once they're there, why not expose them to developers everywhere? (And then, why not turn the EVM into being an IR on top of that ISA, instead of an enshrined feature massively complicating the base protocol?) Though much of the deeper exploration here is too early even for the strawmap.
* New state types are not just a replacement for expiry, they're a fundamentally different paradigm to how Ethereum does scaling
A common theme in scaling, found in both state types and zkzk frames (both new ideas), is that instead of trying to maximally scale ALL ethereum activity, we try to create specialized mechanisms that have more restrictive properties that make them more scaling-friendly, while supporting the heaviest loads incurred by users and applications today (eg. token transfers, swaps) and tomorrow (eg. privacy protocols).
The other common theme is treating STARKs and AI-accelerated FV as first-class objects, that we are okay betting the technical future of Ethereum on. There are recursive STARKs in many layers of the protocol, one particular primitive (the "aggregate to union verified dependencies" primitive) is expected to be used in *three* places in the protocol: EL, CL and DL. This can only be safe with formal verification, which is itself only feasible with modern AI tools.
In general, many steps forward in maturity. And a huge amount of hard work by many dozens of Ethereum researchers and developers on all of these features.
Ethereum will be quantum-safe. Ethereum will put users' privacy first. Ethereum will be secure. Ethereum will be censorship-resistant. Ethereum will be highly performant and scalable while satisfying the above. And Ethereum will be Lean.
> Since when was bitcoin “only for developers” or coders or engineers?
Life requires you to have a basic understanding of a lot of things. You can't drive a car safely without understanding a bit of physics. You can't navigate personal finances without understanding some math and economics. Indeed, you can't securely use a computer without understanding what a secret is: passwords.
If you want to have control of your money, you need to have a basic idea of what a seed is. Yes, that probably means knowing what a random number is.
Sorry, but there's a limit to how simple things can be if we want to give people control of their money. And yes, that means that a non-trivial part of the world will always be too stupid to actually take full advantage of cryptocurrencies.
@DylanLeClair@BitcoinNewsCom Not until cryptographic agility is achieved to allow for stronger cryptography to be implemented in order to mitigate any threat, be it quantum or AI breaking ECDSA.
@apruden08@dotkrueger@dotkrueger should also put his bitcoin in P2PK address and leave them there as a symbol of his confidence in CRQC being irrelevant.
@CorySwan@IanSmith_HSA Why risk it? It is better to be prepared for something that ends up taking longer than to be caught off guard if it suddenly appears. Robust security is what gives confidence in Bitcoin. Cryptocurrencies should be the spear head of cryptographic security.