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.

Key Points Discussed

• GitHub governance: w1g0 raised the unclear, centralized ownership and permissions across ETC’s repos; Istora walked through the website-maintainer team and its two-approval quorum, and the Olympia/no-Olympia schism that has effectively deadlocked merges
• ETC Co-op winding down: with the Cooperative stepping back and another party stepping up, the maintainer structure and neutrality are in flux; both sides of the Olympia debate struggle to get PRs approved
• eth/69 on a PoW network: Diego explained why eth/69 is a poor fit — it drops total difficulty from the status message, which ETC needs for heaviest-chain selection and 51%-attack defense
• Recommended path: rather than chase the eth/6x line, define an ETC-native protocol (the ECIP-1120 / “etc1” framing) that keeps total difficulty and cherry-picks the useful pieces; clients can coexist behind a feature flag (as Besu does) without a hard fork
• Attack vector: adopting eth/69 naively risks a chain split on network partition (a node following the longest rather than heaviest chain); snap sync is largely orthogonal and safe
• Where protocol decisions belong: Cody’s point that the community call is not the forum for deciding technical changes; revive a developer call, and keep the community call for direction and education
• Website redesign: migrate off Gatsby and visualize how the protocol actually works — a 3Blue1Brown-style explainer and a MESS visualization to make (de)centralization legible
• AI in development: split views — w1g0 cautious, weder arguing it is now table stakes — converging on AI being fine for ideation and tooling with a human in the loop, while core-client code needs human review (Diego: AI-generated client PRs were mostly garbage)
• Show notes: Diego’s article, eth/69 on a Proof-of-Work Network

Full AI Summary and Transcript ↓

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

AI Summary

Website Maintainers and the GitHub Deadlock

w1g0 opened the rounds by raising the centralized, opaque governance of ETC’s GitHub repositories.

• Details
  • w1g0: Each repo has its own purpose and governance, but it is unclear who maintains which; permissions should be transparent, and more signers added so progress does not stagnate
  • Istora: On the website repo he is an administrator who sets the maintainer team; the merge quorum is two approvals, historically tied to the number of active contributors
  • Istora: Most of the listed maintainers are inactive (named Kimmy, Cody, Keith Hall Barnett, Christopher Mercer); above them, Cody, Elaine and Mikey O are GitHub org admins who can move people between teams and reassign repo access
  • w1g0: On the Olympia debate, PRs sit unapproved because two neutral signatures are hard to get; even non-Olympia changes stall
  • weder: Questioned whether a genuinely neutral participant is even possible in such a schism
  • Istora: Is intentionally not approving Olympia-adjacent changes to avoid taking sides; with the ETC Co-op winding down and another party stepping up, the maintainer structure is in flux, and a returning long-term contributor like w1g0 could help as a neutral party
• Conclusion
  • Repo ownership and permissions need a clear, published structure (an org diagram)
  • The two-approval quorum plus the Olympia schism has deadlocked merges
  • More active, neutral maintainers are needed to move past the deadlock

eth/69 and the Case for an ETC-Native Upgrade

Diego, who researched and wrote on the topic, explained why adopting Ethereum’s eth/69 wire protocol is a poor fit for a proof-of-work chain.

• Details
  • Diego: eth/69 drops total difficulty from the status message; post-merge Ethereum no longer needs it, so to them it was noise
  • Diego: ETC needs total difficulty for heaviest-chain selection; without it a node could follow the longest rather than the heaviest chain. Total difficulty predates snap sync and was used for node bootstrapping
  • Diego: A change like this should be decided as a coordinated network upgrade across clients, not by one client or person
  • Diego: Naively following the longest chain enables a chain-split attack on network partition — an attacker mines a long, low-difficulty chain that looks ahead on block count but is lighter than the honest chain. Snap sync is largely orthogonal and safe, since you still complete syncing against the heaviest chain
  • Diego: Some eth/69 pieces are positive (e.g. dropping redundant receipt data); those could be cherry-picked
  • Diego / Istora: Rather than fight a protocol designed for a different network, define an ETC-native protocol (“etc1”, the ECIP-1120 framing) that keeps total difficulty; multiple protocols can coexist behind a feature flag (as Besu does), requiring no hard fork and enabling safer opt-in upgrades. This is the same protocol that has served the network for over ten years, so changes warrant caution
  • w1g0: Asked whether starting fresh affects existing smart contracts — Diego: no, the network layer and the contract/state layer are orthogonal
• Conclusion
  • eth/69 as-is is unsuitable: dropping total difficulty undermines heaviest-chain selection and opens a partition / chain-split attack vector
  • The recommended path is an ETC-native protocol that preserves total difficulty and cherry-picks the useful parts, coexisting behind a feature flag without a hard fork
  • Background reading: Diego’s article, eth/69 on a Proof-of-Work Network

Where Protocol Discussion Should Happen

Prompted by Cody’s view that the community call is not the venue for deciding technical changes, the group discussed the right forum.

• Details
  • Istora: Cody flagged that some decisions (e.g. DNS versus discovery for peer discovery) should not be made on the community call
  • w1g0: Agreed Cody is right — the community call is not a good forum for making binding technical decisions, though it is fine for higher-level direction
  • Istora: Would happily join a dedicated developer call; in its absence the community call has absorbed that role
  • w1g0: Historically there were separate venues for core-protocol versus Layer 2 / app questions; documentation matters
• Conclusion
  • Decisions on protocol changes belong in a (to-be-revived) developer call, not the community call
  • The community call is for direction and education, not binding technical decisions

Website Redesign and Visualizing the Protocol

The website thread focused on migrating the stack and making the protocol legible to newcomers.

• Details
  • Istora: Wants a landing page with dynamic, visually appealing explainers of how the protocol works
  • w1g0: His main interest is a smooth migration off the Gatsby site; supports the redesign and offers to help
  • Istora / Diego: A 3Blue1Brown-style explainer video and a visualization of MESS (and how 51%-attack defense worked) would help
  • Diego: MESS is currently deactivated and disabled by default but kept in the codebase out of respect for the community; it diverged a lot from upstream
  • Diego / w1g0: During past 51% attacks a person had to coordinate stakeholders to enable defenses — human “infrastructure” that should be made visible, showing where the network is and is not decentralized
• Conclusion
  • Migrate off Gatsby; prioritize visual, dynamic explainers of the protocol
  • Visualize MESS and the human coordination behind attack response to make (de)centralization legible

AI in Development and Content

The group debated where AI fits in ETC development and content.

