Most people read a cryptography explainer to understand the math. I read it to find the copy-paste.
The Defiant published a walkthrough of ECDSA this week built on what the author openly calls a "Toy ECDSA Example" — small numbers, a deliberately insecure curve, hand-computable arithmetic. The prose is careful. The curve is flagged. And that flag is precisely the problem: a disclaimer lives in a sentence, while the code lives in a repository, and only one of those gets copied.
I have spent years reading other people's signature code. Not the whitepapers — the actual verify functions, the nonce generation, the ecrecover calls. The math in these tutorials is almost always correct. The risk sits one layer below the math, in the gap between "this demonstrates the concept" and "this compiles."
ECDSA — Elliptic Curve Digital Signature Algorithm — is the scheme underneath Bitcoin's secp256k1 curve and every Ethereum transaction ever broadcast. Private key d, generator point G, public key Q = dG. The security claim is brutal in its simplicity: given Q and G, recovering d requires solving the elliptic curve discrete logarithm problem, which on a 256-bit curve is not a computation anyone can run.
The property that matters for blockchains is asymmetry. Verification consumes the message and the public key. It never touches the private key. That is the entire trust model of a self-custodial wallet compressed into one sentence — a node can confirm you authorized a transfer without ever holding the thing that authorizes it.
Which is why the demo curve matters. It's a defensible pedagogical choice. It's also the exact place where the security assumption inverts without anyone noticing.
In a drawdown, security review is the first line item cut. Teams paying for two audits in 2021 are paying for none in 2026, and the signature layer is where that shows up last and worst — it does not degrade gradually, it fails once.
Walk the four steps: key generation, signing, verification, and the nonce.
Signing picks a random k, computes R = kG, r = x(R) mod n, and s = k⁻¹(z + r·d) mod n. Verification computes u₁ = z·s⁻¹ and u₂ = r·s⁻¹, then checks that x(u₁G + u₂Q) = r. Substitute and d cancels out through Q = dG. Verification never needs the secret. Genuinely elegant.
Two things break it.
First, the curve. On a toy curve — an 8-bit field, say — the discrete log falls to brute force in milliseconds. Any signature published from that curve hands you the private key directly. The author says so. But a reader who ports those parameters to test a script has built a key generator, not a signer.
Second, and this is where real money has actually been lost: the nonce. If k repeats across two signatures, r repeats too, because r = x(kG). Then:
k = (z₁ − z₂) · (s₁ − s₂)⁻¹ mod n d = (s₁·k − z₁) · r⁻¹ mod n
Two signatures, one algebra step, private key gone. No curve attack required. This is not theoretical. Sony's PS3 was broken this way in 2010, with a static k across firmware signatures. Android's SecureRandom bug in 2013 reused k across Bitcoin wallets. Blockchain.info shipped a faulty RNG in 2014 and double-spent its own outputs. And the bias need not be total: the "Biased Nonce Sense" work in 2019 demonstrated lattice attacks recovering keys from nonces leaking only a few bits.
My own audit trail keeps returning to the same place. In 2018 I hand-audited more than fifty ICO contracts, most of them reached by scraping raw mainnet transactions through Python scripts I wrote because no clean dataset existed. The reentrancy bugs got the headlines. The signature bugs got the funds. Two patterns recurred: ecrecover returning address(0) on a malformed signature with no zero-address check downstream, and missing low-s enforcement, which leaves ECDSA's built-in malleability open — for any valid (r, s), the pair (r, n−s) is also valid. Ethereum closed that at the protocol level in Homestead. Contracts verifying signatures off-chain-style routinely forget it.
The toy tutorial addresses neither. It doesn't have to. The code that follows it will.
Why does ECDSA persist when Schnorr and BLS are cleaner? Because the address space is the moat. secp256k1 keys, derivation paths, and hardware secure elements are all ECDSA-shaped. BLS aggregation is a validator-set tool, not a retail wallet tool. The algorithm is legacy in the best and worst senses simultaneously — and legacy code is what gets copied.
The comfortable assumption is that education reduces risk. My data points the other way: sample code propagates faster than warnings.
I want to be precise about causation. A demo curve does not drain wallets. What drains wallets is the distance between a prose caveat and a runnable artifact — the reader takes the artifact and leaves the caveat. The disclaimer is in the paragraph. The k = 3 is in the function.
There's a second inversion worth sitting with. ECDSA explainers get read hardest when prices are lowest. Nobody studies discrete logarithms during a mania; they study them when they're building, auditing, or working out whether the thing holding their remaining balance is actually sound. Follow the gas, not the hype — and right now the gas is being spent by developers, not tourists. The copy-paste window is widest precisely when the market is quiet.
Whales don't lose keys to Shor's algorithm; they lose them to a reused nonce. The near-term threat surface is implementation, not mathematics.
Watch one signal this month: whether wallet libraries have moved to deterministic nonces — RFC 6979, or the EdDSA design that removes k from the developer's hands entirely. If this wave of explainers produces forks of demo code rather than forks of libsecp256k1, we will see failures in the same place we always do. Code is law, but bugs are fatal.