Key Points Discussed

• codeaholic presented the first of a planned multi-session series on quantum hardening, built around the draft ML-DSA verification precompile ECIP for Ethereum Classic.
• On Q-Day thresholds: roughly 500,000 physical qubits, 1,200 to 1,450 logical qubits, and 70 to 90 million Toffoli gates would let Shor’s algorithm recover a private key in 18 to 23 minutes. codeaholic’s reading put the serious-concern window around 2035, with the green room having floated 2032.
• The precompile targets the smart contract layer, not the wallet: contracts and their application login flows gain a second ML-DSA signature check, so an adversary who recovers an ECDSA key still cannot authorize contract actions or seize admin roles.
• ML-DSA-65 was chosen because it is a finalized NIST standard with published known-answer test vectors and a maintained implementation in Cloudflare’s CIRCL library, whereas Falcon has no approved standard yet.
• Istora pressed on what the proposal does not cover: funds already sitting in exposed externally owned accounts. Both agreed the interim mitigation is moving funds to an address that has never transacted, and that a complete answer needs account-level support, possibly account abstraction combined with the precompile.
• Two distinct threats were separated: the at-rest problem, where a public key sits exposed on-chain and can be cracked at leisure, and a fast attack, where a quantum machine reads a pending transaction from the mempool and front-runs it inside the block time.
• Istora argued ETC is structurally better placed than Ethereum: proof-of-work hashing faces only Grover, so ETC has one layer to re-armor (ECDSA at execution) where Ethereum has three (BLS validator keys, KZG commitments, and ECDSA).
• codeaholic proposed “quantum permanence”: proof-of-work anchoring plus post-quantum signatures could let ETC host data structures intended to last centuries, and floated ETC as a settlement backbone that other EVM chains anchor to.

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

This episode looks at quantum computing and what post-quantum cryptography could mean for Ethereum Classic and other proof-of-work chains.

• Post-quantum cryptography on Ethereum’s roadmap
  • Ethereum’s Strawmap lists a “post-quantum L1” north star, aiming for centuries-long security via hash-based schemes. What, if anything, could ETC borrow from this direction?
  • Ethereum’s lean Ethereum talks cover the post-quantum consensus direction. How relevant are these ideas to ETC?
• The quantum threat and Q-Day
  • Ethereum’s Quantum Plan Before Q-Day (Justin Drake on Bankless) lays out how Ethereum is preparing for quantum computers. How seriously should proof-of-work chains take the same threat, and where does the debate currently stand?
  • The Quantum Threat That Could Steal 2 Million Bitcoin (Justin Drake) estimates how much Bitcoin sits in key-exposed addresses. Is ETC’s exposure comparable?
  • Since ETC addresses are hashes of public keys, only addresses that have already transacted expose a key. Does that change how urgent migration is for ETC compared to Bitcoin?
  • Should a migration path be a focus of a future hard fork, and what might it look like? A draft ECIP, Quantum-resistance for Ethereum Classic: ML-DSA verification precompile, is one concrete proposal already on the table.

Background: the CL/DL/EL layers and why quantum hits ETH harder

The Strawmap organizes Ethereum L1 upgrades into three horizontal layers:

• CL (Consensus Layer): the proof-of-stake machinery. Validators, attestations, and finality.
• DL (Data Layer): data availability and storage. Blobs and danksharding.
• EL (Execution Layer): transactions, accounts, and smart-contract execution (the EVM).

Shor’s algorithm breaks anything built on elliptic curves or discrete logs, meaning a private key can be recovered from an exposed public key. Grover’s algorithm only weakens hash functions quadratically, which is fixed by doubling the output size. The question for any chain is how much elliptic-curve crypto is load-bearing, and how exposed the public keys are.

Why the problem is bigger for ETH than ETC:

1. Three exposed layers versus one. Because ETH is proof-of-stake with a data layer, quantum-broken elliptic-curve crypto is load-bearing in all three bands: BLS in the CL, KZG in the DL, ECDSA in the EL. ETC, being proof-of-work with no blobs, only has the EL problem of ordinary ECDSA transaction signatures. There is no consensus-layer or data-layer crypto to migrate.
2. ETH validator keys are exposed by design. A validator must publish its BLS public key and sign every epoch, so the crypto securing finality and a large amount of staked ETH is standing in the open. There is no “spend before exposure” escape hatch at the consensus layer.
3. ETC’s one exposure has a built-in mitigation. An ETC address is a hash of a public key, so the key is only revealed once the address sends a transaction. Addresses that have never spent are quantum-safe until they do. ETH accounts share this property at the EL, but it does not help the CL and DL keys that are exposed by necessity.
4. ETC consensus is already quantum-robust. Proof-of-work (Etchash/Keccak) rests on hashing, which faces only Grover and is absorbed by difficulty adjustment. ETH’s proof-of-stake rests on BLS, which Shor breaks outright.
5. Migration cost. Swapping BLS to hash-based signatures and KZG to hash-based commitments is a deep re-architecting of two whole layers, which is why the Strawmap makes post-quantum L1 a multi-year north star. ETC’s task is narrower: give accounts a path to a post-quantum signature scheme and a migration for already-exposed addresses.

In short, ETH has to re-armor three layers, one of which (validator BLS keys) is unavoidably exposed and secures the whole chain, while ETC has to re-armor one layer whose addresses are hidden behind hashes until spent, with proof-of-work itself already quantum-resistant.

Background: the “proof of seed phrase” mitigation

Vitalik has proposed an emergency quantum-recovery hard fork (Justin Drake references it in the Bankless talk) that lets existing users keep their funds after Shor breaks ECDSA, without everyone having to pre-migrate to a post-quantum signature scheme.

The key insight is that there are two secrets, not one. Most wallets do not start from a raw private key. They start from a seed phrase (BIP-39 mnemonic) and derive the private key through a chain of hash functions (BIP-39/BIP-32 KDF):

seed phrase --(hashing KDF)--> private key --(elliptic curve)--> public key --> address

Quantum computers attack these two steps very differently:

• private key to public key is elliptic-curve, and Shor reverses it. On Q-Day, an attacker who sees an exposed public key can recover the private key.
• seed phrase to private key is a hash. Shor does nothing to it, and only Grover applies (quadratic, easily out-sized). The attacker cannot climb back from the private key to the seed phrase.

So the seed phrase is a secret the quantum attacker still does not have, even after breaking the private key. The mitigation uses that. When the quantum threat materializes, a hard fork activates and:

1. Freezes ordinary ECDSA signatures, since they are now forgeable.
2. Replaces spend authorization with a quantum-safe STARK proof (STARKs are hash-based). To move funds, the owner submits a zero-knowledge proof that they know a seed phrase which, run through the standard derivation, produces the key controlling the account.

Because the proof requires the seed, and the attacker only recovered the private key, the attacker cannot produce it. The legitimate owner can. Funds stay safe even though the private key is public.

Caveats:

• It only works for keys derived from a seed via a hash. A raw or imported key with no hash barrier above it (some exchange keys, certain contract setups, brain wallets) cannot prove a preimage and is not protected this way.
• The seed itself must never have been exposed.
• It is an emergency design activated by hard fork, not a routine day-to-day scheme.

Relevance to ETC: ETC accounts are generated the same way (BIP-39/BIP-32), so the same hash barrier between seed and key exists on ETC. It is one candidate answer to the migration-path question above, and it pairs with the dormant-address scan below: the scan says how much is at risk, and proof of seed phrase is one option for how those owners could still recover it.

Background: ECIP draft for an ML-DSA precompile