• Details
  • Istora: In the age of AI there are uncontroversial uses (idea generation, tooling); a human should always sign off
  • w1g0: Cautious about AI, especially which agent or tooling is used; sees limited but real usefulness, such as drafting low-importance posts
  • weder: Disagrees with blanket caution — AI is becoming table stakes, not adapting is a disadvantage, and it can lessen the volunteer burden without compromising ETC’s principled values
  • Diego: For core clients, curation matters and depends on codebase size; his diff-based work isolated exactly the PoW-relevant changes so anyone can verify what changed. AI-generated client PRs he received were mostly garbage; experience reviewing the codebase and protocol is essential, and the human eye and criteria must remain
  • Istora: AI can produce valid code but not necessarily the right architectural judgment, especially for critical, low-level software
• Conclusion
  • Consensus: AI is acceptable for ideation and tooling with a human in the loop
  • Core-client code requires human review and protocol experience; unsupervised AI-generated PRs are not trustworthy
  • The methodical, human-based approach remains essential for critical software

Action Items

• Publish a clear org / permissions diagram for the ETC GitHub repos
• Add active, neutral maintainers to break the merge deadlock
• Revive a developer call as the venue for protocol decisions
• Progress the website migration off Gatsby and commission protocol-explainer visuals (including a MESS visualization)
• Add show-notes links: Diego’s article (eth/69 on a Proof-of-Work Network) and ECIP-1120

Full Transcript

0:14Welcome and introductions

0:14IstoraHello, everyone. I think you're on mute, w1g0. 0:20WedergartenYo, can you hear me? 0:22IstoraYeah. Can you hear me? 0:24WedergartenYeah, I got you. 0:25IstoraAwesome. 0:25WedergartenThey're going. 0:27IstoraIt's going very well, thanks. Thanks for joining, good to see you. How are you? 0:32WedergartenIt's my pleasure. Thanks for, doing it at a, you know, more… better time. Usually it's at the opposite time of the day, 11pm. It's not… not great for… I don't know, maybe, I guess it's because you're on the other side of the world. But what changed today? 0:49IstoraToday we are in Europe. I'm in Europe, and I'm here with Diego, who's also in Europe. 0:55DiegoYes, hello. 0:57WedergartenOh, he's actually there! 0:58IstoraYeah, yeah, awesome. I do. 1:02WedergartenDiego. 1:03DiegoYeah, hi, how are you? 1:05WedergartenDoing very well. 1:08IstoraAnd, we go, I see he's in the room. How you doing? We can't hear you. I think there's a mic setting that might need to be tweaked. 1:26w1g0Can you hear me now? 1:28IstoraYes. Got ya. 1:30w1g0Great. 1:31IstoraThank you for joining. Yeah, there's no green room this week, because, yeah, we've been… in Europe at a conference, and bit tight on time, so I think we'll just jump into it straight away. So… In a few seconds, I'll kick things off. Okay, hello and welcome to Ethereum Classic Community Call number 54. Today is Friday, 12th of June, 2026. Ethereum Classic Community Calls is a voice chat discussion about Ethereum Classic, and everyone is welcome. The call will be published on YouTube, so we kindly ask that discussion stays focused on ideas rather than individuals, and let's keep it classy. You can find past episodes, transcripts, subscribe to the calendar, and more at You can find past episodes, transcripts, subscribe to the calendar, and more at cc.ethereumclassic.org.. This week is a bit of a special episode. Today, I'm joined in person with Diego. Yup. 2:34DiegoHello, everyone. Hi, Diego. Yeah, happy to be here. 2:38IstoraIt's very strange… Not having latency between us, and being able to speak in real time. So we're taking the opportunity to do this community call while we're both Currently in Prague, attending conference here. We also have on this call some… Long-time contributors? Shall we say hello, to Wiedergarten? How you doing? I think we're on mute at the moment. 3:07WedergartenYo, how's everyone? Recall. 3:12IstoraGood to see you again, after a while. Glad you could join. Yeah. 3:19WedergartenI apologize, not always able to make it, but it's good to see another fresh face we haven't seen in a while as well. 3:26IstoraYeah, just like old times. We also have w1g0. 3:32w1g0Hello, everybody. 3:35IstoraHere we go. Good to see you. And maybe we'll try and do these calls at different time zones occasionally in the future, so that people from Europe can join us more easily, and Yeah, just vary in terms of, potential joiners. So, this week, We have just a couple of items that maybe we can talk about, but there's also just, obviously, every time, general floor for people that can bring anything they want to talk about. On the agenda I have lined up is the new website. And how we can tackle this. And what kind of content we can add or remove, and what features we can focus on. And I also wanted to take the opportunity, as Diego's here, to get into some more deep. technical… understandings, particularly when it comes to some of the decision-making for future Ethereum Classic features. We might touch on, DevP2P. and the option in front of us in terms of eth/69, or potentially something that's more specific to Ethereum Classic. So, we can talk about that. Either first, or after we talk about the website, or if there's anything else you guys want to bring up. It's been a while since we've heard from Wiedergarten and w1g0, so do you guys have anything that you would like to talk about? Well, we sh… 5:09WedergartenI think we should do your normal rounds, and then we can talk about network upgrades later, if everyone is interested. 5:19IstoraSounds good. w1g0.

5:21Website maintainers and the Olympia deadlock

