stop being retarded, fellow bitcoiners.
AI conspiracy confirmation slop is rotting your brains.
bitcoin development is robust, it doesn't need your "help".
fighting to erode or override IETF-like consensus process is a BAD IDEA, and will be forcefully rejected by the market.
The signing math
When you sign a message with Ed25519, two values get published on-chain as your signature: R and s.
They're computed like this:
- R = k · G (k = the secret nonce, G = a fixed public point)
- s = k + H(R, A, M) · a
Where:
- k = the nonce (must be secret)
- a = your private key (the thing that must never leak)
- A = your public key
- M = the message (transaction)
- H(...) = a hash anyone can compute from public data
(Simplified, the real scheme works modulo the curve order and the nonce is derived from a secret value inside the seed, not the raw seed. But the shape below is exactly what matters.)
Both R and s are public. They're literally in the signature on the blockchain.
Now solve for the private key
Look at the second equation and rearrange it:
a = (s − k) / H(R, A, M)
Everything on the right side is public except k, the nonce. So the only thing protecting your private key a is that nobody knows k.
That's the whole game. Secrecy of k = secrecy of your key.
What SecondFi broke
Correct Ed25519 derives the nonce from a secret:
k = H(secret_seed, M) ← depends on something private
You can't recompute k, because you don't have secret_seed.
SecondFi instead did something equivalent to:
k = H(M) ← depends ONLY on the public message
Now anyone reading the chain can:
1. Read the transaction M → compute k = H(M)
2. Read s and R from the signature
3. Compute H(R, A, M)
4. Plug into a = (s − k) / H(R, A, M) → recover the private key
A toy numeric walkthrough
Forget elliptic curves; use plain arithmetic to see the shape.
Say:
- Private key a = 7 (secret)
- Message hash H(R, A, M) = 3 (public)
- Nonce k = 5
Then the published signature value is:
s = k + H·a = 5 + 3·7 = 26
Good system: an attacker sees s = 26 and H = 3, but not k. Two unknowns (k and a), one equation unsolvable.
SecondFi's system:
the attacker recomputes k = 5 from public data.
Now:
26 = 5 + 3·a → a = (26 − 5) / 3 = 7
The private key falls right out. One signature, no guessing.
Why this beats classic "nonce reuse"
The famous bug, the one that broke the Sony PlayStation 3 and some early Bitcoin wallets, was reusing the same k across two different messages. That took two signatures to cancel the unknowns and solve.
Here you need only one, because k isn't unknown at all. It's computable from data already on chain. Every single transaction a user ever signed is a standalone leak of their key.
The fix was never "understand the curve math." It was "don't be the one writing it."
Libsodium and noble/ed25519 are good examples: both open, both audited, and both give sign() no parameter to supply the nonce.
After my sabbatical, I have decided to step down as co-executive director and board member of the Ethereum Foundation (@ethereumfndn), effective today.
That time gave me space to reflect on my priorities and the kind of life I want to build next. During my break, Bastian (@aerugoettinea) guided the transition with care and thoughtfulness, and I appreciate the work he and many others have put into that process. Over time, I've come to feel that this is the right moment for me to step back.
Serving as EF co-executive director let me see the bigger picture of how the Ethereum community collaborates. I'm proud of what we've accomplished, not only at the EF, but across the builders, researchers, educators, node operators, validators, users, and many other contributors who have helped build, maintain, secure, and use the infrastructure and applications on top of it.
What I will remember most is the people behind the work. We come from different places, speak different languages, and build different things. But the purpose that brought so many of us here remains the same: building a world that no one can shut down, making systems more open, resilient, and more access to anyone, anywhere.
Ethereum has always been bigger than any one role, any one organization, or any one moment. Its strength comes from those who keep building permissionless infrastructure across the ecosystem to unlock freedoms that didn't exist before.
To everyone at the EF and across the Ethereum community who made this journey meaningful, memorable, and often unexpectedly fun: thank you. I'm grateful for the dedication, integrity, and care so many people have brought to this work.
I'm still working out what comes next, though I expect to spend more time closer to home. I remain a proud member of this community, whether contributing from inside the EF or beyond it.
What we've built was handed to us by those who came before, and it is ours to carry forward. I'm grateful to have been one runner among many, and I'll continue to cheer for what comes next. Thank you, all of you.
Hsiao-Wei Wang
Today, the EF is changing shape, concluding a months-long process of reorganization as part of the implementation of the Mandate and the Treasury Management Policy.
We come out of this process with the structure, activities, and people necessary for execution on the critical tasks ahead of us, but also with 54 fewer colleagues, roughly 20% of the EF, many of whom will be finding ways to contribute to Ethereum from outside the EF in the coming weeks.
Find a brief introduction to the new structure, and learn more about how we are supporting the people who are leaving in the full post below:
The predominant term used in the white paper is "transaction." Satoshi's Bitcoin obtained, relayed, and redundantly stored transactions. Where "message" is used in the white paper it is just referring to a sub-protocol used to communicate transaction information between nodes. It's just common technical terminology used in protocol work -- protocols are by definition algorithms that send and receive messages, so "messages" in this computer science context is a generic technical term that can be used for any kind of data sent by any kind of protocol, regardless of formats, restrictions, or intended usage of that data, and that's how it's being used in the white paper. The term "transaction" and the formats and space restrictions in the code much better inform us what the intended use was or is.
That said, it's always been possible to embed non-financial content in blockchain transactions, akin to how it has always been possible to draw scrawls on a dollar bill. However, embedding *legible* non-textual content, and thus most legally risky kinds of content, was quite difficult in Bitcoin during its early years, due to several kinds of enforced limitations, until SegWit and some other "upgrades" made it easier, culminating in the inscriptions hack and core30, which has practically invited legible non-textual content, and thus a far wider variety of content for which node operators can be held legally liable, which, unlike other services for which legal precedents exist, blockchain node operators have no ability to delete without severely degrading or destroying their functionality.
When I gave this speech in October 2022, Bitcoin traded near $20,000, Strategy held 130,000 BTC worth about $2.6 billion, and $MSTR was ~$24 split-adjusted. Weeks later, after Bitcoin fell below $16,000, our debt exceeded the combined value of our BTC and cash reserves by ~$300 million, and $MSTR fell into the $13 range by year-end.
We stayed focused, strengthened the company, and executed our strategy. Since then, Strategy has raised over $60 billion of additional capital and invested it in Bitcoin, adding more than 716,000 BTC. Today, our BTC and USD reserves exceed debt by ~$48 billion. Thank you to everyone who believed, endured, and took the long view.
.@hwwonx has been a steadfast contributor to the Ethereum ecosystem for a decade. I still remember her early days in the Ethereum research community, first outside the Foundation and then inside it, and the thought and care she put into making Ethereum research and consensus work more organized and legible. At the same time, she put a lot of work into building an excellent Ethereum community in Taipei, with people and events that were among my favorites.
Last year she, along with @tkstanczak, voluntarily took on the burden of what is perhaps the most challenging position in the Ethereum Foundation, at one of the most challenging times for Ethereum - and realistically, a challenging time for all of humanity. She handled the task skillfully and gracefully, and has constantly strived to find and insist on outcomes that are right both for the Ethereum protocol and for the human beings that build and maintain it.
I look forward to her next adventures.
https://t.co/yaJsdlvDU4
In only 15 months, Bastet journeyed from its very first commit to the @BlackHatEvents USA 2026 stage.
Connecting LLM with Web3 security, it’s pushing the boundaries of what’s possible in the decentralized world.
Huge thanks to all who have contributed and supported, see you in Las Vegas
#BHUSA
Introducing strawmap, a strawman roadmap by EF Protocol.
Believe in something. Believe in an Ethereum strawmap.
Who is this for?
The document, available at strawmap[.]org, is intended for advanced readers. It is a dense and technical resource primarily for researchers, developers, and participants in Ethereum governance. Visit ethereum[.]org/roadmap for more introductory material. Accessible explainers unpacking the strawmap will follow soon™.
What is the strawmap?
The strawmap is an invitation to view L1 protocol upgrades through a holistic lens. By placing proposals on a single visual it provides a unified perspective on Ethereum L1 ambitions. The time horizon spans years, extending beyond the immediate focus of All Core Devs (ACD) and forkcast[.]org which typically cover only the next couple of forks.
What are some of the highlights?
The strawmap features five simple north stars, presented as black boxes on the right:
→ fast L1: fast UX, via short slots and finality in seconds
→ gigagas L1: 1 gigagas/sec (10K TPS), via zkEVMs and real-time proving
→ teragas L2: 1 gigabyte/sec (10M TPS), via data availability sampling
→ post quantum L1: durable cryptography, via hash-based schemes
→ private L1: first-class privacy, via shielded ETH transfers
What is the origin story?
The strawman roadmap originated as a discussion starter at an EF workshop in Jan 2026, partly motivated by a desire to integrate lean Ethereum with shorter-term initiatives. Upgrade dependencies and fork constraints became particularly effective at surfacing valuable discussion topics. The strawman is now shared publicly in a spirit of proactive transparency and accelerationism.
Why the "strawmap" name?
"Strawmap" is a portmanteau of "strawman" and "roadmap". The strawman qualifier is deliberate for two reasons:
1. It acknowledges the limits of drafting a roadmap in a highly decentralized ecosystem. An "official" roadmap reflecting all Ethereum stakeholders is effectively impossible. Rough consensus is fundamentally an emergent, continuous, and inherent uncertain process.
2. It underscores the document's status as a work-in-progress. Although it originated within the EF Protocol cluster, there are competing views held among its 100 members, not to mention a rich diversity of non-EFer views.
The strawmap is not a prediction. It is an accelerationist coordination tool, sketching one reasonably coherent path among millions of possible outcomes.
What is the strawmap time frame?
The strawmap focuses on forks extending through the end of the decade. It outlines seven forks by 2029 based on a rough cadence of one fork every six months. While grounded in current expectations, these timelines should be treated with healthy skepticism. The current draft assumes human-first development. AI-driven development and formal verification could significantly compress schedules.
What do the letters on top represent?
The strawmap is organized as a timeline, with forks progressing from left to right. Consensus layer forks follow a star-based naming scheme with incrementing first letters: Altair, Bellatrix, Capella, Deneb, Electra, Fulu, etc. Upcoming forks such as Glamsterdam and Hegotá have finalized names. Other forks, like I* and J*, have placeholder names (with I* pronounced "I star").
What do the colors and arrows represent?
Upgrades are grouped into three color-coded horizontal layers: consensus (CL), data (DL), execution (EL). Dark boxes denote headliners (see below), grey boxes indicate offchain upgrades, and black boxes represent north stars. An explanatory legend appears at the bottom.
Within each layer, upgrades are further organized by theme and sub-theme. Arrows signal hard technical dependencies or natural upgrade progressions. Underlined text in boxes links to relevant EIPs and write-ups.
What are headliners?
Headliners are particularly prominent and ambitious upgrades. To maintain a fast fork cadence, the modern ACD process limits itself to one consensus and one execution headliner per fork. For example, in Glamsterdam, these headliners are ePBS and BALs, respectively.
(L* is an exceptional fork, displaying two headliners tied to the bigger lean consensus fork. Lean consensus landing in L* would be a fateful coincidence.)
Will the strawmap evolve?
Yes, the strawmap is a living and malleable document. It will evolve alongside community feedback, R&D advancements, and governance. Expect at least quarterly updates, with the latest revision date noted on the document.
Can I share feedback?
Yes, feedback is actively encouraged. The EF Protocol strawmap is maintained by the EF Architecture team: @adietrichs, @barnabemonnot, @fradamt, @drakefjustin. Each has open DMs and can be reached at first.name@ethereum[.]org. General inquiries can be sent to strawmap@ethereum[.]org.
Today is a monumentous day for quantum computing and cryptography. Two breakthrough papers just landed (links in next tweet). Both papers improve Shor's algorithm, infamous for cracking RSA and elliptic curve cryptography. The two results compound, optimising separate layers of the quantum stack. The results are shocking. I expect a narrative shift and a further R&D boost toward post-quantum cryptography.
The first paper is by Google Quantum AI. They tackle the (logical) Shor algorithm, tailoring it to crack Bitcoin and Ethereum signatures. The algorithm runs on ~1K logical qubits for the 256-bit elliptic curve secp256k1. Due to the low circuit depth, a fast superconducting computer would recover private keys in minutes. I'm grateful to have joined as a late paper co-author, in large part for the chance to interact with experts and the alpha gleaned from internal discussions.
The second paper is by a stealthy startup called Oratomic, with ex-Google and prominent Caltech faculty. Their starting point is Google's improvements to the logical quantum circuit. They then apply improvements at the physical layer, with tricks specific to neutral atom quantum computers. The result estimates that 26,000 atomic qubits are sufficient to break 256-bit elliptic curve signatures. This would be roughly a 40x improvement in physical qubit count over previous state-of-the-art. On the flip side, a single Shor run would take ~10 days due to the relatively slow speed of neutral atoms.
Below are my key takeaways. As a disclaimer, I am not a quantum expert. Time is needed for the results to be properly vetted. Based on my interactions with the team, I have faith the Google Quantum AI results are conservative. The Oratomic paper is much harder for me to assess, especially because of the use of more exotic qLDPC codes. I will take it with a grain of salt until the dust settles.
→ q-day: My confidence in q-day by 2032 has shot up significantly. IMO there's at least a 10% chance that by 2032 a quantum computer recovers a secp256k1 ECDSA private key from an exposed public key. While a cryptographically-relevant quantum computer (CRQC) before 2030 still feels unlikely, now is undoubtedly the time to start preparing.
→ censorship: The Google paper uses a zero-knowledge (ZK) proof to demonstrate the algorithm's existence without leaking actual optimisations. From now on, assume state-of-the-art algorithms will be censored. There may be self-censorship for moral or commercial reasons, or because of government pressure. A blackout in academic publications would be a tell-tale sign.
→ cracking time: A superconducting quantum computer, the type Google is building, could crack keys in minutes. This is because the optimised quantum circuit is just 100M Toffoli gates, which is surprisingly shallow. (Toffoli gates are hard because they require production of so-called "magic states".) Toffoli gates would consume ~10 microseconds on a superconducting platform, totalling ~1,000 sec of Shor runtime.
→ latency optimisations: Two latency optimisations bring key cracking time to single-digit minutes. The first parallelises computation across quantum devices. The second involves feeding the pubkey to the quantum computer mid-flight, after a generic setup phase.
→ fast- and slow-clock: At first approximation there are two families of quantum computers. The fast-clock flavour, which includes superconducting and photonic architectures, runs at roughly 100 kHz. The slow-clock flavour, which includes trapped ion and neutral atom architectures, runs roughly 1,000x slower (~100 Hz, or ~1 week to crack a single key).
→ qubit count: The size-optimised variant of the algorithm runs on 1,200 logical qubits. On a superconducting computer with surface code error correction that's roughly 500K physical qubits, a 400:1 physical-to-logical ratio. The surface code is conservative, assuming only four-way nearest-neighbour grid connectivity. It was demonstrated last year by Google on a real quantum computer.
→ future gains: Low-hanging fruit is still being picked, with at least one of the Google optimisations resulting from a surprisingly simple observation. Interestingly, AI was not (yet!) tasked to find optimisations. This was also the first time authors such as Craig Gidney attacked elliptic curves (as opposed to RSA). Shor logical qubit count could plausibly go under 1K soonish.
→ error correction: The physical-to-logical ratio for superconducting computers could go under 100:1. For superconducting computers that would be mean ~100K physical qubits for a CRQC, two orders of magnitude away from state of the art. Neutral atoms quantum computers are amenable to error correcting codes other than the surface code. While much slower to run, they can bring down the physical to logical qubit ratio closer to 10:1.
→ Bitcoin PoW: Commercially-viable Bitcoin PoW via Grover's algorithm is not happening any time soon. We're talking decades, possibly centuries away. This observation should help focus the discussion on ECDSA and Schnorr. (Side note: as unofficial Bitcoin security researcher, I still believe Bitcoin PoW is cooked due to the dwindling security budget.)
→ team quality: The folks at Google Quantum AI are the real deal. Craig Gidney (@CraigGidney) is arguably the world's top quantum circuit optimisooor. Just last year he squeezed 10x out of Shor for RSA, bringing the physical qubit count down from 10M to 1M. Special thanks to the Google team for patiently answering all my newb questions with detailed, fact-based answers. I was expecting some hype, but found none.
Today a crazy quantum story just got wilder.
On March 31, the Google Quantum AI team published a landmark result on Shor's algorithm for elliptic curve cryptography. Technically, the paper was a bombshell: a dramatic 10x improvement over the state-of-the-art. As a stunt and wakeup call to the blockchain space, those optimisations were illustrated on secp256k1, the elliptic curve underlying Bitcoin and Ethereum signatures.
But perhaps the most striking part of the paper was sociological, not technical. Instead of following standard academic process, the optimisations were kept secret, hidden behind a zero-knowledge (ZK) proof. Google's accompanying blog post mentions they "engaged with the U.S. government". The ZK proof demonstrates the existence of algorithmic improvements without leaking details. Academic censorship with ZK, a historic first!
As a co-author of the Google paper I witnessed some of the context surrounding this censorship. To be honest, multiple aspects of that context don't sit well with me. As much as I believe the general public ought to know more, I am limited in my ability to whistleblow. Though let me be clear about one thing: the Google team's professionalism has been absolutely exemplary, and they deserve nothing but praise.
Censorship has a way of backfiring. The Streisand effect, where an attempt to bury something only draws more attention to it, is exactly what's unfolding today. First, Google's key optimisation has been rediscovered by the French. And in a thrilling turn of events, a collaborative Shor-at-home challenge just launched. The initiative, available at ecdsa[.]fail, breached a new Shor world record in a matter of hours.
Let's start with the rediscovery. Just two months after Google's paper, French quantum expert André Schrottenloher cracks the main secret optimisation. His paper, titled "Optimized Point Addition Circuits for Elliptic Curve Discrete Logarithms", landed on the arXiv today. Big congrats to André, who beat several other nerdsnipped experts to it. In a blog post also published today, Craig Gidney, the world expert on Shor optimisations, revealed that he'd been sitting on this very optimisation for a whole year under censorship pressure.
Interestingly, André missed a handful of minor optimisations, both from Google's original publication and from improvements found since. It's plausible there's still plenty of juice left to squeeze out of Shor, and this is exactly what the ecdsa[.]fail challenge is about. The verifier program developed for the ZK proof does double duty, automatically filtering for valid submissions. Dozens of compounding small and micro improvements are rolling in. As of the time of writing there's an 8.4% improvement to Google's circuit, as measured by the product of logical qubit count and Toffoli gate count. Nice!
The nerdsnipping ran deeper than anyone expected. Over the last few weeks it became clear it extended well beyond André and other quantum experts. Behind the scenes, a small army of amateurs quietly got to work. Inspired by Karpathy-style autoresearch, they turned AI on Shor. Ironically, the verifier program for the ZK proof makes an ideal reward function for AIs. The barrier to entry for this modern style of research is refreshingly low, with several non-experts, even a teenager, finding nice optimisations. Get in touch if you'd like to join a Telegram group with fellow autoresearchers :)
Part 2: neutral atoms and qday
The story doesn't end with Google. On the same day Google went public, a stealthy startup called Oratomic published its own Shor paper in a coordinated release. It made a splash, ultimately becoming the most upvoted paper on scirate[.]com, a website ranking arXiv papers.
Oratomic's claim was wild. By building on Google's logical optimisations and applying custom physical optimisations for neutral atoms, they claimed just 10K physical qubits were sufficient to run Shor's algorithm on secp256k1. That number is mind-bogglingly low.
Knowing essentially nothing about neutral atoms when Oratomic's paper landed, I was intrigued and decided to learn more about the tech. I fell straight down the rabbit hole and spent a couple hundred hours on the topic. I got a little obsessed and watched every YouTube video I could find and spoke to a bunch of experts.
My conclusion? The tech is real, very real. Even Google recently decided to start a neutral atom lab, a notable pivot from their sole focus on superconducting qubits. If you care about qday, i.e. the day a quantum computer will break the first piece of cryptography in production, neutral atoms demand your attention. I shared some of my learnings on Shor and neutral atoms in a 30min talk at the ZKProof cryptography conference. You can find it on YouTube by searching "zkproof neutral atom".
Here's an interesting observation about this duo of breakthrough papers: neither Google nor Oratomic say a word about what their results mean for qday. No timelines. Zero. Nada. That is especially baffling given that the whole point of whitehat quantum cryptanalysis is to inform qday estimations and help the general public make good decisions.
So let me attempt to partially fill the silence, similarly to what Scott Aaronson did in his April 29 post. Given everything I know, including scary non-public information, I now put the odds of qday by 2032 at 50%. 10% by 2030.
Anecdotally, the US government has its own date: 2035. Originating at the NSA and later adopted by NIST, it's when branches of the US government will be disallowed from using quantum-vulnerable cryptography. In plain language: with hindsight, that date is a joke and should be discounted entirely. I don't see how NIST avoids being forced to pull it forward by years.
Part 3: post-quantum cryptography
There are good reasons to sound the alarm today, but please do not panic. Rushing carelessly towards immature post-quantum cryptography is a recipe for disaster. IMO a good target date for migration is 2029, roughly 3.5 years out. 2029 happens to be the date selected by Google, Cloudflare, and the Ethereum Foundation.
These days most of my time goes to safely migrating Ethereum towards post-quantum cryptography as part of the broader lean Ethereum effort. There's a lot to do. We need to rip out and replace BLS signatures at the consensus layer, KZG commitments at the data layer, and ECDSA signatures at the execution layer.
The plan to get there is compelling, and is based on hash-based cryptography. Within the Ethereum Foundation we've developed a Swiss army knife called leanVM (github[.]com/leanEthereum/leanVM) powered by the magic of hash-based SNARKs. Thanks to truly exceptional work by Emile, Thomas, and others, its performance is derisked. Regarding security, leanVM is a jewel, a minimal zkVM crafted for end-to-end formal verification and maximum security.
Want to help? There are two $1M initiatives. First, the Proximity Prize (proximityprize[.]org). Solve a long-standing mathematical conjecture in coding theory, improve hash-based SNARKs, and go home a millionaire. Second, the Poseidon Initiative (poseidon-initiative[.]info), offers $1M for breaking Poseidon, the SNARK-friendly hash function.
Got an idea for Web3 security but need AI credits?
🔥DeFiHackLabs AI Credits Initiative is now open.
We’re supporting builders and white hats using AI to create security public goods.
Apply 👇
Introducing: Ethereum’s top security experts
TheDAO’s ETHSecurity Badges are a new onchain primitive recognizing the people securing Ethereum.
40 have been selected. 160 open spots are left.
Are you one of Ethereum’s top 200? 👇