A draft ECIP, Quantum-resistance for Ethereum Classic: ML-DSA verification precompile (authored by GravityLabLLC, still in draft), is the first concrete ETC proposal in this space. It adds a precompile that verifies ML-DSA signatures on-chain, with a parallel implementation in core-geth. ML-DSA (Module-Lattice-Based Digital Signature Algorithm, FIPS 204, the standardized form of CRYSTALS-Dilithium) is one of the NIST post-quantum signature standards.

How it might fit in:

• It gives ETC a native post-quantum signature primitive at the EL, which is the one layer that needs re-armoring (see the CL/DL/EL table above). A precompile makes ML-DSA verification cheap enough to use inside contracts rather than reimplementing lattice math in the EVM.
• It is a building block, not a full migration. On its own it lets contracts and smart-contract wallets check quantum-safe signatures, so users could move funds behind an ML-DSA-secured account or multisig ahead of Q-Day. It does not by itself rescue funds in a plain externally owned account whose key is already exposed.
• It composes with the other options discussed above. The precompile could back the quantum-safe side of a migration, while the proof of seed phrase mitigation covers already-exposed EOAs whose owners still hold the seed. One provides the new signature scheme; the other provides an emergency recovery path.
• Open questions for the call: is a precompile the right altitude versus native account support, how are gas costs and signature sizes handled, and should this ride an upcoming hard fork or wait for upstream EVM work.

Follow-ups

• Scan the ETC chain for quantum-vulnerable addresses: those that have already revealed a public key (any address that has sent a transaction) and are now dormant. Quantify how much ETC sits in these key-exposed, dormant addresses, since that is the funds most at risk on Q-Day. This is the ETC analogue of the “2 million Bitcoin” figure and would answer whether ETC’s exposure is comparable.

Introductions

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

AI Summary

Call 58 was the first of a planned multi-part series on quantum hardening for Ethereum Classic. codeaholic joined to present slides and a draft ECIP adding an ML-DSA verification precompile, covering what Q-Day is, how far away the hardware looks, and what the precompile does and does not protect. Istora then widened the discussion to migration paths for accounts whose public keys are already exposed, the difference between at-rest and fast attacks, and why a proof-of-work chain has far less to re-armor than Ethereum. Lunar joined for the introductions and stayed to listen.

Welcome and Introductions

Istora framed the episode and welcomed the guests.

• Details
  • Istora: Introduced quantum computing as a topic gaining momentum in cryptography circles, with predictions of a capable machine ranging from five to ten years out
  • Istora: Framed the two questions for the session as how ETC might deal with the quantum threat, and how Ethereum mainnet is planning to deal with it
  • codeaholic: Had slides prepared for what he expected to be one of two or three sessions on the subject
  • A few minutes were lost to a screen-sharing problem, which codeaholic resolved by rejoining from Chrome instead of Safari
• Conclusion
  • The call was set up as the opening instalment of a series rather than a single self-contained discussion

What Q-Day Is: Thresholds and Timelines

codeaholic gave a deliberately high-level definition and then put numbers on it.

• Details
  • codeaholic: Defined Q-Day in plain terms as the point where a computer can crunch complexity classical machines cannot, letting an attacker sign transactions as somebody they are not, including moving a wallet’s funds
  • codeaholic: The specific mechanism that matters for ETC is running Shor’s algorithm against an exposed public key to recover the private key
  • codeaholic: The hardware thresholds are roughly under 500,000 physical qubits, 1,200 to 1,450 logical qubits, and 70 to 90 million Toffoli gates, at which point a wallet identity could be stolen in about 18 to 23 minutes
  • codeaholic: Current hardware is nowhere near those counts, and the largest qubit counts (D-Wave’s) are a kind of physical qubit that cannot run Shor
  • codeaholic: His research pointed to around 2035 as the point of serious concern, with the caveat that the estimate assumes a historical rate of progress; AI capability outran predictions, and the 2032 date discussed in the green room felt like a plausible risk zone
  • codeaholic: A motivated nation-state could plausibly get there sooner, so it is the right time to start, but this is not a drop-everything panic
  • codeaholic: Every transaction publishes a recoverable public key by design, so any address that has transacted at all is exposed once Shor is available
• Conclusion
  • The threat is real but not imminent, and the exposure comes specifically from public keys revealed by past transactions

The ML-DSA Precompile: Where the Code Goes

The group worked out exactly which layer the proposal touches.

• Details
  • codeaholic: The precompile adds a small amount of code to Ethereum Classic, plus a small amount that contract authors add to their own contracts, closing this attack vector for their applications
  • codeaholic: Using it requires an extra step in the wallet sign-up flow that the application implements, increasing the complexity of the signature the contract verifies
  • Istora: Asked whether this is an additional opcode used primarily in the smart contract layer rather than in the EOA’s own signature
  • codeaholic: Both are needed. The contract needs the reference, and the application logic performing the signing between wallet and contract needs code added, incorporating an additional ML-DSA private key
  • Istora: Restated it as the EOA still using the existing signature scheme to broadcast, with an off-chain computation passed as a parameter and validated inside the contract, which codeaholic confirmed
  • codeaholic: Nothing changes on the wallet side yet; applications also need a disaster-recovery path in case a user loses the new key
  • codeaholic: Announced next-session goals of local testnet results, a Mordor testnet plan, a code review, and a deeper dive on ML-DSA and Shor’s algorithm
  • codeaholic: Noted the proposal also helps smart contract admins safely retain administrative control, which otherwise becomes a liability
• Conclusion
  • The precompile protects contract-level authorization and admin roles, and requires changes in both the contract and the application, but none in the wallet

Deriving the New Key and Choosing ML-DSA

Istora’s questions turned to implementation detail and the choice of scheme.

• Details
  • Istora: Asked how the account for the new signature is derived
  • codeaholic: It stays on device and is left to each application; in his own case it never leaves the device, as he already generates something similar for a LogTrees ID
  • Istora: Suggested that a BIP-39 wallet could simply use a different derivation path from the same seed, keeping one seed phrase while generating the quantum-secure key
  • codeaholic: Chose ML-DSA-65 mainly because it is a completed NIST standard he can trust, where Falcon had no approved standard at the time he checked
  • codeaholic: Added unit tests built on NIST known-answer test vectors, and uses Cloudflare’s CIRCL package rather than implementing the algorithm himself
  • codeaholic: There are other ML-DSA parameter sets, and adding the next precompile together was floated as a future code-review session
  • Istora: Asked about signature size, gas cost, and the effect on transaction throughput and chain growth if every transaction eventually used the scheme
  • codeaholic: Has no measurement data yet; benchmark-mode unit tests showed no obvious problem, and real numbers are the point of testing on Mordor
  • Istora: Clarified he was asking about raw transaction size in bytes, and how many transactions would fit in a block at the current 8 million gas limit. The two agreed to collaborate on the benchmarking
  • Istora: Noted Ethereum has opted for hash-based rather than lattice-based signatures, largely because hash-based schemes aggregate more easily, which matters for validators but not for a chain without them
  • codeaholic: Not a cryptographer, but expects all of these to be implemented eventually; ML-DSA was the fastest path to shipping something that can be iterated on
• Conclusion
  • ML-DSA-65 was picked for standards maturity and library support rather than on performance grounds, and the performance work is still ahead

Account Abstraction and Exposed EOAs

The discussion moved to the gap the precompile leaves open.