5:21w1g0Yeah, for me, the order is not really important, So, I have some things that I would like to discuss, concerning, the website, Discord, and, also, the centralized nature of GitHub, how… We can, improve that format as well. 5:49IstoraYeah, that sounds… Intriguing. What do you have in mind with the GitHub stuff? Because it is actually quite a pertinent topic. That I've been thinking about as well, and particularly how we move forward, with this apparent deadlock between GitHub maintainers and the whole Olympia, no Olympia… schism that's currently going on, and how we move forward in that. So, if you have any, ideas. Why don't you, let us know. 6:22w1g0Well, first of all, we have the, repositories. Each have their own purpose, but they also have, all have their own governance, and, I think it, is not really clear who is… yeah, maintaining which repo. So, I think the… the nature, it should be transparent that, the… who is actually able to have right permissions, In that, in that specific, repo, and also to… Bring on more people that can, That can sign, so that we are not… In this, issue that… There are not… that it does not stagnate because you need too many people signing, to proceed. And, also, well, yeah, the opposite. 7:38IstoraRight. It's quite a… A balance between having enough like, a minimum quorum in terms of approvals for things to get merged. I think currently on the main website, it's two. approvals. but also… Having, not too many, such that nothing gets merged. And I think historically, it was 2, because… based on the number of active contributors, it kind of fluctuates and settles somewhere, and it just happened to be two. Maybe that's too high, but I think in the current environment, it's… Better to have a stalemate than one side, like, dictating. Everything that's on the website. And that's also why, like, having 3… People that are, like, coordinating to push things forward is also a problem. So… Ideally. I think after this call, I… I mean, I can tell you right now from… from my understanding, so with the website repo. I'm an administrator on that repo, which means I can decide which team members are in the website maintainer Group. And there's currently, I believe, like. 7 people, I'll check right now. Most of those people are not… actively contributing. So, I'll look right now at the team for Ethereum Classic website. I think it'd be great to have more contributors, as you mentioned, especially ones that are able to be active and engaged, and ideally help us Like, not take sides, necessarily, but at least get us past this deadlock phase. Somehow. And having, like, a neutral third party that's… I guess a bit like you, w1g0, or Wiedergarten, being, like, committed long-term. Might be helpful in this scenario. So let me just open up the Teams… So… Yeah, in the website maintainers team, there's actually 10 people, and that includes, Diego, Phyro, myself, Elaine, Bob Summerwill's still there, I guess… That can be, updated. Kimmy? Cody? Keith Hall Barnett, The Enthusiastic As, and Christopher Mercer. So that's all the people in the… website team that have the ability to approve merge requests, basically. Pull requests. And if two of them agree. It's a little bit more complex than that, but basically. If one of the people that have made a pull request And one other person approves, that's not enough to get something merged, it has to be… two separate… Maintainers to approve. And that means that right now, like. if either side of the active Olympia debate participants Submits a pull request, it's unlikely to get approved, because you need at least two people. If that makes sense. Above me, basically, is the GitHub admin, and I believe that Cody is one of those. So Cody, has full admin… Right? As far as I understand, I'm not sure, and it'd be good if, we could get, like, an organization diagram to confirm What roles different people have. But basically, Cody, I believe, has the ability to… Remove anyone from any team, and… Re-ascribe which teams have right access to the repos. So that is my understanding. 11:33Diegoof… 11:34Istorawho controls the GitHub repos, basically? 11:41WedergartenSo, I think I understand the problem is that there's kind of a deadlock on some of your proposals. I don't know if the one that you sent for switching the Discord again went through, or if that's the one that you're talking about. But I'm not sure if it's possible to have an actual neutral participant in the sense that you're trying to say, because I think… that people are going to be picking sides on this, and the idea that one person is going to be accepted by both sides as a neutral party, I don't see anyone, at least right now, in the field of candidates that could be like that. The closest, I would say, is Cody. 12:23IstoraYeah, in terms of, like, neutrality on the Olympia topic, a lot of the pull requests are basically… Determined based on Whether it's, like, If it's concerning Olympia. I think it's, like, automatically a bit controversial, and for that reason, I've been, like. intentionally not approving things that may mislead people into thinking that Olympia is further ahead than it is. And then, contrary to that, like, the Olympia guys don't seem to be approving anything that's not related to Olympia. 12:58w1g0What I want to say on the Olympia, debate is that While, the elephant in the room is, the funding, they have a proposal. Which is heavily critiqued, because it violates the fundamentals. But in the meantime, there's also no counter-position made, so they are trying to solve a problem that no one else is solving at the moment. 13:32IstoraSo, actually, myself and Diego published an ECIP called ECIP-1120, which is the… basically counterproposal to Olympia in terms of the mechanism of 1559. So there is another option on the table, and that did finally get merged after a while. Going back to the ownership structure, I've just found that Elaine… Mikey O? and Cody are basically the admins of the… Ethereum Classic repos, so there's 3 of them. 14:11w1g0Okay. Well, it's not only for the… because Wiedergarten, pointed out for the ECIPs, but it's not only, for, that repo that we are… having some delays, I saw that on the website. There were two, requests for adding it in the applications. There, there was CryptoFlower and Saturn text. But they're still not being approved, while they only need two signatures. If somebody not agrees, okay, that's fine, put a comment, but nobody… I thought you signed one of them. So, that's, that's, in my… opinion, an issue. On the volunteer repo, I have, made a request, so, if volunteers are not being welcomed, you're not gonna grow your user base. 15:14IstoraSo, yeah. With reference to those two additional applications. I approve both of those, and just waiting for another approval. They seem to be non-controversial, not related to Olympia, so the only reason they're not being approved, I think, is just lack of… activity. So it'd be good if we could get some, as mentioned, more active maintainers on the website, Did you create that pull request on volunteer? Recently? Or where is that? 15:45w1g0I made an issue. I don't think it's needed to be a pull request. I didn't see that in the, in the README that it needed to be a pull request, so… 15:58IstoraNo, you're right, I think. And, yeah, this is something that one of the organization admins, i.e. Elaine, Miko, or Cody, would need to approve. And maybe it's just not on their radar yet, so I will… Literally right now, CC Cody into the comments on that. So maybe he'll get back to us on whether w1g0 can join once again as a volunteer. For people that are kind of, like, recently joining Ethereum Classic. w1g0, could you, like, maybe give just a summary of how you've been contributing in the past? 16:40w1g0Well, my contributions, in the past, have been limited, to… maintaining the Ethereum Classic website. I've been a moderator on the Discord. I've been a very, Limited time and admin, on that same Discord. And, I did some hard fork, coordination, in the sense that I did the transcripts, for the dev meetings, so that's, my, My contributions, so far. 17:36IstoraAnd this was… would be around, 2020-ish, I guess, till 22, if I remember correctly. Or a bit earlier as well? 17:48w1g0Oh, I, I… I have no idea, about time. Time flies. 17:56IstoraIndeed. But it's good to have you back. And, you, you also… I think maybe if you are… potentially becoming more involved once again. Like, the Discord front is another… element that I think could also use some attention, and I think your experience there could be quite valuable. 18:20w1g0Well, yeah, it all depends a bit on, on how this, evolves, because, well, another thing that I have noticed is, that Meal Bits, Chris Yogas, They all left maintainers. Grayscale funding, I stopped. These are some fundamental… changes, I believe, that are not… Really, bad news, but they… are… Moell. Not… not really optimal as well. 19:12IstoraYeah, that's true. But I think with all… with all change, like, there's also opportunity. So… like, it seems that ETC Co-op, or at least from what I understand from Cody's, intentions that he's shared on Discord, is that the ETC Co-op would be winding down. Probably sometime this year. So that means that, yeah, the… The volunteer community and potentially other sources of funding will need to be figured out. I'm confident that there will be solutions to that, and that's partly why I'm stepping up and trying to be involved more and more, and doing these calls. As well as other things in the background, which… Hopefully, we'll be able to announce soon. In terms of the deadlock, though. I do think that even if the person that comes in is not 100% neutral and has an opinion, like, everyone has opinions, right? But… Being, like, having some skin in the game, and having, like, proof of contributions before. Will definitely help in terms of… Being an active maintainer, and having a voice in that discussion. Because… really, I don't think it's necessarily… a problem… based on… like… the community doesn't know what to do. It's more just, there's not that many people that are active maintainers, and that's been, like, an opportunity, for one side or the other to be pushed without really much engagement with the wider community. So I think right now is really a good time for more of those voices to be heard. as maintainers. 21:07w1g0Well, the… if… The ETC co-op is going away, and there's another party stepping up. That's, well, it's replacing the central entity with another central entity. in… in an ideal world, we would have, several entities, like, while the other, was not really, ideal as well. But I really liked the… How can I say the… the ecosystem when, Charles Hoskinson was there with their Mantis team, and this coordination, and all… all… it was, it was interesting. The only thing that was not that interesting was that the Mantis team was not really on top of things, and they were more asking. questions, but if you have two teams that are knowledgeable, you can have, interesting discussions, and I think that was, lacking in the past. 22:19IstoraYeah, and I do actually think that, if anything, this Olympia, Period. Has… Caused a lot of… Activity. Almost like kicking the hornet's nest and creating either people responding or, like, at least some activity. And, again, like, I do appreciate that Olympia authors have made an effort to do something. And that in itself is… A good sign that… at least something's happening, and us responding to that is also a good sign. Myself responding to that is also a good sign, so… The only thing that I really hope we can get back to is having this dialogue, and… Currently, people are not speaking to each other, and that… prevents any progress, basically. And it's… it's gonna be difficult to move forward unless we restart that dialogue. And that can be done on purely technical conversations without having any, necessarily. personal engagement on a… Like, it can be just purely conceptual engagement, I think. As a next step forward. And part of that is… I think leading us nicely into… The first… or maybe we can start talking about this technical… element of the agenda, on eth/69. Which, I was talking in the Olympia Discord earlier today. And Cody was mentioning about, some… I'll read the quote verbatim. So… on the topic of why Cody was not joining these community calls. He basically said that, He's thinking about the depth and breadth of the tree search during healing of SnapSync. eth/69 plus behavior during handshake. DNS versus discovery for peer discovery. And… He said that some things, he doesn't care about other people's opinions, but some things he does. And the community call was not a place to have this conversation. So I thought it might be nice for us to have this conversation.

