Recorded

Ethereum Classic Community Call #54

Prague

Friday, June 12, 2026 at 15:00 UTC (Saturday, June 13 in Asia)
UTC 15:00
ESTNYC
10:00
GMTLondon
15:00
CETBerlin
16:00
GSTDubai
19:00
ISTNew Delhi
20:30
ICTBangkok
22:00
CSTBeijing
23:00
JSTTokyo
00:00+1 SAT
AEDTSydney
02:00+1 SAT

Time change for this call. Our usual 0200 UTC slot has been shifted to 1500 UTC for this episode due to travel. No green room this time. Regular timing will resume on the call after.

Preamble

Hello, and Welcome!

This community call is an open voice chat discussion about Ethereum Classic. Everyone is welcome.

The call will be published on YouTube. We kindly ask that discussion stays focused on ideas rather than individuals. Let’s keep it classy.

Find past episodes, transcripts, subscribe to calendar, and more at https://cc.ethereumclassic.org.

Today’s Agenda

  • New Website
  • Video Pipeline
  • Clients
  • eth/69 on a Proof-of-Work Network
  • Protocol Technical Discussion: Where Should It Happen?

Introductions

Quick round of introductions for everyone on the call, and if there’s anything you want to talk about.

Agenda

New Website

Continuing from call 53. Quick takes on:

  • Progress since last call?
  • Design competition: brief, judges, timeline?
  • Wiki-style content with multiple viewpoints, or single voice?
  • Who owns content, and how do contributions land?
  • How should AI be used?
  • AI-facing surface: assistant, MCP server, llms.txt?
  • Link-checking bot for the site, ECIPs, and docs?
  • Open contributor slots and rewards?

Video Pipeline

Zoom recordings going straight to YouTube. Production quality could be better. Quick takes on:

  • Worth setting up a proper post-production pipeline?
  • Anyone want to help with graphics or editing? Reach out.

Clients

Quick takes on:

  • Why does client diversity (and the trust that comes with it) matter for ETC?
  • Classic Geth: state of play, roadmap?
  • Nethermind: status, ETC integration?

eth/69 on a Proof-of-Work Network

Diego’s recent post: eth/69 on a Proof-of-Work Network.

When two Ethereum nodes meet, they swap a quick “hello” that says where each one is in the chain. eth/69 is a new version of that hello. It drops “total difficulty” (a running tally of all the proof-of-work mined into the chain) and uses block number instead. On Ethereum mainnet that’s fine, because total difficulty stopped changing when the network switched to proof-of-stake.

On a proof-of-work network like ETC, total difficulty is exactly how nodes pick the canonical chain: heaviest wins, not longest. If the handshake doesn’t carry it, an attacker can mine a long chain of cheap, low-difficulty blocks that looks ahead on block count but is lighter than the honest chain, a vector that was closed in 2015. Diego argues against adopting eth/69 wholesale and proposes an ETC-native etc/1 that keeps total difficulty in the wire protocol while pulling in the genuinely useful pieces of eth/69 (like dropping redundant receipt bloom filters).

Protocol Technical Discussion: Where Should It Happen?

A recent comment from the community:

depth first vs breadth first tre search during healing of snap sync impacts everyone too. or eth/69+ behavior during handshake. or dns vs discovery for peer discovery. on somethings i do not care about other people’s opinion, on some things i do. The community call proved not to be the place to have conversations

So, let’s talk about:

  • Depth-first vs breadth-first tree search during snap sync healing
  • eth/69+ behaviour during handshake
  • DNS vs discovery for peer discovery