• Details
  • Istora: Noted an upstream EIP-8051: Precompile for ML-DSA signature verification, and that the next ETC hard fork already contains a precompile supporting passkeys, so this would not be a novel kind of change
  • Istora: Suggested the precompile could be combined with account abstraction so a wallet uses it as an externally owned account, giving a migration path to quantum-secure addresses
  • Istora: Laid out the gap. Someone with a pre-quantum ETC address that has already transacted has their public key on-chain and is not protected unless they act
  • codeaholic: Called the question of existing exposed accounts a very expensive one, likely a decade of roadmap, and an open question rather than something needing an answer soon
  • Istora: The interim mitigation is simple: move funds once to an address that has never been used, since its private key has never been exposed
  • Istora: Separated two threats. The fast attack, where a quantum machine reads the mempool, derives the signature, and replaces the transaction with a higher gas fee inside the block time; and the at-rest problem, where an exposed public key can be worked on at leisure
  • Istora: The fast attack is further off and can be mitigated by users simply not moving funds until a new signature scheme exists
  • codeaholic: Confirmed his proposal addresses the contract-authorization case, not the at-rest breach of a wallet; it prevents a stolen wallet from also corrupting valuable long-lived contract state
• Conclusion
  • The precompile is a building block for contract-level protection; protecting ordinary accounts needs account-level support that is not yet designed

Signature Agility and Ossification

A shorter exchange on whether post-quantum schemes are a one-time fix.

• Details
  • Istora: Asked whether ML-DSA is a one-time fix or whether the system should be designed to be upgraded as signature schemes age
  • codeaholic: Upgrades can be partly automated, but increasing complexity and attempts to control it are the two forces driving the cycle of faster attacks and stronger codes, so it will stay a fairly manual effort
  • Istora: Raised the political dimension for ETC specifically: how consensus is reached on which schemes to adopt, how often, and whether that is compatible with an ossification vision rather than perpetually chasing the latest signatures
  • Istora: Argued the precompile is useful beyond quantum resistance, as a general primitive for validating signatures from external systems, citing TLSNotary-style proofs about web page content
  • codeaholic: Had not considered that angle and thought it a good point
• Conclusion
  • Signature agility remains an open design question for a chain that also wants to ossify, and the precompile has value as a general verification primitive

Why ETC Is Better Positioned than Ethereum

Istora closed with the structural comparison, and codeaholic extended it.

• Details
  • Istora: Ethereum’s move to proof-of-stake left it with three layers needing quantum hardening, where ETC has one
  • Istora: Proof-of-work is already quantum-resistant because hashing cannot be reversed, so ETC’s consensus layer needs nothing done to it
  • Istora: Ethereum’s data layer uses KZG commitments, which are not quantum secure, so blob data availability is affected as well; replacing three layers in under a decade is a larger job than the switch to proof-of-stake, with no guarantee the solutions prove viable at scale
  • Istora: Quantum could turn out to be the best thing that happens to ETC as the largest proof-of-work EVM chain, and even if ETC did nothing, he does not see it as an existential threat
  • codeaholic: Coined quantum permanence for the property of being on the right side of the curve, letting applications store semantically rich data structures meant to last centuries on a physical, work-backed ledger
  • Istora: Floated alliances where other EVM chains anchor their security to ETC through bridges or storage proofs and pay for that security, which codeaholic said matches his own architecture for LogTrees
  • Istora: Suggested ETC’s slow, low-complexity approach may be the saving grace that lets it continue for a long time
  • Istora: Left proof of seed phrase and commit-reveal schemes as topics for future calls
• Conclusion
  • ETC’s narrower exposure was framed less as a defensive advantage than as a possible strategic position for the chain

Action Items

• codeaholic: Run the precompile on a local testnet and post behavior and performance results to the draft ECIP PR ahead of a code-review session
• codeaholic: Draft a Mordor testnet activation plan, show an application-side login-flow example, and go deeper on ML-DSA and Shor’s algorithm next session
• Istora: Scan the ETC chain to quantify how much ETC sits in key-exposed, dormant addresses, the ETC analogue of the “2 million Bitcoin” figure
• Istora and codeaholic: Collaborate on transaction-size and gas benchmarking for ML-DSA signatures, using baseline values and varying message sizes
• Community: Review the draft ECIP and post questions on the PR before the code-review session; codeaholic can also be reached on the Discord servers or by DM

Full Transcript

0:03Welcome and introductions

0:03IstoraHello, and welcome to Ethereum Classic Community Call number 58. Today is August 14th, 2026. Ethereum Classic Community Calls is a voice chat discussion about Ethereum Classic, and everyone's welcome. This call will be published on YouTube. We kindly ask that the 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 cc.ethereumclassic.org. This week, we are going to be discussing the quantum topic. Which is a thing that's been gaining momentum in cryptography spheres. As a bit of background, There's this idea that in the very, or somewhat near future, medium-term future. Some people are saying within 10 years, some within 5. The idea is there'll be this computer that… is able to… potentially… disrupt the operation of certain cryptographic protocols, including blockchain cryptography. So this week, we have on the call with us codeaholic and Lunar to discuss Potential future. And how Ethereum Classic might be able to deal with this quantum threat. And, we'll also be looking at how Ethereum Mainnet is planning to deal with it. So, to start off, let's, say hello to join us on the call. Hi, codeaholic. 1:35codeaholicHey, hey, good to be here again. Hope you're all doing well, and, looking forward to diving into quantum things. I've got some slides prepared for, like, my portion of what I think will be, like, one of two or three sessions, so whenever you want me to present my stuff, I'm happy to dive in, but, glad to be here. 1:56IstoraThanks for joining again, codeaholic, good to see you. And we have Lunar. 2:04LunarHello? Nice to be here, guys. How's everyone? Good to be on call. 2:10IstoraYeah, we're doing good, thanks. And we also had a really nice, interesting discussion, philosophical discussion just now in the green room. So if you're interested in talking about an array of topics, then please join us for the next, green room, which is an hour before the scheduled call. Okay, so… codeaholic? Is your presentation sort of laying some of the framework that we can provide context for this discussion? Or shall we just, like, try and lay out what the threat is exactly, and, like, what… for people that are uninitiated, could you potentially, like, just give us a quick overview of from your perspective. What the problem is. 2:55codeaholicYeah, I could definitely do that as relates also to the… code specifically, or to the draft PR, conceptually, to explain, like, what is the actual issue generally, and then what is the specific, nature of the issue that is being addressed with the, precompile concept. So I could just share a screen and jump into my slides, if that sounds good. 3:19IstoraYep. 3:21codeaholicOkay, let's see… share screen… One second while I find my permissions button. Let me… let me reload the page. Be right back, one moment. 3:37IstoraSure, no problem. If you're listening, There's a lot of notes in the show notes of this call at cc.ethereumclassic.org. And… basically… Ethereum Mainnet is the source of a lot of this information, specifically a guy called Justin Drake, who's basically, core focus is now on this potential solution for Ethereum upstream. Codeaholic is back? Are you… able to share? Okay… I… I think Codeaholic is having some, technical difficulties, but… if you can hear this codeaholic, then just start sharing your screen whenever you're ready, and K… I could cut this part out of the… 4:40codeaholicHello? Testing, testing. 4:42IstoraHey, hey. 4:43codeaholicOkay, yes, I'm back, can you hear me fine? 4:46IstoraYep. 4:47LunarWe can hear you. 4:47codeaholicIt says that my browser is not letting me share screen, so let me rejoin… I apologize, let me rejoin from Chrome and not Safari, and I think that'll fix it. My bad, be right back. 4:59IstoraSure, no problem. Yeah, so we've talked… we've touched on quantum before, on these calls, but… this time. Hoping to go into a bit more detail, and having, like, researched some of this stuff. partly thanks to Justin I think we can have a better understanding of what the issue is, specifically for… Ethereum virtual machine. blockchains. And the good news is, for Ethereum Classic, it's a lot less of a problem for Ethereum Mainnet. But that doesn't mean we can rest on our laurels. Okay. So, codeaholic is sharing his screen now. 5:48codeaholicOh, is that okay? To start sharing? 5:50IstoraYep, you can take it away.

