Summary of Developer AMA #1: March 5th

The ETC Labs Core team hosted an AMA this last week, answering all community questions about the current state of ETC and what the team is focusing on in the future. The 1 hour discussion covered a wide range of topics, including the new team, ETC initiatives like Pristine, collaboration with ETH, ECLIPS proposal processes, and what we need to do to keep ETC competitive.

The entire discussion was hosted on the team’s Discord server and has been recorded and posted here

Below is a recap and summary of some of the topics

Q: I see some new people on Discord labeled as “Dev”. Has the team grown? How big is the development team?

The two newest additions to the team are Alan Li and Zac Mitton from Consensys. We’ve got a total of 10 full time developers and plenty of part-time contirbutors aswell. We are definitely going to keep growing and wont be staying at this size for very long so please reach out if you are interested in joining us!

Q: What solutions are there for the 51% attack? What do you suggest miners can do to help out? What role will ASICS play in mining moving forward?

First thing is to realize that there is no single solution, there are trade-offs in running a Proof-of-Work network and 51% attacks are always possible.

There is discussion of ASICs coming to ETC mining, and personally [Zac Mitton], that will help prevent 51% attacks. Today, it’s very easy for a single entity to ramp up and down since everything is using GPUs, but with ASICs you wont be able to do it suddenly like that. Another benefit is that hash power will be consistent since ASICS tend to be left on all day. If we move to ASICS, you wont see people just purchasing 100% of the hash power from NiceHash since the hardware wont be available.

ETC has so far been growing slowly but steadily, but the rate of upgrades will increase a lot moving forward. Node operators and miners will need to pay attention to that. There are alot of tools that are cataloguing events (made searchable through elastic search) and providing analysis of the chain that can help manage and predict potential attacks. We are also discussing defensive mining with a few ETC clubs.

All of this focuses on mitigating or preventing a certain kind of 51% attack. As Satoshi mentioned, you can’t get rid of all of the malicious actors, but identifying them will help alot. 51% attacks don’t destroy networks, they allow for double spending which mostly affects exchanges.

Another important step is we are in dire need of new op codes for a client upgrade and that is going to be on the horizon soon, so miners and node operators, please voice your self loudly!

Q:What’s ETClabs view and plans on accessibility of running full nodes? I think, currently, full nodes are able to blacklist accounts. Could you confirm if this is correct? Should full nodes be able to blacklist accounts? If yes, could you explain the reasoning and what it solves?

We definetly want full nodes to be more accesible and its something we are currently working on. Regarding blacklisting stuff, we cant do it in Geth, so we’re talking about RPC blacklisting. This was a concern brought up in the past, but we don’t think it’s relevant. This issue is more common for 3rd party hosted nodes, like Infura.

Q:What are the priorities right now?What will we see from the ETH 2.0 collaboration? Will it affect ETC’s competitiveness?

Our focus is currently on decentralization, backward compatibility, and community collaboration.

Our call included IOHK and ETCcoop as part of the discussion with ETH 2.0 We have borrowed from EIP in the past. We need to keep an open mind and share ideas, and that’s how open source collaboration works. There is only net positives in that. ETH 2.0 respected that we are “POW Ethereum” and they see that there are good ideas for us to discuss around our respective forks and our respective visions.

Q: Supposedly Byzantium and Constantinople upgrade can break the immutability of existing smart contracts. What do you guys think of this? My personal opinion is that we should not allow breaking any existing smart contracts if we are to be serious about immutability. Have you considered having versioned VMs as this seems to be the only case we can guarantee that programs can be built for the future?

Only opposition to it would be the technical overhead. Keeping old versions of Geth adds a whole lot of overhead to clients; i feel like it would be hard to convince everyone to do it even though its well intentioned. There are also a host of arguments around the definition of immutability. Adding new op codes creates an issue around previously undefined op codes now being used.

If you used an op code in a previous version that was undefined, that’s on you. Developers need to do the work to make sure their code is following procedure. We can’t preserve backawards compatibility on op codes if the recommendations aren’t followed.

Q:What is Pristine?

Pristine is an open source documentation guideline that promotes better documentation practices for the open source world. So the idea is the problem that you’re trying to solve is written down in repository before we even started. There are some pretty unbelievable examples of sloppy documentation already and we’re trying to prevent that moving forward.

Q:What is the reasoning behind ECLIPS — (Ethereum Classic Labs Improvement Proposal)

This allows everybody to contribute on their own terms and signal support for for proposals in their own ways as well. I guess what it comes down to is like we keep coming back to this idea that in order for it to be truly decentralized and in order for the network to be sufficiently decentralized there needs to be more than one client. We can all agree that if there was only one client then there would be only one group of people that you would have to lobby to or whatever to have a proposal. Everyone should be able to follow proposals and processes and and really the organization of where that’s coming from should be improved and should be agnostic

GitHub is owned by Microsoft and they just host specifications that do not directly effect the network. You have accepted specs but they don’t have to be adopted because it’s up to developers to implement them and so on. ECLIPs was prematurely discovered because it was a public repo but some in the broader community had negative assumptions long before we advertised it to anyone. What’s cool is ECLIPs is sparking discussion in the ecosystem about how we be inclusive of independent contributors instead of conforming to central organizations, I mean, people want to push code wherever they want. As far as scale, it’s good to have something that is inclusive of everyone else’s processes. Unless you have a gun to someone’s head, you can’t force people to push code here or there. This is a decentralized ecosystem after-all.

Reference Links for more information



You can read our Full Roadmap and Introduction here

Interested in getting more involved with ETC? We’re focused on accelerating the development of Ethereum Classic and need your help! Reach out to us to see how you can get more involved today!

Our team links: Github, Medium, Twitter

Come chat with us on Discord

Dean Pappas | Building Grape on Solana | Ex Marlin, Ethereum Classic, Zel, Taucoin | Ex GM at Zeta Global | Hearthstone and MTG