24:46eth/69 versus an ETC-native upgrade

24:46IstoraAnd given that we have Diego. With us, who has written on the topic, on… eth/69, I thought, why don't we… potentially move things forward by starting a purely technical discussion? 25:01DiegoYeah, absolutely. Yeah, just, two weeks ago, I started to… kind of research. Yeah, we were thinking about upcoming network upgrades, and what to include, and what to… can be delayed, and so on. So one of the things that popped out was, this change that, Ethereum made, on their network layer by upgrading their version of the protocol, and so, right now, the consensus on Ethereum Classic runs on top of the eth/68 specification. And that change will be, like, or should be discussed as part of a network upgrade. It's not just that, like. one team or one person could decide on what to do with the network layer. So, yeah, just for having some context or more information, it's that, like. like, two, two weeks ago, I started this research. And… and I posted, an article, I, I'm just, opened a substack. So we can share the link in the notes. But, basically, there I went through, like, why it's not a good idea of adopting the changes on eth/69 for a proof-of-work network. Basically, the main change there, or the thing that will prevent it to be an option for proof-of-work network, is that, in eth/69, they dropped the total difficulty from the status MESSage. And that changed a lot, and it makes sense for a proof-of-stake chain, because they don't need it, and actually, they had set a total terminal difficulty. So… For them, that… for them, that was just noise. So they remove it. There were some other things that may be positive for a protocol. In the new version, like, for example, dropping bloom filters on… Things like that, that will… shrink the size of the packages, and I think that's… that's good, but the problem about adopting eth/69 in the same way that it was published for Ethereum is that They are basically dropping the total difficulty there. The problems that are tied to… to it is that… well, basically, it's an historical thing, it's an historical situation that has been… settled a long time ago. There was a back and forth in the past, about, this very same… field, and, like, the… well, this is more extensively in, like, explain in… in my article. But basically. it… the first version was eth/61, then, it didn't have, It had… initially, it had total difficulty, then they removed it in eth/62. And then I think it was added back later on. Basically, that change was made in 2015, so that's when the total difficulty was finally added. That was for… for solving, and… like, the bootstrapping of a node. Basically. it will… so it… this exists way before the specification of a SnapSync, so it solves a really early problem about syncing the blockchain and a proof-of-work chain. Basically, the consensus says that, the… The canonical chain will be the one with more total difficulty on it. So, that's what it's, reflected into the network, the networking layer. So, let's say if we drop that MESSage. Then, the only thing that we can use for choosing Which fork to follow will be the longest one. And that's… That's not the right signal for a proof-of-work network. Because, for example, if you are syncing from scratch, and you have to pick on which node to follow. If you only choose, by… by the longest one, which… which one of your nodes has the longest chain. And you pick the longest one, that longest one could trick you and build a really long… really long chain, but with really low difficulty. And that would be a problem. So… This decision of following the terminal difficulty will be that, okay, the first thing is that you have to trust. Which node to follow. But with the MESSages itself, you will be able to… to prove that you are able to reach the announced total difficulty. So basically, that's why it's so important to have the total difficulty as part of the status MESSage. And… So, for SnapSync, that came way later in this… This, research, or this development of the network protocol. It's not a huge problem, because you're already starting from a network that is advanced in total difficulty terms. 30:35IstoraSo… 30:36DiegoIn that case, you can say that you are kind of safe. Because you will have to replicate a network that is longer, but at the same time has enough terminal difficulty. Because at some point, you will have to complete, what you are snap-syncing. And you will check the upcoming, blocks to connect into your, into your chain, and your chain will not accept Blocks with… without a proper… terminal difficulty. So, in that case, you can say, yeah, we are sort of safe, but the main problem arises on the… on the full sync. So, basically, that's a brief explanation on why it's not a good idea. That being said. And what I said at the beginning, there are certain things that are interesting, on eth/69 and that could be adopted. But if we want to do that, it might be the right time to start thinking about having our own protocol. And that's something that has to be agreed among, the different clients, and… and it's important, and it's something to… To be decided, and to think about, a migration, and probably, like, a transition, because we will have some times where both Protocols should coexist, and then eventually one will be dropped in favor of the other. If we go down that path, probably, like, we can name it ETC slash 1, or etc/ any number that we… decided to be the first one, the first protocol that will be native for ETC. In that one, we will, adopt these changes, like, dropping, them… Some things of, of, like, like, the Bloom filters, also some things that is… they are for history expiry, that are, like, there are… those are features that we don't have yet, but, Ethereum has the building and putting the building blocks. For… for in the future, maybe, discussing about, expired in the history, but those are things that we can put in place. But I think that's part of a broader conversation, and… but I think it has to be treated in the same way as any other protocol upgrade, and that's the way, as Ethereum has been Doing for this type of changes. Because basically, in the end, it could, result into chain split. It will not be strictly a consensus one, but it will be, like, at the communication or networking layer. So, yes, I think it will be good if people are interested in this to read the article I put in. I think it's, yeah, has some interesting information. I made some… diagrams there to… to explain more how it works, how it all works. But, yeah, in a not-so-small nutshell, I think that's… that's all. 33:53IstoraCould you, give, like, a… just a… To step back, for… for the… from a higher level view, like, how does DevP2P And the protocol? like, interact with each other in the client. And… Given that the… Like, these are two separate… layers, DevP2P not being part of the core protocol. Yes. 34:26DiegoSo, you have… first, you have the, like, a discovery protocol, which is the Kademlia, and this exchange of MESSages that you have… you send a hello, then you receive a ping, and you respond with a pong, and then you will be asked for your neighbors, and all that. Once that connection is established is when the secondary protocol kicks in, and that's when you start talking to peers, and then it's like, basically, When you pick up which, node to follow among your networks, or the ones that you… You already know. 35:06IstoraAnd the worry is that if you are preferentially communicating with the wrong peer, because it's advertising information that's less relevant to proof-of-work. Yep. that could cause issues with syncing. 35:21DiegoYes, I mean, that node will probably follow what the longest chain. I mean, and there is also something interesting about how, and this is also part of your portfolio, how a client should decide The first thing that they do is also exchanging capabilities, and they will pick the biggest one. So, if we have, like, two clients, or we have, yeah, two clients with eth/69, in this case, implemented, they will prefer connecting among them using eth/69. And that will create, like, a… like, a cluster in a network, like a communication among them only. And that's also a risk, and it's a… it's definitely an attack vector. 36:07IstoraI see. And what would be the motivation for going to 69 from what we have now? Like, apart from the… The state… the bloom filter removal. Is there, like, conceivably some, like, interoperability path potential that's beneficial to follow Eth long-term? 36:30DiegoWell… Not necessarily at this level, because they are dropping a lot of things that are, not important for them. Like, for example, it has been signaled… it's signaled that, in the upcoming release versions of it, they were going to drop MESSages that are really important for the synchronization of a proof of our chain, basically a proof-of-work chain. Which is the advertisement of new blocks and new block hashes, because now they… they got that information from the consensus layer, so they don't need those MESSages anymore. So, like, following blindly what Ethereum does is, like, a dead end, basically, because, I mean, they are going through their own agenda of, like, dropping everything they don't need, which makes sense. But, yeah, it doesn't make sense to follow them blindly in this… In this particular case. 37:27IstoraRight. And the interoperability benefits that you would get from other parts of the EVM, like smart contracts, they don't apply. Yeah, no. Because we're just talking between ETC nodes. We don't need to be compatible with Ethereum nodes at all. 37:40DiegoYeah, no, not anymore. I think, actually. Yeah, it could be positive, because when you're syncing, you're getting a lot of noise from… From other nodes that are not Specifically, for ETC, so I think it might be actually beneficial. 38:02IstoraRight. So, instead of trying to follow the eth/6970 path. it's better to just start our own with ETC One. Yeah, probably. And then we can design it specifically for ETC's needs, and maybe adopt future changes. But primarily, like, not try to… Fight or work around a protocol that's not designed for proof of work. 38:29DiegoYes, and basically, it's important to… I mean, to… to be aware of that this very same protocol is the same one that has been serving the network for the last more than 10 years. So we have been on top of this protocol for… I'm checking the dates here, for 11 years. The very same one. So, like, rushing now on changing it, yeah, it has… it has to be something that has to be really well thought and discussed. Right. 39:01IstoraIs this the kind of… change, assuming it doesn't require a hard fork. That would make more sense to do in a… like, non… if you're gonna do an upgrade. don't tie it to a hard fork, right? You could… you could do it at any time, essentially, and you could do it in a way that's easier to… Like, in a gradiented way. Like, so you're not just switching everything in one go, in one upgrade? 39:29DiegoYes, yes, and… yeah, and that's interesting. Yeah, with the proper coordination. 39:36Istoralike… 39:36DiegoDifferent or multiple protocols could coexist, and that's an interesting path forward. for these type of changes, because, I mean, you may have part of the network connecting or exchanging MESSages in one version of the protocol, and some others with the other, and… yeah, that's something that can be done, and… 40:01IstoraAnd you could have it as a feature flag that people opt into? Yep. And then upgrade in a much safer way. 40:08DiegoYes, actually, like, for example, Besu, they have, The flag that, that says what's the maximum version Of the protocol. I mean, of course, if we are changing the prefix, and not being ETH and being ETC, and, well. probably there should be… there will be some things that have to be adjusted, but, overall, the mechanisms are there. I don't know exactly about the other plans, but I know for sure that Besu has that flag. 40:40IstoraCould you, explain, like, the worst case scenario in terms of an actual attack? That might happen if… there was an Ethereum Classic client using eth/69. 40:53DiegoYes, I mean, the worst, thing that could happen will be that, you could create a cluster Of, like, a completely new state among a set of clients that they never realized that they had been tricked by. Malicious, player that they announced a really high block number. with, like, a fakely, created… I mean, it had… I mean, it would be actual proof of work, but it would be probably way… less difficulty than the… than the longest chain, or the canonical one. I don't want to be the… the longest one, the canonical one. 41:37IstoraThe heaviest chain. 41:38DiegoThe heaviest chain, yes. 41:39IstoraSo this would create a chain split based on the network partition? 41:42DiegoYes, yes. So, yeah, that's… that will be the main… the main problem. Yeah. I see. 41:50IstoraAnd it's particularly… Relevant to SnapSync. Do I understand that correctly? 41:59DiegoNo, well, no, actually, for SnapSync. you could say that you will be safe if you upgrade to eth/69. I mean, in terms of eth/69, let's say that happens, and you only have SnapSync as your syncing mechanism, you could say you are… you could be quite safe, because Even if you get… if you pick the longest, chain announced by a peer, that peer will have to send you a block that will connect to your existing chain. And for doing that, that malicious [peer] had to send you, A block with enough difficulty in it. So, in that case, we can say we are pretty safe. But, the main problem will be for the full syncs, which… In my particular opinion, I think full sync is the most important aspect of a blockchain. 42:59IstoraRight. 43:00DiegoI agree that it's good to have snap syncs or protocols that are more user-friendly. But, yes, I have a… like, I can say quite large, opinions about, history, expiry, and those sort of things that, yeah, I would probably have to research way more, but so far, I think the most beautiful mechanism that the blockchain has is the full sync property. Right. 43:32Istoraw1g0, I see you had a question. Did you want to… Jump in now? 43:38w1g0Yeah, sure. I was wondering, this, Starting from zero, which makes sense, since the consensus mechanism is completely different. if it would have, any complications, implications, for the smart contracts, that get ported from Ethereum, on ETC, if they're… maybe, like, an attack factor, in, I don't know, in different opcodes or something, I don't know. 44:11DiegoNo, no, no, no, thankfully, no, these are two orthogonal. Yeah, aspects of the, of the chain. 44:18IstoraGreat. Right, it's really just the network layer, and peer discovery, and syncing. 44:27DiegoYeah, it's also about consistency, because, I mean, we have a mechanism, a fork choice mechanism, within the network, the consensus, let's say, which is that you will never connect to your chain a block that has lesser difficulty than the one that you already know that it's the best one. And if we drop that into the network layer, we will have another yeah, and another concept there for picking, for picking up, which will be the… 45:00w1g0I think that would be really interesting, for me personally, I think, and I think it would be helpful for other people that are, less technical. is to have a animated, video on how, a client, miners, knows, distribution of ETC, currency, how this really, works, and maybe how these certain, changes proposed would affect like, people, I think… oh, well, I don't know why this, so little, traction on ETC, but, first of all, it would be that people just follow, the crowd, and they're on ETH. And Solana, I guess, But secondly, I think there's also the history of the 51% attacks. Which maybe are not really clear to people what they are, but… They might, say that, It's, unsafe, and I think that maybe an animation, on the consensus, Would, well, visualize, make it Because, well, we all have different learning styles, and for people who are more visual and auditory, or some documents might not really, explain it well.