5:52What Q-Day is: thresholds and timelines

5:52codeaholicOkay, cool, yeah, my apologies, I don't know what happened, except that Safari was giving me some problems, but let me just go ahead and jump into the slides that I have. Not gonna talk that long, but… with these slides, I will… I will just explain Ethereum Classic and quantum hardening, and… specifically, in the first session today, August 13th, I want to talk about what is Q-Day. at a very high level, but then specifically, what is the specifics of the precompile as it relates to Q-Day, the ML-DSA precompile, and then some announcements, like what I intend to talk about next time. So… I'm not going to talk too much at a high level, because I know that Istora has materials or, like, ideas he wants to talk about, too, so I just want to explain the general idea for what Q-Day is, with specifics being focused on Ethereum Classic, and I have a concrete example in some code. in a moment, in a couple slides, but basically, there are many ways to define Q-Day, but the… in a nutshell explanation, as if you're talking to a child, would be. Eventually, there's gonna be computers that are way faster, and they can… successfully process or crunch complexity that classical computers simply are not able to do today. And that will allow people to… basically sign transactions, in the case of the crypto world, as if they are somebody they're not, meaning impersonation, and this includes even moving a wallet's funds, to a different place. So, it's… it's many different ways you can define Q-Day, but with respect to Ethereum Classic, and with respect to the problem that I'm trying to solve, it is, using a quantum computer to run what's called Shor's algorithm, so that you can take somebody's credentials. And, this brings up the question of how far away is this? Meaning… with today's hardware, how far are we from the point in time in which, we… this is realistically a risk. And, just double checking if my mic is still good. 8:06IstoraYep, we can hear you. 8:08codeaholicOh, okay, cool. Yeah, so today, on the left side here, you'll see this is what is considered the state of the art for the two measurements that matter for when we'll get to this point, when we can perform this attack. It's measured based on qubits. which is, defined to be physical and logical qubits, and then it's also measured by something called Toffoli gates. So these are just two physical components that have to be built inside of this advanced computer. And we will need somewhere in these estimated ranges of these qubits, maybe a little bit under 500,000 physical qubits. 1200 to 1450 logical qubits. Which… which is just the representation of the information state that exists on the physical qubit. And then we'll need 70 to 90 million Toffoli gates, which are just, the next version of circuits that hold some charge in a configuration, similar to the types of gates that we have already in classical computers, but just able to retain more states or do more computations. Once we have a computer that matches these requirements. We'll be able to effectively steal somebody's, cryptographic wallet identity in about 18 minutes or so to 23 minutes, which is pretty insane, considering how big of a problem it is to do that. And, on the left side here, you'll see that we're nowhere near the number of qubits required. physical or logical. And, the biggest qubit count, which is D-Wave's. Is a kind of physical, qubit which is not able to run Shor. So, after doing some research on all of this, to say, okay, now we have, like, a moving target, kind of, or, like, some ranges for what range of qubits and gates we should be caring about. I did some research and found that All of this slide is basically saying that we really need to start really being concerned by this around 2035. The caveat to this, though, is that this kind of assumes… like a historical understanding of what the rate of progress has been, whereas if you look at the rate of progress in something like AI, for even just what you can run on your machine. for the kind of workloads you can process, it's way more powerful. and there's more to be desired, of course, but it's way more powerful than people were predicting. So I think the same thing is possible here, where the 2032 date that we were talking about in the green room does sound way more, like a risk zone. But what I want to say, though, is because of the complexity of what I'm going to show you in some later sessions as well, and then what we talked about with respect to Ethereum more broadly, like, the complexity they will have on the proof-of-stake side. It's definitely the right time to think about this now, and not when we get to the end of the 2020s, because in theory, if somebody, like, if a nation-state is motivated. Could they… could they build a quantum computer faster than 2035 or 2040? Certainly. So, it's good that we're talking about this now, but on this timeline, I do want to say, though, that it's not like a drop everything and, you know, panic and tear your hair out type of situation, so I don't… expect that this would be, like, a dot-com scenario with the Y2K apocalypse or whatever. In those days, but it's just something to start working on. So… in a nutshell, the risk is… as is relating to the point of this session, and, like, what code is going to be in review in the coming weeks, if it passes the drafting process and all. Basically, the… Specific example is that with every transaction, you have information that exists on the blockchain publicly. By design. And, with some of that information is a recoverable public key for transaction signing. So… because of the nature of classical computers, they cannot… reverse or derive the private key to that, it's just not a possible computation. But… the entire concept of Q-Day is when we reach the threshold by which, like, a quantum-powered adversary would be able to use Shor's algorithm to get the private key. For any wallet that has the private signing key for any wallet that has interacted with the blockchain. at all, such that there's a transaction, and then they'll be able to impersonate that owner of that wallet address. They'll be able to do that, like. Either by… in this example here, I'm just showing… where… somebody can be perceived to be a valid LogTrees caller, or you can substitute LogTrees here with whatever your smart contract is, but that's one implication of this. They would be able to… somebody wouldn't be able to impersonate you, and if you are using I don't know, some smart contract where you have a lot of value stored into it. Or it's just a semantic or memetic value to you, or to other systems. Because they're primitives, and what I'm going to show you in the coming slides is also just more primitives to build with. You don't want… you don't want the situation where you can lose either your funds or have your very valuable smart contract states be corrupted, or… the state altered, which is what this is, a risk. Like, this is… this is what this risk is of impersonation, basically. It's not just losing your funds in your wallet, but it's also having any smart contracts that… that you care about. In this case, LogTrees being one example, since I'm developing it, but also, like, I showed it to you before. So, you can understand the semantic value to a smart contract like that, that lasts forever, and is intended to be important. So you can see why you would want to avoid corruption there. of such smart contracts. So here's the example, like, this is what… this is what the current possibility is, not just for LogTrees, which is just an example that I'm using, but for any any application that uses this flow. Basically. You would be sending a transaction as a sender? And everything's fine, but… if in the future you are, somebody who's had your private key derived? with a Shor-capable quantum computer, then somebody will be able to forge transactions and appear as if it's you. Where… where the solution comes into play, which is ML-DSA Precompile, which is what the draft PR is for. Basically, by introducing a little bit of code, and this is a little bit of code, and… Ethereum Classic itself, and also it's gonna be a little bit of code that you have to add to your smart contracts. By doing that, you can basically make it impossible for this attack vector to exist, for your applications. There are other ways that we will need to quantum harden Ethereum Classic, this is just one of them. And as we already talked in the green room, like, Ethereum itself is gonna have way more than we have to do, so… you know, it's gonna be a busy season for them, but the point is, though, like, this is just one possible attack vector, but supposing that Supposing that you are an authorized user, the difference now will be that in order to use the LogTrees smart contract, or any smart contract that uses the precompile. There will need to be an additional step taken by the user and or the wallet sign-up process that your app implements. And… that's basically, like, an additional… it's kind of like a two-step factor, but not really, but that's the only example I can think of to explain. Basically, what will happen is it's just going to… increase the complexity of the signature that… the contract verifies. is actually. 16:08IstoraOkay. 16:08codeaholicfrom you. And just to clarify. 16:11Istoraclarified. This is, this is, like, an additional opcode, for the precompile. And it's primarily used in the smart contract layer, as opposed to the signature itself from the EOA. Is that correct? 16:28codeaholicIt's both. Like, you'll need both. 16:31IstoraOkay.

