Have you ever watched a network move in one direction for a day, then quietly walk the whole thing back before most people even noticed? That is roughly what happened on Ethereum Classic this week. A handful of mining pool nodes jumped onto a new Core Geth build labeled v1.13.0, got told it was a security migration, and then returned to the client they had been running all along. No blocks vanished. No wallets emptied. Still, the episode left a sour taste, because the fight was never only about a version number. It was about who gets to speak for a chain that refuses to name an official maintainer.
What Actually Happened On Ethereum Classic This Week
I keep coming back to the timing. The disputed build landed on September 14. Promotion followed the next morning. By midday on September 15, four nodes tied to a large mining pool were already on v1.13.0. By late evening those same machines were back on Argos v1.12.23. If you blink, it looks like a non-event. Look closer and it looks like a governance stress test dressed up as a patch note.
Classix, which tracks this corner of the stack, framed the release as rogue rather than merely unofficial. That word is loaded, and I do not use it lightly. The claim rests on a simple split. One repository has maintained Core Geth in public since 2020. Another fork, created later, pushed a large batch of commits, tagged a stable release, and then circulated upgrade language through social accounts, listing pages, and emails that looked institutional enough to move operators.
In my experience, miners do not upgrade for poetry. They upgrade when someone they trust says the old binary is unsafe. That is the lever that worked, at least for a few hours.
A Fast Release With Almost No Outside Review
The most striking detail is the pace. Ninety-six commits landed on the fork’s main branch in about fifty-six hours. That is more than thirteen thousand lines added and nearly four thousand removed. There were no pull requests sitting in the open for outsiders to pick apart. Release candidates stacked up from September 12 through the fourteenth, then the tag flipped to stable in the afternoon UTC window.
Speed is not automatically sin. Emergency patches exist for a reason. The problem is the packaging. Operators were told every v1.12.x node should move, and that the older series still carried unpatched holes, including one supposedly used against bootnodes months earlier. If you are running hash power for other people’s payouts, that sentence is designed to make you act first and read the diff later.
A security update that cannot survive a second look is not an update. It is a coordination event.
Perhaps the most interesting aspect is how ordinary the distribution channels looked. A network account posted the migration request. Market pages echoed similar language. Pool operators received mail from a domain that sounds like the project itself. None of that proves malice. It does prove that branding still moves machines on a chain that insists it has no official brand.
How Far The Disputed Client Actually Spread
Node counts matter more than slogans. Four pool nodes were on v1.13.0 just after noon UTC on September 15. By 23:35 they were gone from that version. Other named pools stayed on the 1.12 line. Public explorers still showed a thin tail of individual machines on the new build the next morning, including addresses that matched bootnodes hardcoded into the client.
That last bit is awkward. If the remaining peers are the discovery endpoints baked into the binary, you are not looking at organic adoption. You are looking at the client talking to its own address book.
- Pool nodes moved on, then reversed the same day.
- Most listed pools never left the 1.12 series.
- A small set of public nodes stayed on v1.13.0.
- Several of those leftover peers matched new bootnode IPs.
Classix called the incident high severity and low impact. I think that pairing is fair. Consensus behavior changed in the binary. The chain did not visibly break. No reorganization showed up. Funds stayed put. Services kept running. The scare was about what could have happened if more hash power had sat on a client that other implementations do not follow.
Why The Security Story Did Not Hold Up
Upgrade notes listed a cluster of vulnerabilities and treated them as a single reason to abandon Argos. A later review of those items told a different story. Five issues had already been closed in maintained Core Geth releases between March and August. Two others did not sit on Ethereum Classic’s peer-to-peer path in a way that justified a forced migration.
One cited flaw involved KZG proof checks. That family of proofs is tied to blob traffic from Ethereum’s later upgrades. Ethereum Classic never switched that machinery on. Another item lived in GraphQL query depth, which is not consensus and is not even reachable unless an operator turns GraphQL on by hand. Those are real classes of bugs in the wider Geth universe. They are weak excuses for telling every ETC miner to rotate keys tonight.
Maintainer review of the leftover delta found no exploitable hole in Argos that v1.13.0 uniquely closed. That sentence should have been the end of the marketing. It was not.
| Claim In v1.13.0 Notes | Maintained-Client View | Operator Risk If Ignored |
| All 1.12.x builds are unsafe | Key issues already patched in later 1.12 releases | Unnecessary rush upgrade |
| Bootnode attack still open | Addressed earlier in the maintained line | False urgency |
| KZG verification gap | Not applicable to current ETC rules | Confused threat model |
| GraphQL depth issue | Optional interface, not P2P consensus | Low unless GraphQL is enabled |
| Rotate P2P keys immediately | Underlying issue already fixed months earlier | Forced rediscovery through new infra |
I’ve found that the fastest way to lose an operator’s trust is to recycle old CVEs as if they were still on fire. People who run pools keep changelogs. They notice when March’s fix is sold again in September.
MESS Came Back, And That Is Not A Small Toggle
Security language grabbed the headlines. The consensus change is the part that still bothers me. Modified Exponential Subjective Scoring, usually shortened to MESS, was switched back on by deleting the configuration that had turned it off at block 19,250,000. Ethereum Classic added MESS years ago as a shield against deep reorganizations. It later stepped away from that behavior after the original chain’s proof-of-work era ended elsewhere.
Here is the practical problem. Besu, Nethermind, and Getc do not implement MESS the same way, if they implement it at all. If only Core Geth nodes start scoring competing histories with that extra rule, you do not have one network with a preference. You have two ideas of which chain is canonical, waiting for enough hash power to make the disagreement expensive.
Ethereum Classic already knows what a majority attack looks like. It ate three of them in August 2020, including reorganizations that stretched across thousands of blocks. Anyone who lived through that week does not need a lecture on why client-split scoring is a bad hobby.
Protection that only one client understands is not network protection. It is a private rulebook.
Would a short burst of MESS-enabled hash have reorganized anything last week? There is no evidence it did. That is not the same as saying the switch was harmless in principle. Consensus knobs belong in a public proposal, not in a weekend commit storm.
New Bootnodes, New Keys, New Gravity
The other quiet change sat in discovery. A commit replaced the DNS tree signing key that contributors on the long-running repository had used since 2020. Three new bootnode IPs were hardcoded. Older discovery trees disappeared from the client’s map. Replacement domains sat behind a single account at the same edge provider. The repository even noted that trouble on that one account could wipe all three paths at once.
Operators following the migration guide were told to rotate P2P keys, citing a vulnerability that the maintained line had already closed. Rotating a key is not cosmetic. It changes a node’s network identity. The machine then has to find friends again through whatever discovery system the new binary prefers. If that system points at fresh bootnodes, you have just shepherded peers onto someone else’s map.
Who holds the new signing key? The public write-up says operators were not told. I will say this as plainly as I can. If you ask people to rebuild their peer graph, you owe them a name, a process, and a fallback. “Trust the binary” is not a process.
- Compare the claimed CVEs against the maintained 1.12 changelog before touching a binary.
- Check whether MESS is enabled and whether other clients on the network share that rule.
- Inspect bootnode lists and DNS tree keys instead of accepting the default address book.
- If a key was already rotated, restore the previous identity where that is still safe.
- Keep at least one non-Core-Geth client in the local mix so a single repo cannot steer the farm.
Why A Chain Without Official Maintainers Is Easy To Nudge
Ethereum Classic’s public disclaimer is almost proud of the vacuum. No official developer. No official site. No official client. In theory that is decentralization. In practice it creates a costume rack. Any repository that looks close enough, any handle that sounds close enough, any domain that reads like the project name can borrow authority for a news cycle.
The maintained etclabscore line does not claim a crown. It claims a six-year public trail, regular releases, and the simple fact that a lot of live nodes already run it. That is a messy kind of legitimacy. It is also the kind miners actually use when payouts are on the line.
Classix asked administrators of the organization that hosts the disputed repository to lock things down. Require proposals before new repos appear. Protect default branches. Name maintainers for anything that ships binaries. Archive or warn on the fork so newcomers do not treat it as the blessed tree. Those are boring requests. Boring is what you want after a week like this.
I do not think every fast fork is a heist. People fork software because they are angry, ambitious, or convinced the current maintainers are asleep. Fine. Ship the argument in the open. Do not wrap a consensus change and a discovery rewrite inside a “you are unsafe” banner and email the pools.
Client Diversity Is Not A Slogan On This Network
If most hash power sits on one implementation, a disputed tag becomes a network event. That is true on every chain. It is sharper on a proof-of-work network that has already been reorganized in public. Running Nethermind, Besu, or Getc beside Core Geth is not fashion. It is a circuit breaker.
Other ecosystems learned this the expensive way while testing large upgrades across execution and consensus clients. Bugs showed up because someone bothered to run more than one binary against the same rules. Ethereum Classic does not need to copy another chain’s roadmap. It does need to stop treating “everyone is on Geth” as a comfort blanket.
Operator checklist after a scare: Confirm the binary source, not the marketing name Diff consensus flags before restarting Keep an alternate client synced Treat key rotation as a network move, not a checkbox Write down who controls discovery infrastructure
There is a temptation to shrug because impact was low. I get it. Markets barely twitched. Explorers looked dull. That shrug is how the next attempt learns that social proof is cheaper than a real exploit.
What Operators Should Do With Machines That Already Moved
The advice from the incident write-up is blunt. Stay off ethereumclassic/core-geth v1.13.0. Keep Argos v1.12.23 if that is the maintained line you already trust. If you already migrated, move back. If you rotated the node key because the guide told you to, restore the previous key when that still matches your peering plan. Then look at the MESS setting with your own eyes instead of assuming the default is harmless.
None of that requires a press conference. It requires a maintenance window and a habit of reading more than the first paragraph of a release mail.
Should GitHub organization admins treat this as a one-off? I would not. Repository creation, protected branches, and review gates are the unglamorous half of chain security. The glamorous half is cryptography. The unglamorous half is stopping a weekend tag from impersonating a safety bulletin.
A Short History Lesson Miners Cannot Afford To Forget
Proof-of-work networks settle arguments with hash. They also settle them with software defaults. When enough machines share a scoring rule the others do not, history can split even if everybody is “honest” in the narrow sense. That is why old ETC reorganizations still get cited whenever someone touches consensus-adjacent code.
I am not reciting that history to scare readers off the asset. I am reciting it because the people who mine it already paid that tuition. Re-enabling a defense mechanism in one client after the rest of the stack moved on is how you spend that tuition twice.
Think of MESS like a house rule in a card game. If three tables use the printed deck and one table uses a house rule that changes which stack wins, you do not have four tables in the same tournament. You have a side game that can steal the pot when the room gets loud.
The Human Layer Behind Node Software
We talk about clients as if they were weather. They are not. They are groups of people with commit access, release habits, and different ideas about what “done” looks like. Some groups review in public until the comments get ugly. Some groups push to main because waiting feels like negligence. Both temperaments exist in open source. Only one of them should be allowed to redefine how a live chain picks heads without a wider argument.
There is also a communications layer that software people still underestimate. An account with the project’s initials, a domain that matches the ticker, a listing site that copies the post. That stack can outrun a carefully written security advisory from the quieter repository. Miners are busy. They scan subject lines. Design those subject lines with care or someone else will design them for you.
In my view, the lasting failure here is not that a fork exists. Forks are the point of the license. The failure is the costume. Call a build experimental and people will test it on a spare box. Call it the security release and they will put it on the payout machines.
What This Episode Says About “Code Is Law” Slogans
Ethereum Classic grew up around a stubborn story: the chain that refused to rewrite history after a crisis on the original network. That story still attracts a certain kind of holder. It does not automatically produce clean release engineering. A community can be philosophically hard and operationally sloppy at the same time. Last week was sloppy.
Code is not law if the binary on the mining rack arrived through an email nobody audited. Code is not law if discovery now points at three domains that share one bill. Code is not law if one implementation quietly scores forks differently. Law, in this setting, is the boring agreement among clients about which block is next.
The chain that refuses official leaders still needs official habits: review, disclosure, and a shared definition of consensus.
Is that a contradiction? A little. Adult networks live inside contradictions. They just try not to discover them during a midweek hash-rate wobble.
Reading The Incident Without Turning It Into Fan Fiction
It is easy to write a villain into this. Resist that urge unless more facts show up. A rushed fork can be incompetence, ego, or something colder. From the public record we can say the review process was missing, the security rationale was overstated, consensus and discovery changed together, some pool nodes followed the call, and those nodes reversed after the warning circulated. That is already enough to change operator behavior. It is not enough to prosecute a novel in public.
The interim report itself leaves room for updates if leftover nodes get identified, if organization admins answer, or if something material appears. That posture is grown-up. More incident notes should sound like that and less like victory laps.
Practical Habits For The Next Email That Says “Upgrade Now”
Assume the next urgent client mail will look professional. Assume it will cite real CVE identifiers. Assume someone you respect will share it before breakfast. Then slow down anyway.
- Match the repository URL, not the project adjective in the subject line.
- Search the maintained changelog for the same identifiers.
- Ask whether the patch changes scoring, difficulty, or peer discovery.
- Stage the binary on a non-paying node first.
- Watch peer counts after any key rotation.
Those steps sound fussy until you remember how short the window was. Hours, not weeks. The entire migration-and-reversal cycle fit inside a workday. Fussy is how you survive workdays like that.
I would also keep a written map of which pools run which clients. Gossip is not a monitoring stack. If four nodes can flip and unflip without a public dashboard screaming, the industry is still flying with too few instruments.
Where The Story Goes From Here
The remaining v1.13.0 peers are the loose thread. If they are mostly the new bootnodes talking to themselves, the episode is already over in operational terms. If a quiet pocket of hash stays on the disputed scoring rules, the conversation changes. Watch for that, not for another round of branding.
Repository controls would help. So would a habit of labeling unofficial trees in the places miners actually look. So would client diversity that is real rather than mentioned in conference talks. None of those fixes trend. All of them cost less than another reorganization postmortem.
Will holders care if the chain keeps producing blocks on schedule? Most will not. That is normal. Infrastructure stories only become price stories after something breaks. The job this week was to notice the near miss without inventing a collapse.
I’ve covered enough of these scares to know the pattern. First the urgent post. Then the rollback. Then the shrug. Then, months later, someone repeats the move with better timing. Break the pattern now, while the damage is still measured in embarrassment rather than orphaned blocks.
A Closing Note For People Who Still Mine This Chain
You do not owe loyalty to a GitHub org because it borrowed the ticker. You owe your pool members a boring uptime record. Argos staying in place after a noisy week is not conservatism for its own sake. It is a vote for the repository that has been shipping in public long enough to leave fingerprints.
If another binary deserves that seat, it can earn it the long way: reviews, release candidates that sit in the open, and a rationale that survives contact with people who remember 2020. Until then, treat “migrate immediately” as a reason to open the diff, not a reason to restart the rack.
The machines already voted once this week. They voted with a rollback. That is the most honest signal in the whole affair. Listen to it before the next tag tries to speak louder than the people who actually keep the chain alive.