46:45Protocol education and where technical discussion belongs

46:45IstoraYeah, I totally agree, and it kind of ties into the next topic with the website. if you do check out the article that Diego published, which I'll add to the, the show notes after this call. There are some diagrams on there that try to explain how the protocol is communicating between peers. In both eth/68 and eth/69. in a visual way. It's not a video, but yeah, it would be great if there was kind of like a… 47:18DiegoIs it 3… 47:19Istora3 blue, 1 brown? style YouTube video explaining how, the various aspects of ETC actually work under the hood. Because there's… there are some pretty esoteric stuff in there, and like… In ETC world, there's probably only a handful of people that really understand how it works, so it'd be good to have more people that do. Even though it's less technical, and I put myself in that category as well. And I'm thinking, like, on… Actually, yeah, before we move on to the website, were there any… comments or questions about eth/69 from the… participants? 48:14w1g0For me, well, this, sounds, acceptable, but I'm not technical enough to… to understand. I have a broad idea what's happening, but I cannot voice, Any opinions? 48:32IstoraYeah. So, for a bit of, like, background context, the… some of the clients that have been worked on by the Olympia guys, are implementing eth/69. and it's kind of like a technical decision that I think is worthy of more conversation. And… part of the reason that I'm bringing it up here is because Cody specifically mentioned this protocol earlier today as something that, is kind of just decided that's happening. Similar to Olympia. But I think, definitely. maybe is not the best choice, and there's definitely room for debate in there, and I think having a forum to discuss those technical aspects is exactly what this call is supposed to be about, and I hope that this forum Can be hosting that kind of debate as it has done in the past. But that requires the participation from, from both sides. So… It's almost like an open invitation to… even if it's just purely technical discussions, I still think there's value for everyone to participate in them. And this… eth/68/eth/69 thing is just another one of those examples. And I hope that… maybe Cody can either… respond to this in Discord, or maybe even join a call, where we can have these technical debates once again. 50:02w1g0I want to chip in on that, and I think that Cody is right. I think as there might be, or there probably are, very technical people in the ETC community, I saw it was also a question in the community calls, where should these technical discussions be held? And I think that, that's really for a dev call, where people are really technical and can… pick up, you… there's no harm in, explaining a technical issue in the community calls. But I don't think that the community call is a good forum, for… Yeah, making decisions on technical issues. 50:52IstoraYeah, that's a fair point. If there was a developer call. I'd be more than happy to join that and discuss things there. But in lieu of that, this is, like, the only call. So… There doesn't really seem to be any other option. than having this call for both the technical side and the community aspect, but I would love to join a developer call as well. 51:21w1g0Yeah, that's also a historical point, because we have a… For quite some time, a dev chat on the… On the Discord, but it's… it's really not being used, And I think it's more, well, how can I say, something that's… that's not a habit. It was just not a habit for devs to have their discussion. Whether it's for core, protocol, explanations, or for Layer 2 app, questions… well, there was never… there's never been, a back and forth between, like, yeah, how should we do this smart contract, or how should a client, respond to this behavior? Well, that's… that's something I would have thought that would have been interesting to follow, like, somebody who is not technical and is willing to learn. There's not really much documentation around. 52:42IstoraYeah, yeah, and this kind of goes into a bigger topic about how the direction of development is Decided within the community, and previously co-op was almost like… By default. The funders and deciding direction of the protocol. But now it's winding up, like, there must be some other way that we can come to these decisions in a decentralized way, ideally. But again, that requires communication. So, hopefully that will return.