16:32The ML-DSA precompile: where the code goes

16:32codeaholicYeah, in order… your app will have to… like, the smart contract itself will need the reference, and then the application logic that performs the signing between the wallet and the smart contract, that will also need some code added. To facilitate, like, a bit more of an intelligent sign-up process in the smart contract. Where we incorporate, like, this… we basically incorporate an additional private key, ML-DSA, and it's, at a complexity size that is not even… not even a Shor-capable adversary will be able to overcome it. Computationally. So that's the entire… in a nutshell, that's basically what it does. But yeah, your application logic, and I have an example in the next slide, actually, on that point. like, this is… this is, well, personally, this is actually the smart contract code. I don't have an example yet of application logic, but I'll show you… I'll be able to show you that next… next session, next week, or two weeks from now. But basically, on the left, It's just a function, log in, and… this is before and after, so on the right, it's when the precompile is being made available and invoked. And I'm not really interested in showing you, like, the code itself specifically right now, beyond just to show you that from a additional, like, amount of context that you'll need to care about. 17:55IstoraIt's not. 17:55codeaholicgonna really be that bad from a code point of view to, you know, know where the precompile for ML-DSA-65 is, and then to invoke it, so the physical width of this is… comparable. So it's not gonna be much code. To… to really, once we make this available. If it passes the code reviews and all that, it's not going to be that much code on your smart contracts to use this. 18:23IstoraBut just to be clear, this… so we have the… the EOA is still using… the existing signature scheme, in terms of the… what transaction you broadcast. And then you also have this off-chain computation that you include as a parameter when you're calling that transaction. That is invalidated in the contract. Okay. 18:49codeaholicYes, according to ML-DSA-65, but yeah, that's the right way, in a nutshell. This is not yet changing anything on the wallet side. It just changes the extent to which your smart contract will begin to have notions of, like, digests and, like, authorizations for actions, with… with that additional Shor-resistant, quantum-Shor-resistant. Complexity added as an additional private key. 19:18IstoraOkay. 19:19codeaholicBut in your smart contract, or, not smart contract, in your application logic. You'll just need to add a little bit more back and forth in your sign-up flow, and then you'll need to enable, Like, disaster recovery, in case the user loses their private key. But the thing is, though, that this is… this is a pretty… like, it's not that complicated, so in next session, which I guess is bringing me to the announcements of what I wanted to talk in the next session. I will be able to… I will be able to show, like, very succinctly with… I'll have a preference towards just linking people to GitHub for example code, but basically I'll show an example where for my own application's login flow, because that's the only one I have. You'll be able to see what it means to set up, like, additional handling of the additional private key, but… and then I also want to show you the, local testnet results for the precompile's behavior and performance. So I'm gonna test that with a demo smart contract, and also my production… my own production. LogTrees smart contract, which I make use of. That way, like, it'll be two examples of how to… like, does the precompile affect anything, or what is… what is the gas, what are the gas results, things like this. Mordor testnet plan, I think it's gonna probably be a bit more involved to… based on the reading I did on that to get anything like that scheduled, so I just leave that up to whatever is the most organic process when we get there, but next session will be some code review. I want to be able to post these results, at least from the local testnet. onto the PR. And be able to show you those, too. But, as far as the code goes on the draft PR, you'll notice in the last couple days, I've been pushing some cleanup commits. And, one of the next steps for me is to… excuse me… One of the next steps for me is to just run things on the… still on the testnet, but just locally, so not deployed to Mordor, which is a more involved step. And then, I'll also be able to dive more into the ML-DSA and Shor's algorithm as well, next session, if anybody's interested, but… Yeah, I think… more code, basically. And… what I can say, though, is that, like, this… there is… there's also, like, a Falcon. option, but it's not yet… there's no, like, actual standard that's been approved on that yet by the NIST. Whereas for ML-DSA-65, one of the… one of the things I added was a couple unit tests that actually use live examples of scenarios from… the NIST themselves for, KATs, like, known answer tests. And, for known, like, real scenarios or valuable scenarios, and I'm able to test so far that… it's working according to, like, all of that specification, which is nice, so Falcon doesn't have that yet. As far as I know from when I last checked. But, I'll also do, like, a deeper dive of the comparison, between the different options, but so far, this is… this is… when I noticed, oh yeah, and also I forgot to mention, this also helps not just users of applications, but also admins of smart contracts, because one of the common guidances, and I'm not gonna debate, like, I don't have a preference or opinion on if it's a good guidance or not, but one of the guidances is, out there is about, like, not retaining or retaining admin control of smart contracts. Obviously, that depends on what is the business logic inside of a smart contract. But, with this implementation, with ML-DSA, you will be able to more safely retain smart admin, smart contract admin functionality, which I know for some… like, application concepts, especially the ones that have to be long-lasting, you'll definitely want to have admin capabilities for things like upgrading your smart contracts or disaster purposes. So this'll take away one compelling reason why in the next, like, 5 years or so. if you have a very bespoke admin infrastructure, it would be, like, completely at risk because of stuff like this. So, yeah, I think it's good to be talking about it, but yeah, you can see… you can see… you can run… you can run the tests yourself on your machine if you want to see that things are, so far, compiling and running, and for next session, I will… I will certainly have, like, local testnet results, and at least the plan for what… what it means to get this to Mordor. I think that was a bit longer than I was planning, but… 24:15IstoraNo, that's, that's really good. 24:16codeaholicLet me share.

24:17Deriving the new key and choosing ML-DSA

24:17IstoraYeah, thank you for that. That's, Yeah, super valuable stuff, and I'm glad we're… addressing this topic now, and I think that the approach you have is, a good… first step in trying to solve that problem. I had a few questions. One is, how do you derive the the account for this new signature. 24:50codeaholicHow do you derive the account for the new signature? Oh, 24:54IstoraThat's the private key. 24:56codeaholicIt'll just be on device, so this will be up to the app implementation. Like, each app is gonna do it differently, but for me, the way that I currently do it is… It's purely on the device, because I already generate something like this for, like a LogTrees ID. But it never leaves the device, it's always on device, so that's how I'm… approaching the implementation. But that's a good question, I'll have more details when I… I'll show, like, a… prototype implementation, hopefully by then. 25:26IstoraOkay. I mean, I'm thinking, I'm guessing you can just use… if they are using BIP39, they could just generate a new derivation. From the same seed, so that at least the private… like, the seed phrase can remain the same, but they can just use a different path to generate this, quantum secure key. Or are you considering that it would be… generated on a… completely different layer. 25:57codeaholicWell, that's a good question. I don't know that it'll matter very much for my use case, like, to care that much, because I mean, you could just call… you could just invoke the function and store things to the session on the device, and… Depending on your application, that might be good enough, so… This'll be, like, a… it depends on the app… how the app chooses to implement it, like, how strict or, like. paranoid you want to be, I guess? 26:27IstoraBecause you… I think you mentioned at some point, the issue of potentially losing the keys or the wallet? 26:34codeaholicYeah, because if it's on device, like how I do it now, that's one risk, but for me… for me, I don't actually care about that, because I advise my users, not to ever have, like, any, like, more than probably, like, a dollar at most in one of your wallets for what I'm expecting people to use my application for, but… if somebody is, if somebody's implementing something that is… way more valuable. Per user, or, like, per… like, for whatever your user is storing there, then yeah, you would want to have way more investment into… that question, including, like, what happens if the user loses their… private key. In my case, it wouldn't be the end of the world, but yeah, it just depends on what is being implemented. 27:28IstoraCool. in terms of the… the algorithm you selected, ML-DSA, could you… is that basically the only option? Are there other options available, and… Apart from, like, the maturity. Is it… is there, like, a comparison between the signature size in terms of gas usage, etc? And… did you… Look into how this might affect the transaction throughput of the chain. Assuming that in the future, basically every transaction needs to be using this new scheme to be quantum secure. How would this affect the growth of the chain? And the transactions per. 28:16codeaholicOh man, that's… those are good questions, I think that's a lot of questions there, so can we go one by one? 28:22IstoraYeah, so… basically, the whole question is, why did you pick DSA? 28:28codeaholicOkay, yeah, so I did a comparison briefly with Falcon, but as I already mentioned, like, Falcon did not have a completed NIST like, standards body, as far as I remember, and the other one was that, I believe it was that ML-DSA is actually just, I have it in my notes, so I have to go find it, but yeah, I did a brief comparison. The biggest one for me was even… and I added it to the specification as well, but the biggest one for me was just that the NIST standard has to be, like, something that I can trust, and it is for ML-DSA-65. There are two other ML-DSAs as well. So, there's a stricter one, and then there's a… like, a more complex one, MLDSA85, and then a lower one, 70-something, I forgot. But the difference is, the one I picked is just the sweet spot. So at some point, we'll be able to implement all of them. In fact, that's one of the things that I… was planning to leave as a, like, let's do it together in one of the next sessions to just go through that. I think, like, as a code review, it would be, ironically, pretty interesting to just add the next precompile. But, Yeah, ML-DSA is pretty good as far as I know. It's, like, also provided by Cloudflare. Oh yeah, that was another big one. The implementation's actually provided by Cloudflare through their package called CIRCL, so… I myself am not implementing this algorithm. I just know that… I just know the signature for how it is intended to work, because it's provided out of the box. This is recommended. So, if we find that there's reasons, perhaps performance-related reasons, to ever want to roll one manually. That's a future conversation. I think part of your questions were asking, like, how does this affect the throughput of the transactions and all that? Right. Great question. We will, we don't have any measurement data on this, because that's the whole point of, Mordor at some point to be able to test the throughput of things and all that, but… so far, I have a couple indications, one of the indications is that based… I know unit tests are not actually good for this thing, but since two of the… two or… like, a couple of the tests are actually testing real NIST test cases. I think if there was, like, a real performance bottleneck, it would even get picked up on a unit test. I'll query this further, but… so far, like, even when I run the unit tests in benchmark mode, I didn't see a problem with it, but this is… this is just a very, very early test result. Conceptually, from the… from the fact that this is, like, a very… like, it's a lightweight, tiny amount of code that has to exist at some address, and what I saw was that this address range is already predefined for precompiles. So it's, like, a supported thing, and it's also effectively… going to be, like, a, a lot of it will also depend on, like, what your application is even doing, so there might not be a huge uptick in… PQ types of applications that really care, because maybe, you know, like, it's just gonna be dependent on what people implement with it, but maybe, maybe it'll be a possible outcome that the, throughput implications are very minimal because of the actual business need for this. So… I'm not really sure, like, beyond… wanting to test it in Mordor, so I'm gonna just test it in Mordor. I think that's where, historically, people are finding this kind of information, right? 32:00IstoraI'm thinking more about just the raw… transaction size, in terms of bytes, and what… 32:06codeaholicOh, I see. 32:07IstoraHow much… Yeah, yeah, when I say throughput, I mean, like. 32:13codeaholicmeasurements will be obtained for… 32:15IstoraAssuming there's a fixed block, size that's remaining at 8 million, that could change, but… yeah, I don't know how many transactions would be able to fit in a single block using, like, one of the bigger schemes, and how much that might cost in terms of gas for users. 32:33codeaholicAre you pretty familiar with this stuff? Because, what I was gonna do is just use, like, some baseline values, and then… just play around with different message sizes and see what happens, and then get performance metrics that way. So it's gonna be kind of like a laborious process, but if you already know about this stuff, then we should talk after. 32:50IstoraOkay, yeah, it'd be good to collaborate on this. One of the other reasons that I asked that question is because the… I've been listening to some of the Justin Drake quantum discussions, and what they're doing in ETH land. is… a little different, and I'm not suggesting we should follow them, because they have a completely different requirement set. Like, proof of stake requires different things. but… they… they've opted for a hash based approach, a hash-based algorithm, as opposed to a lattice-based one, which I believe that like, ML stands for something lattice, right? So… I don't fully understand this problem. Do you have any insights as to… What the difference is between these two, whether or not like, one of the benefits, as far as I understand, of having the hash-based thing is that you can aggregate signatures more easily. And that's, specifically for validating, kind of necessary for Ethereum. But not for Ethereum Classic, because we don't have validators. So… have you touched on this problem, and do you have any thoughts on that? 34:07codeaholicNo, I'm not a cryptographer, so, like, my knowledge on this is minimal, but, what I do know is that I think, realistically, like, they'll all be implemented, so it's really just a question of like, for example, what it… I think it requires more context than just, like, a very simple one is better than the other, generally, but in my case, ML-DSA is the only one that is, like, the fastest path to shipping something that can be iterated on. per proposed and good standard from, like, a final NIST standard. So I think since, like, that's the objective in this case, that's probably the… the winning move, but… Yeah, I think it's a good question for people who are, like, super into that, or, like, towards the review time, to see what, you know, I don't know what the historical… I think is this the first ever precompile that's been… drafted? For, no, no, there's been other ones, because I saw the unit tests. So yeah, I don't know, like, what the other precompiles that touched on… 35:12IstoraYeah, actually, I believe in this… in the upcoming… the next Ethereum classic hard fork. There's… there's an additional precompile for… the algorithm allows, I think, BBLZ signatures or something, but allows the passkey system to work, so it's… it would not be a novel implementation, or a novel. 35:33codeaholicThings. 35:34IstoraI also noticed that the… there is an upstream EIP-8051, which is precompile for ML-DSA, which is… 35:43codeaholicHmm. 35:44Istoraa similar idea, I guess. But this… 35:49codeaholicOh yeah, I saw that one. 35:51IstoraYep. So… this precompile is largely for… in the smart contract layer, and for… allowing people to opt in to… quantum secure transactions that interact with contracts, if I understand correctly. And it could potentially be then leveraged as part of the account abstraction, so you have, like, a wallet that then uses this precompile as an EOA, as an externally owned account. 36:24codeaholicCan I get the link to this one, or the number?

36:29Account abstraction and exposed EOAs