53:17Website redesign and visualizing the protocol

53:17IstoraBut you did make a good point about the documentation, and maybe we can now talk about the improvements to the website. That, the upcoming redesign and basically rebuilding of the whole thing later this year, can address. Did you have any thoughts on that, w1g0? Because I know that you were expressing interest in helping with that. 53:42w1g0Yeah, for me, the main interest is to make the smooth transition from the Gatsby framework to Astro. I don't know if that's already really being decided, if that needs to be decided at all. I think it's a great solution. I'm in favor of that, and I'm really… offering my service to make that happen, if things need to be rewritten and observed that, transition goes smoothly. How the… well, how the website would look like. I think it would be interesting to have some more technical things that are more dynamic than static. Like, the pricing, like, how many nodes there are, who are, the miners, where are they located on, on a… On a map, so there's some backend stuff, I guess, that's… that's some things that I would like to see. So you can really track to see, is the protocol actually decentralized? Or I remember some phase that… When the difficult, the difficulty, when, some, miners are rogue or attacking the protocol, that it switches to, a higher, consensus, or that you need more percentage to overtake, the… Yeah, I've been out of the loop for some years. So, I have a conceptual understanding, but I don't know the terms. 55:36IstoraI think you're talking about MESS. 55:39w1g0Yeah, exactly. 55:41IstoraYep. Again, that's… 55:49DiegoMESS was happening on the P2P layer, Or… Yes, yeah, basically that's where it happened, yeah. 55:56IstoraRight, so that was another non-hard fork. 55:59DiegoYes, yeah, it will give you eventual… yeah. 56:04IstoraYeah, definitely, like, it would be awesome to have some more visualization and dashboards, and ideally be able to, like, show… Things like reorgs, if they happen. 56:19DiegoYes, well, something important to say is that By now, MESS is deactivated. It's not active by default in the… Core-Geth version, the latest Core-Geth version, and that has been the case for a really long time. That was a decision that yeah, we published, and we had a public discussion, you can trace it back in GitHub, but overall, the… The decision was that, yeah, the network is in a completely different state than it used to be when it was activated, and… Having MESS was, kind of a… technical debt. Because, it diverges a lot from the upstream. For the work I've been doing on alternative clients, I… I try to keep it. like, Disabled by default, but, like, they are being there just in case that we need to coordinate something to enable it. But, I don't know, that's something I'm probably up to debate. I would vouch for… for removing it completely. But, out of respect of the community, I let it there. So… but yeah, that's also… Something else to talk about. 57:42w1g0if I remember correctly, there was something, that… There were some alarms that were going off if, a reorg happened, and that somebody, I think it was MioBits, that, had to intervene manually. 58:00DiegoYeah. That was the case in the past, yeah, when the 51% attacks happened. 58:08IstoraIn what way was he intervening? 58:11DiegoHe had to coordinate with, yeah, the different stakeholders to basically enable or deploy a new version. It wasn't there, but it was one of the two. 58:23IstoraRight. That's also, like, an infrastructure thing that… like, human infrastructure, that I think needs… reinforcing. 58:32DiegoYeah, absolutely, and… Yeah, I will not say it's centralized, but we need a like, a common point of communication among different stakeholders for a situation like this one. Yeah. 58:46IstoraUnless… 58:47w1g0That's what I meant with, like, it needs to be visualized, that it's decentralized, and the solutions, so that it inspires people that the protocol is safe. 59:01DiegoYes, Yes, I don't think this… all these communications have been taken, like, in the shadows, but yeah, I mean, all that was traceable on the network activity, but yeah, probably not… properly… announced, or… 59:19IstoraRight. It's a bit of a paradox in… decentralized communities, like, where, like. Someone kind of has to fill the role of being a single point, or at least a node. relays information to people. 59:37DiegoYeah, and also in those, like, emergency situations, it's kind of important to have a… probably a single criteria to follow, because let's say that we have a dashboard that will alert everyone that we are going under a 51% attack. And what would be the decision there? So… I mean, at some point, maybe some… I mean… at least, general agreement on… Who to follow, will be important, and it's really difficult to plan a protocol for every possible attack there, because basically those… their nature of attacks is that we cannot prevent them. Yeah, we can only imagine what may come, but So, yes, it's, yeah, it's a tough… Decision. 1:00:36IstoraSo yeah, having a nice landing page with Visually appearing, dynamic stuff, appealing, would be… Great, I think. Yeah. 1:00:48DiegoDefinitely, yep.