36:29Istorasorry, 8051 is the ML-DSA precompile. But this does not necessarily talk about the, account abstraction. thing, but if that was part of ETC, then this precompile could be used as a migration path to secure the EOAs. Instead of just having a raw signature. So this seems like a pathway that allows people to migrate to quantum secure addresses. using… ML-DSA. But it would… it would require those two pieces together to… ensure that the EOA is secure, as opposed to just in the smart contract layer, if I understand your proposal correctly. Right now, it's just introducing that additional check for smart contracts. Whereas, let's say I have, like, an ETC address from… pre-quantum signature days. I've already made a transaction, so my public key is on-chain. And… I am still not protected unless I do something, right? I need to make a transaction, I need to move my funds. Into… a contract that specifically protects it from that. Ideally, in the future, it could just be another externally-owned account that is quantum Secure. And with this precompile, you're introducing in this ECIP, plus… a minimal contract for that abstracted EOA, then I could be quantum secure. So… in this proposal, how… How can we think about the existing accounts, and the… ETC that's sitting on-chain that is currently exposed to potential quantum attacks. 38:41codeaholicThat's a great, very expensive question, and I think that's the objective of, like, probably 10 years of roadmap, hopefully, because it's interesting. But yeah, I think it's a good open question to keep thinking about. But I don't think we need the answer anytime, like, anytime very soon, thankfully. So… 38:57IstoraOkay. 38:58codeaholicOpen, open question for me, as I ponder. 39:01IstoraYeah. And I think having these, these precompiles are… are gonna be useful for various different things. In the smart contract layer, for sure. But I think, like, a full answer to the quantum threat is gonna require, like, something also low-level, so that individual accounts can be protected. So if the average user is making a transaction, they shouldn't necessarily have to, like, put their funds in this contract to ensure that it's protected. 39:35codeaholicYeah, I mean, once… once wallets exist, which… Don't have that problem at rest. If they do already, that's great. I don't know if they do or don't, but once they do, then the simplest solution is for people to just move things over manually. 39:52IstoraYup. I think, like, as far as I understand, because, like, the… the quantum Attacker, adversary, would need the private key. Essentially, in order for anyone on ETC to protect themselves, they simply need to move their funds to an address that has never been used before. Because that has a unique private key that has not been used. So… essentially… People can, at least in the interim. Simply move their funds once, and they are not going to be able to be attacked through quantum computer. And then the question is, how do you then spend funds? And then there's, like, two branching issues. One is the… Like, is it possible for a quantum computer to… Before a transaction is included in a block. Is it possible for a quantum computer to read the mempool. And then compute the signature, and then submit another transaction with a higher gas fee that replaces that transaction. So that's like a fast replay attack, if you like, of sorts. Using a quantum machine. And then the other is that, like, at-rest problem that I talked about just now, where the public key is available for a while, and a computer can just, like, crunch on it and derive the signature over the course of, like, 10 minutes or so. So both… both possibilities are threats. And the fast attack is… probably further in the future? And also, more dangerous one, that ideally, can be mitigated. And that means that, like, people that have made transactions like. For this fast attack to be a problem. there's… it has to be the case that people are not aware that it could happen, because they can simply just, like, not move their funds. Until there's a solution in place, like a new signature scheme, for example. So that one can be mitigated, but it's also… Something that… we… should solve, eventually, but it's less pressing. And the solution, I believe, that you have Proposed here is a solution for… that threat, as opposed to the at-rest issue. If I understand correctly. 42:26codeaholicYeah, I would say that you understood that correctly. Yeah, it's for… it's for the application logic, and… administrator… control over… Smart contract functions for use cases where a smart admin… a smart contract admin, like the person who deployed the smart contract, would not want to give up their, like, ownership role on the smart contract, so they can continue to invoke functionality. I think. They will be interested, but, also people that are, like, wanting to… if their users get compromised. In their finances, like, for somebody to… you know, take their wallet, and then… transact away their Ethereum or something, at least to not have it be a double whammy where Like, that adversary can then screw up their very, very valuable data structures and smart contracts that they use, because the future state of all of this is going to be that people are going to be using very powerful applications that have to store constructs or data for, like, hundreds of years, or thousands of years, and it's going to be very meaningful Solidity. memory objects, and you don't want those to get corrupted just because your wallet gets stolen, because those are two separate events, right? Like, if you're breached in this way, at rest. My solution doesn't help you with that, but my solution helps you with if you're a smart contract developer that has, like, very interesting data structures that are valuable to users, or if you're an admin, then it'll help you. 44:04IstoraOkay. So this is more the transient attack, where… 44:10codeaholicYeah. 44:11Istorayou're… you've made it… you're an admin, you've made a transaction. For the… even for the first time, you've been very… Diligent about not reusing the same address. And… this first new transaction gets intercepted by a quantum machine, and then basically, they crack your wallet, basically, at that point. And they must do it within the 10-second block time, or let's say 30 seconds a minute, because of ETC block length. or block size. does this… What one of the issues that I was thinking about from the research I did, and listening to Justin Drake, was that There's a possibility that these signatures become… outdated over time. And there might be a need to, like, migrate to different signature schemes. Is… I don't understand, ML-DSA? Is it something that is, like, a… One-time fix? Or is it something that… the system should be, like, designed to… be able to be upgraded over time.

45:32Signature agility and ossification

45:32codeaholicThat is a very… I think that is a very good question. I'm sure, like, many careers have been based on this question so far, because it's complicated, but… in some ways, yes, you'll be able to automate, like, upgrades, but… you will also still need to pay attention to the different ways that complexity can increase, because ultimately, it's increased complexity and attempts to control that complexity. Those are the two driving levers or forces that are… causing, you know, an adversary with a faster computer to crack the code again, and then somebody else with an even faster computer trying to make an uncrackable code, and… It's a virtuous cycle. Especially for the people who like gaming rigs, but the entire point, though, is that, yeah, I think even if… even if you can… like, for the next higher order thing to ML-DSA-65, or 87, or whatever, even if you can automate, like, that trajectory of, somebody trying to use a faster computer, there's gonna be other ways, you know, so… Still have to be… It's still gonna be a pretty manual… effort, I would think. But those are if it… 46:43IstoraYeah. 46:44codeaholicIt's just gonna all be automated delivery. 46:46IstoraThis… this is something that, like, for ETC specifically, because of the… there's another, like, political dimension to it, where… how do you get consensus on which signature schemes to upgrade, and how often do you want to do it? Do we try to reach ossification at some point? And are there solutions that are compatible with the ossification vision, as opposed to, like, trying to catch up with the latest signatures every time? That being said, like, I definitely think that Common signature schemes, like the one that you're proposing. Are useful… in multiple dimensions, for validating data. Not just on-chain, but, like, external systems, and, like, if this does become a standard that's used in many different systems, like, it's gonna be super useful to have this precompile anyway, just for validating signatures from things like… 47:43codeaholicHmm, I haven't considered that angle, but that's a very good point, like, post-processing of… 47:50IstoraYes. 47:50codeaholictransactions, you mean? That's really cool. Yeah, definitely. 47:54IstoraThere's this thing called, like, TLSNotary, which is being used for, like, validating Content on websites, so you could potentially create this zero-knowledge proof that a web page has a certain property. And if… every web page is switching to a quantum secure algorithm that potentially could be ML-DSA, then that could also be, like, a super useful Primitive for… Smart contracts, not just for being quantum secure, but also everyday… Cryptography, if you like. So yeah, I… I really appreciate you putting this proposal forward, and I think it's a serious proposal, and I think we… hopefully can get some… More data about how DSA… It's before ML-DSA is performing, and the trade-offs, and… 48:55codeaholicYeah, I will… 48:56IstoraAble to stop the discussion on this, so thank you. 48:59codeaholicYeah, thanks for having me, and I'll definitely… like, I'm super eager to obtain the research results for, for, like, the performance testing as well, so I'll be reaching out with some questions, probably, but if anybody has any other questions for me. you can reach me in the server, both servers, or the GitHub. Those are both good options right now, but, or DMs, too, is also good. But yeah, thank you for having me, and, pleasant conversation, as always.

49:31Why ETC is better positioned than Ethereum

49:31IstoraYes, indeed. Did anyone have any questions for codeaholic before I jump into some related topics? Okay, so I think… it would be cool now to try to explain why Ethereum Classic is in a much better position than Ethereum Mainnet, in terms of its, path to quantum hardening. And it's essentially, like, the proof-of-stake change the Ethereum implemented a few years ago, has put them in a position where they have a much more complicated system, and they have three different layers where they need to implement quantum hardening, whereas for Ethereum Classic, there's only one. And for us, for Ethereum Classic, it's a much simpler system, and therefore. There's less things to go wrong. And… that means that if there is a problem with Ethereum Mainnet, like Ethereum Classic and as the only non-proof of stake, Ethereum virtual machine. that's viable. It's, like, the largest proof-of-work chain. Quantum could actually be the best thing that happens to ETC, because the other chains might be… Like, it's unknown whether these problems are surmountable for them, whereas for us, it's, like, fairly contained. And… I'd like to do some research in the coming weeks about how many addresses exactly are exposed to the quantum problem, but even if Ethereum Classic does essentially nothing. I don't think it's going to be a big threat to it. because of. 51:06codeaholicYeah, that's… That's huge. That's a huge thing that, like, a lot of people haven't really thought about yet, I don't think, but there's a very interesting emergent property that I'm really excited about for my applications, or just the future of, these extremely, like, semantically rich data structures that will exist in the future, where users will care about them. Like, you can… you can call it a quantum permanence, is what I call it, but basically, if Ethereum Classic is indeed ahead of the curve on if it will really significantly or meaningfully be breachable in this way, then that's a… that's a huge thing that many other chains, or maybe, like, no other chain, can actually say. So, anybody who does care about building applications that are resistant in that way, where we are on the right side of the curve to have quantum permanent data structures. The only way you can do that, like, the way that we're doing it, is… by having access to the quantity that lets you program and ride. the… the stored value increasing. So then the tokenomics is just completely, like, obviously simple, like, to just say, like, I like the… the concept there. I'm not giving advice, but, like, I personally think it just makes a whole lot of sense to be optimistic about it from that point of view. But yeah, I just got on my little soapbox there about the tokenomics about it, because I think it's super interesting. 52:32IstoraAnd the quantum permanence concept, but that… First time I've heard of it, but I'm imagining that that means, like, in the future, all of the pre-quantum algorithms have to be assumed fakeable, and therefore untrustable. So, this permanent property is… adopted only by the post-quantum algorithms, right? 52:51codeaholicYes, and because it's tied to a proof-of-work ledger, that means that, the transactions are carrying actual work. then this is a, a physical… it's a physical ledger. Like, not unlike a book. But just, like, a book plus plus? 53:08IstoraSo… Yep. That ties… 53:10codeaholicto strongly be tethered to that from an information integrity standpoint or theory. We will be strongly tethered to that across the filter to be post-PQ. And when we're at that point, then we can consider that what's tethered to it is… has the… that property of quantum permanency. 53:30IstoraYeah, that's one of the things I picked up from the research I did. That being that… Proof of work is already quantum secure, because you can't just reverse a hash. easily. It's, it's, you need the public key, and therefore all those, like, SHA-256, or in the case of ETC, SHA-3, like… hashing is not reversible by a quantum machine. So… the consensus layer, the proof-of-work layer, is totally secure, we don't need to do anything, we don't need to worry about it. Whereas in Ethereum, they don't have that luxury. Also, on the data layer of Ethereum, they're using KZG commitments, which are also not quantum secure, so the blob data availability, which I believe is used for some kind of exotic scaling and danksharding, which I'm not familiar with, because I don't study Ethereum, but… they kind of are locked into this paradigm, and they're gonna have to completely replace 3 layers of the stack, which is basically the whole stack for Ethereum. And they're gonna have to do it in the next less than a decade? And… That's a larger job than the switch to proof of stake, most likely. So… they have, like, a really big challenge ahead of themselves, and it's not guaranteed that any of these things are actually gonna… be viable. Like, in any frontier coding project, like, who knows whether these solutions are gonna stand the test of actual deployment, and… There's big concerns about, like. scalability? Like, can you get these properties, but also have 10,000 validators all doing the same thing at the same time? And can it be done in a decentralized way? So… Yeah, it seems like the approach ETC has taken to move slowly and don't break things, and not add on, pile on complexity. Might be the saving grace that allows it to continue for a long time, as predicted. 55:37codeaholicIt's a good time to be… Really, into this stuff. So I'm a huge optimist. I think that this is all, like, yes, yes, it's all possible, like you said. So… if you can build it, then it should be a lot of fun ahead. 55:52IstoraYeah, yeah. And few people are aware of this. It's, like, really, frontier stuff, and the Ethereum people are not even paying attention to proof of work anymore, so… we're in this, like, really. 56:03codeaholicThey really… it really should. 56:04IstoraNo. 56:05codeaholicBut I, I. 56:06IstoraYeah, I've. 56:06codeaholicas well, like, I like… I think the hybrid nature to it, the fact that I give the benefits of both for the same smart contract, especially as your smart contracts increase in complexity and you have to think about upgrading them. Which is a thing in itself, like… Yes. It's gonna… it's gonna be worth, you know, but… Yep. 56:25IstoraI actually think there could be, like, some… very… interesting alliances forming between ETC and Ethereum Mainnet. whereby… we kind of anchor the security of their chain. To the physical world. And using some kind of bridge, or… zero knowledge proof, or EVM storage proof. Like, thank you. what they want. Yep. They can do what they want on their chain. But they kind of pay us for that security. 56:55codeaholicYeah, you would love Elysium. Like, one thing I want to talk about, but I'll save it for next time, because I already talked about the quantum stuff, is Elysium, Olympia, Bastion, and I wanted to show you guys another thing that I have to sweeten the deal with Elysium. To precisely make that aspect better. Because it's just so cool, right? Like, Ethereum and Ethereum Classic. like I said, it's a hybrid, but yet you still have the same smart contract to deploy, and at least for me, because my smart contracts are simple, it was actually literally just push the button, and that's it. 57:29IstoraCool. Yeah, and it would not just be Ethereum, but every other EVM chain that's currently proof of stake, which is all of them. So basically, imagine a future where ETC is the base chain. because it's EVM compatible, every other… 57:43codeaholicThat's amazing. 57:43IstoraEVM chain anchors it to this chain. 57:46codeaholicThat's my… that's exactly my architecture for LogTrees. For that aspect. But yes, it's extremely, it's extremely powerful, and it plays into the whole, how can all of these be meaningfully ahead of the curve on quantum stuff? Well, it's thanks to the Ethereum Classic in that way, that it's literally the physical backbone in a big way because of proof-of-work. Despite it still being ERC20 and Solidity compatible, like, to the same extent, so… Super interesting machinery. 58:17IstoraYeah, this is, this is quite a compelling vision for the future, I think, for ETC, and you heard it here first. I think we can actually, put our… put our heads together. I'll try to think how we can make this work, because… Even if it's not, a primary solution for the other EVMs. At least it's like a fallback option. And they should still consider, like, helping ETC, funding ETC, like, we can work together to try and implement something that as a standard that other EVM chains can anchor to. So, yeah, we're coming up to the hour. It's been a really fascinating discussion, and I'm really glad we had this. Thank you, Codeaholic, for presenting, and… I'm looking forward to continuing the discussion on this topic, and… looking forward to the, continued research on ML-DSA and other quantum-related solutions. There are some more things that we could potentially leave for other calls. That includes proof of seed phrase. And it includes some of the other Like, commit-reveal potential solutions to quantum transactions. But since we're coming up to the hour, I think now is a good time to tie things up, and… I will… just mentioned that their next call, I believe. is… yeah, in 2 weeks, so… probably, same time, same place. There might be a change to that, so stay tuned, but I'll be posting updates in the Discord if there is a change. But apart from that, Unless there's anything else, people in the chat would like to talk about, I will wrap things up. 1:00:09codeaholicNope, have a good one. See you next time. 1:00:11IstoraOkay, thanks everyone for joining. Take care. Have a good one. 1:00:18LunarCheers, guys? See you? 1:00:21IstoraCheers, bye-bye.