1:00:52AI in development and content

1:00:52IstoraThe other thing I was… thinking about is, like, in the age of AI, like. To what extent do we utilize AI on the website? I don't think we should be generating slot for everything. But at the same time, it might be useful to use some features, For example, like, checking that links are alive. And potentially translating into different languages. There's probably some uses of AI that… Basically, nobody is against. And I think, there might even be the case of, like. Turning some of the more complicated concepts into easier-to-understand articles using AI. As a possible… as a possible use of it. Do you have any opinions, w1g0? 1:01:48w1g0Yeah, on the opinion side, regarding which, agent, will be used, and if it's Freeware, or, where the funding comes from, or, well, that… That's, one thing. On the other, I don't… I'm not really, in favor of, AI, because it's, well, quite controversial at the moment, and as ETC is a more conservative, I think, I wouldn't be ashamed to integrate that as, As the last community out there. 1:02:38WedergartenI disagree. I think that you can be all for ETC and the principled values that it holds, while still being supportive of the use of AI. I think that human oversight is definitely the most important part, whether it comes to your developing websites or making translations, it's just important that everything gets, like, a second check from a human, but when it comes to stuff like ETC, where the people who are contributing nowadays are volunteers, if we can triple or quadruple the productivity of the volunteers. Instead of having to necessarily get more volunteers, it can definitely lessen the load if it can be used productively and used to simply just do things that would take you longer to do without having to take as long to do it. 1:03:29w1g0Well, - if I may, pick up on that, on… based on what, weder is saying, I could, see, use for, let's say, in the Twitter together. application, an AI that is proposing, and that people are, Let's say, rewriting what it says, or… that approve, so that it can pass. In that, I'm… I think it can be useful, because I think that I'm not on X or Twitter or whatever. But I think it can be useful because the proposed tweets were very, very low in the past. 1:04:17IstoraRight, indeed. And yeah, having even just, like, the idea generation on a… and the prompting to actually… create tweets on a regular basis. would, I think, in itself, be useful? And yeah, as long as a human signs off on it, and it's not completely garbage, I don't see the negative in terms of output. On the front of, using AI during development, I'm totally for it, and I think that Like, modern development basically requires AI, like, almost everyone is going to be using it to some extent, some more than others, but I'm definitely in the leaning into agentic engineering camp. And if I do work on the website, then that will most certainly be using coding agents, To help with the migration, even if it's not, like… in the production side of having, like, a chatbot to talk to ETC or something, but during the development rollout, I'm… I'm definitely pro-AI in that… in that sense. As long as there's, like, a level of… quality to the work that's outputted, and, you know, like any tool, it can be abused. So, as long as that's kept in check, then… like Wiedergarten is saying, it's something that can really help amplify the efforts of the volunteers. And, with a limited number of volunteers, I think it would be more and more essential for us to lean into these tools to have an effect. 1:05:55w1g0I think, I think I already said that I'm not… much in favor of AI, to… implemented really quickly, because I'm more inclined to, Search other volunteers and have a human. Interaction, with everything. And this is based, because I'm, yeah, I'm more an observer, I'm more an analyst, and from the contributions I see, they are very, very low quality, to begin with, and secondly, it's always a human that needs to check. And, that's… while that's great for beginners, I have the impression that, senior, The seniors, really get annoyed by, the low quality, and that they'd rather do it themselves from the first, From the first time. 1:06:54WedergartenI think that's an interesting position, but I see it the other way around. The way I see it is that developers who've been doing development for before… since before there was AI, they understand how to work a codebase, they can do that by hand. They don't need AI. So when they… when AI steps into the picture, I feel like… and you may not have experienced this yourself, but at least for me. what happened was, is that it essentially took over certain parts of things that would… the time-consuming parts of things that I would typically not exactly enjoy the most doing. are effectively stripped out, and it's replaced by my, essentially, mostly my oversight, of what's going on. And I… and I'm not sure about the future, but The way things are moving right now, and it depends on you, you know, how you see things. AI is… becoming something that if you don't adapt to, then you may fall behind, and you may not, you may not be seen as adapt as people who are both good at development, and also good with artificial intelligence to help them. And the people who are just starting to learn how to code now. they are at a disadvantage because they are used to having artificial intelligence there, and they're not used to being able to debug things and to do things manually, and they are going to learn from the start to rely on AI to fix those things. So, from your point, I agree that it does cause quality issues, but I would say that comes from the more newer developed developers, and it's more important that we just try to expand, to give our knowledge from before AI and show them that you have to learn the ropes a little bit yourself before you incorporate AI, or else you're not going to understand what's going on in the back end and what's going on behind the scenes. 1:08:55w1g0Yeah, that makes perfect sense, but in the same way, Ethereum Classic is not the, the apex chain out there, so, maybe the timing is not, so crucial. 1:09:16IstoraYeah, I think Wiedergarten, you hit the nail on the head there, and I agree with your analysis. In terms of the timing for ETC, I'd say, like, really, we just need to get things done, and if these tools are helping us achieve that with the limited resources we have, then that's a good thing. I actually look forward, w1g0, to showing you what is possible, with these agentic engineering tools. in the right hands, and I'm thinking, like, the amount of hours I spent on the current version of the website just doing… complete monkey work, basically, aligning divs, etc, is something that now takes seconds instead of hours and hours, and that time saved can be going to other things and more productive things, so… Yeah, I… all I'd ask is keep an open mind, and… Let's, work closely, and hopefully you'll be able to see some of the power of this technology, if we're working together on the website. At least in terms of the… the less essential stuff. And when it comes to the core clients, this is where it's really an important question of how much AI is too much AI, and what kind of quality controls are necessary. Because it's not just a website, it's not just a contract even, but it's the whole protocol. 1:10:47DiegoYeah, I think, when… I mean, my opinion in this is about curation of the content. That's, the most important thing. And it will also depend on how… large is the codebase that we are building on, like, for example. The codebase for the Nethermind plugin is less than 2,000 lines of code. Which will be quite easily reviewable for any human being, And I think that's the way to go. For larger code bases, it may be, like, a challenge itself. like, for example, when I… something that I did when I've been working on, well, go-ethereum-classic, so this new type of revamped version of Core-Geth on top of Core Ethereum. Was to build. diff basis. So, because the main idea with that work was to try to bring it back, all the changes that were removed by the GoEthereum team. All the things that were important for a proof-of-work network, and adapting what was necessary for… for, like, adapting into their new architecture, because, of course, they have been changing things. But what… what I tried was to… well, to… to… Turn back to life to those commits. So, kind of reverting them, but in an intelligent way. And during that process, what it did was To put in place several tools that will create a wiki page with the actual diff. That will allow anyone to check If anything had been changed from The previous state of the codebase. So, that… will not… Ensure that, it will be bug-free, but at least it should give us a good signal that it will be in the very same state. As before the removals. So, that's where I think it's important, the curation and all the tools that we can build around for humans to validate what the AI made. And… and more… moreover, in… in a consensus. Client. So, yes, I think that's… that's important, and I agree on both sides. I think it's an amazing tool that allows us to do amazing things. But the human touch and the eye and the criteria has to still be there. And we never had to lose that, at least, for now. Yeah. 1:13:38IstoraRight. And whilst the AI can… Create valid code. it doesn't necessarily have the depth and the historical context to understand what's best for ETC, specifically. I mean, for example, this… this previous topic of eth/69? It could be the case that maybe an agent decided, okay, this is… let's upgrade, you know? You need to bump the version. And then you just go down that path and spend however many hours implementing that without really under, like, should we do this? And that's… that's not something that I think that AI is at yet, to make those high-context decisions. 1:14:21DiegoYes, part of my research was also, like, trying to… to go deep into the… the… Earlier on the old decisions that lead to the inclusion of of this, and then was when I realized, okay, yeah, that was there for a reason, and they already had this discussion internally into the Ethereum groups. So, yeah, that was already settled. But it's, yeah, that's something that, yeah, the AI missed. Probably. 1:14:51IstoraCould be the case. Yup. And, and yeah, the… heh. It could be the case that in the far future, like, the whole protocol is controlled by agents, but I really don't think we're there yet, and we have to recognize the limitations of the tools that exist as they do today. And I see them as just… Like, extremely good code completion. But not necessarily, decision-making. Tools. And depending on the complexity and importance of the software that's been worked on, I think… humans definitely still have a large part to play. Yeah. And we'll do for the foreseeable future. 1:15:34DiegoYeah, something like, for example, that an AI is… well, in my experience, has not been incredible, was that… Like, when you're working, for example, in a large codebase written by humans like Besu, and you want to introduce a refactor that has to be readable for reviewers, that you have to convince to include it. It's not really good, because it doesn't think in the same way that a human does. So, you have to kind of manually go through all the transformation, probably to reach out the proposition that it made, but you have to do it in a way that will convince, and during the process, you will get convinced also that it's, It could change, like, taking all the guardrails that you will… take for any call that you had written manually, so I think, like, for example, that's… it's another example where the human touch is really important, because in the end. There are still humans merging code, and you have to think of them. And the best usage of their time as reviewers and maintainers of the codebase. So it's not just about, throwing up, like. a pull request with a thousand lines changing, because, I mean, that will be actually disrespectful for the time of the reviewers. So yeah, that's also something else that we have to keep an eye on. Right, right. And actually, it was a time that I was talking with a Nethermind team. About some pull requests that I had to send for… for the… ETC plugin to work well with their codebase, and they told me that I had to, like. signal to them to send them a MESSage with a pull request, because they were receiving that many pull requests coming from AI that was impossible for them to handle, and… As they are, like, really good professionals, they had to… to go through all the… all the proposals. But, yeah, most of them were garbage or on this shape. I mean, someone ran an agent against their codebase, and who knows which prompt they use, and okay, they decide to just send a pull request. So, yeah, so the human part there is important. Right. 1:17:52IstoraAnd unless you have experience working with the codebase and the protocol. 1:17:57DiegoYeah, and also having experience reviewing other people's code and all of that. So, yeah, I think that's still the human part. It's there, and it's quite important. 1:18:08IstoraRight. So even if it's easy to generate a ton of new features and have I don't know, like, 10 pull requests a day. Through agentic work. that doesn't actually improve the speed at which you can merge them. Yeah. You still need the human in the loop there. And this slow, methodical, Human-based approach, especially for the critical lines of code in the clients, I think is going to be important to keep around for a long time. Okay, so we are, like… it's been a good discussion, it's been… more than an hour now, so I think maybe now's a good time to wrap things up. Would… Is there any other comments or last things to mention before we do so from… to join us?

1:19:06Wrap-up

1:19:06w1g0I have, nothing else to add. I just, wanted to, ask you what the counter… the ECIP for the counter-proposal for Olympia, was. 1:19:20IstoraThat number was 1120. 1:19:24DiegoAwesome. Chocolate. 1:19:28IstoraECIP-1120. I'll add that to the show notes, which you'll find in the transcript. 1:19:33w1g0Thank you. 1:19:34IstoraNo problem. 1:19:38WedergartenNothing for me, thank you so much. 1:19:41IstoraOkay, thank you both for joining, and… The next community call will be 2 weeks in the future, probably at the regular time, sorry, Europe, of 0 to 100 hours UTC on Friday, 2 weeks' time. So, thank you for everyone participating today. It's been a… A deeply stimulating call. So, yeah, see you next time. Thanks for joining. Till then, stay classy. 1:20:14DiegoThank you. 1:20:16w1g0Thanks for the discussion. Bye.