| name | date | time | location | length |
|---|---|---|---|---|
ETC Community Call 012 |
2022-02-08 |
1500 UTC |
Discord |
30-60+ mins |
A casual voice chat to discuss ideas for ETC. All are welcome.
The ETC Discord can be joined at https://ethereumclassic.org/discord
Please join us in the #community-calls channel ask questions or bring up topics.
This week, with special guest Afri, where we will discuss Hard Fork Coordination.
- Announcements
- Dev Call 22 Monday, February 21st, 2022, 17:00 UTC https://ethereumclassic.org/blog/2022-02-21-core-devs-call-22-ecip-1049-proposed-rejection
- Henry's Hybrid PoW whitepaper https://github.com/epicblockchain/whitepapers/blob/master/ETC/Hybrid_PoW/Hybrid_PoW_Strategy.md
- Preamble
- Afri Q&A
- ETCDAO Gigs https://github.com/ETCDAO/gigs
- Bridges vs Algo Stablecoins?
- Conference 2022?
- Uncle Rewards, Pool Centralization, Monetary Policy
- Open Discussion
- Completed
- Attendees: > 20
- Duration: 2 hours
- Recording: https://www.youtube.com/watch?v=GCBv1VCN2tE
The meeting was joined by Mr. Afri to discuss hard-fork coordination and various other related topics. Most of the time was allocated to Q&A session held with Mr. Afri. Mr. Afri shared his experience/ knowledge about the goal of hard fork coordination, the factors involved in hard fork coordination and his long lasting relation with blockchain/ Web-3 and ETC. Along with that, he shed light on the things that can go wrong while transitioning to a new fork. He also briefed the participants about the mitigation techniques. Responding to various questions, he explained the network monitoring tools and proposed measures to be taken when there is a chain split. In addition to that, he spelled out the kinds of chain splits, the ways to resolve things when the hard fork results in a chain split and the post scenario of a permanent chain split. He highlighted the role of Hard Fork Coordinators to act as a trusted point of contact and also shared his prospective on multiple client implementations. At the end, he shared his thoughts on the current state of ETC and addressed the question as how the things will go in case of merger of Ethereum. After the Q&A session, the issues like ETCDAO Gigs and Uncle Rewards were discussed in the meeting. However, no significant action was taken on these two points.
- The participants are requested to peruse Henry's Whitepaper so that meaningful discussion could be held on it in the next meeting.
- Veterans like Afri may be invited in the Weekly Calls as and when possible for benefiting from their experience.
- One or two proposals on ETCDAO Gig may be submitted within a week so that we may start testing out our system.
(1). There would be a dev call on the 21st of February at 1 500 UTC to ponder over the proposal to reject ECIP 104.9 and that would be to reject the SHA-3 proposal. Those who are interested can join the debate through the link in the discord.
(2). There will be discussion on the paper submitted by Henry. He has come up with the proposal to do a hybrid proof-of-work transition using SHA-3 instead of an immediate switchover to some kind of phase transition. You can peruse the Paper through the link given in the Agenda Item.
-
Upcoming Mystique Hard Fork is coming on 13th Feb.
-
Currently ETC Coop has taken charge of this fork including coordination/outreach, you can follow bob's twitter.
-
ETC will likely be experiencing hard forks for many years to come, so we wanted to "open source" some of the knowledge that has been accumulated over the years by speaking to a qualified hard fork coordinator, in the hopes that it can help ensure future forks go smoothly
-
We are pleased to be joined by one of the most experienced and qualified coordinators out there, Afri, who is veteran and prolific caretaker of various blockchains and testnets. Afri has previously helped coordinated forks on ETC, such as Agharta etc.
After the Q&A session, the Chair opened the discussion for ETCDAO Gig. The participants were apprised that an MVP product related to ETC DAO has been launched. It is in a very beta stage at the moment but, with the passage of time, it will evolve into a grants system or funding platform type. Currently, it is just a Github repo at github.com etc gigs. It will grow and then will be used as a testing ground for how we might be able to raise funds and allocate funds via various different DAOs that are running in ETC. It can be built like a business to create positive revenue. We can have a protocol to start building little gigs that generate more funds to build more little gigs and fun more gigs. We can learn a lot from Monero in this regard. The chair requested for submission of one or two proposals in the next week so that we may start testing out the system.
Werner informed that Uncle Rewards were brought up by Mr. Crazy who is still on vacation. Explaining the term "Uncle", he stated that an uncle is a block that that is correct and that passes all the controls but does not make it into the longest chain. Instead, some other block makes ways and then future blocks can reference those uncles .There was this other block that was submitted but it was not there to be part of the lowest chain but it would still like to acknowledge that this was a valid block and its content can be considered part of the blockchain. When you make such a reference, then the one making a block that contains such a reference gets a little reward and also the producer of the uncle block gets a reward. It is a relatively significant compensation you get for your uncles. So, they are not worth as much as blocks that move the chain for what they on the longitudinal direction but you still get something for making blocks. While in Classic you get very little and this means that any pool that has a lot of hash weight which is the especially the case around the field Classic where even mine is currently must be close to 50 percent and let me just check how much it has at the moment. At the moment, it has 50.46 percent, which means 7 percent of the global hash rate of Ethereum Classic. So, they are very close to fifty percent already and so this means that because they are so dominant they have a very good chance of being able to make consecutive blocks and cash and receive always the full block rewards while other pools only get well but have a much higher chance of getting only uncle rewards instead of full block rewards. So, this creates an unfairness between the poles which goes beyond the differences you would expect based on hash rate. So, it is basically a bonus for the biggest. It is sort of kind of the subsidiaries for the elites in a way. At the moment, it doesn't seem to happen to the full to the worst extent imaginable which would be the largest pool trying to actually suppress other pools by simply ignoring their blocks, then they could probably already be able to get away with this by just looking at their own blocks and ignoring all others. Eventually, well no other pool could keep up with them and it is unlikely that they all would agree on the understanding of the same competing chain and then they could basically make all the other pools unprofitable. We do not see this happen so that is good that they are not doing anything actively agnostic but still we can see that there are benefits from the synergy effect and this might get worse over time and of course one big issue with having such a massive pool concentration is that the pool diversity system drops so you have less diversity in the software higher risk but you create a single point of failure and it will cross.It will also make the pool more attractive for attacks. The idea is to improve the uncle rewards to make things more attractive for smaller pools and to reduce the risk of an unintentional boosts basically to a very large pool so that the minor distribution would be a bit more even so that we do not get one dominant pool and that could then cause all kinds of centralization issues.
The Q&A session held with Mr. Afri is being reproduced verbatim as under for perusal and record:
Question No 1 : Who is Afri and how has he been involved with blockchain-3 and ETC?
Answer : I am a long-term member of the crypto community. When I found out about Bitcoin, I was really excited. I think I would say I got into the space by mining. I really found it so interesting that you could come so like Satoshi's vision that one CPU is one vote. I mean this does not necessarily hold through today but it was just something that fascinated me about Bitcoin and in the early days, I had really fun just assembling mining with like assembling GPUS and mining not Bitcoin necessarily but like a lot of Altcoin in the back in the day like litecoin and other interesting experiments .And for me, it was really interesting both from a technical perspective, I am an engineer by degrees so I really enjoy the technicalities around us. I was intrigued by the potential impact this could have on us for the financial system or in society in general. So, eventually I came across Classic very early when I read the white paper by Vitalik Buterin and tried to test writing my first smart contract in 2015 which was a complete mess, but eventually I was sucked into Ethereum in first place because it was so interesting to see that you have this entire potential unlocked by a programmable virtual machine, and as I said I am an engineer, I am naturally curious about these technical aspects and I have been a long-term member of this Classic community. I was hard fork coordinator for both Ethereum and Ethereum Classic. This is how the story began.
Question No 2 : What would you say is the goal of hard-fork coordination?
Answer : Hard fork coordination is technically nothing. It is basically the same thing as the traditional software engineering project management. You have to coordinate a group of people to reach a common goal and eventually in the specification to hit a certain deadline of delivering the various pieces of software towards certain deadlines that need to be met, because in this case it is very interesting with all these aspects around consensus between different clients, teams and themes that might work on applications or tests or whatever else involved. So, the heart for coordination is basically just a new application of a traditional software engineering profession and it is a lot around orchestrating engineers, doing a lot of QA but also doing a lot of project management around timing estimating and all these kind of things.
Question No 3 : In the process of coordinating hard fork what are the things that you are trying to avoid happen ?I guess there are a number of potential things that you could say that this hard fork didn't go well. So, what might those be and how do you try and avoid them typically?
Answer: That is an interesting question. So, a hard fork is not really strict. There is no strong definition of this term. But, I think we can all agree that that this is a set of changes applied to a consensus system such as a blockchain protocol that introduces breaking changes. So, the ultimate goal of a hard fork coordinator should be, first of all, to convince or not convince but help the community to find consensus on such an upgrade not only on a technical level but also on a community level. Because there needs to be rough consensus to move forward if the community is not aligned on a hard fork then it might not happen or you risk a chain split if the community goes in different directions or creates different tribes with different opinions and a hard fork coordination basically assists community in finding the path to rough consensus and this is both important on logical level or on community level but also on technical level. The risk here is as to answer your question is that there are many facets to it. It could happen that the community does not care about an upgrade and just does not upgrade at all so you have to take ready but miners keep running the old software they don't upgrade. Another risk is that like only a small amount of miners or other network operators upgrade and then you risk a chain split because you have two different protocol versions and the worst case is obviously that you have if you have different protocol implementations that you have consensus issues that only reveal on the main net activation and this needs to be carefully prevented and prepared and that is all what hard fork coordination is about planning, testing and iterating both on technical but also on community and communications level.
Question No 4 : So a lot of things can go wrong and I guess especially when operating with a live test net. Some of these issues are not going to be apparent even in testing and it is only like an economically incentivized real world use case that some of the problems might emerge?
Answer : Totally this is always a risk and that is why we have so many different test nets in the first place. So, usually the process is that the engineers test everything in private. I do not know under development or feature branches and eventually when they believe in you know software development is never final but in the end, if you believe that your feature is ready, then you will test and talk to the other client teams and then you create private test nets and you test different implementations of the same thing against each other and even then you just grow confident that your code is working and that the other team's code is also working. Eventually, you can approach community and try to schedule these features on test nets and even on test nets, you do not have the same utility as on the main net and you can really try to stress test everything on test net, and even on extremely heavily used test nets such as the old modern Classic test net even such as assume foundations Robson test net, you still can miss certain edge cases and there is always a small risk that the day you activate a feature on main net you miss something and it eventually will trigger only on maintenance and break main net consensus which would be the worst case or the biggest failed of hard-fork coordination in that regard.
Question No 5 : In terms of the actual like fork block arriving on main net what kind of tooling and monitoring systems would a hard fork coordinator typically utilize to ensure that things are going smoothly and how would you detect any anomalies that you were not expecting?
Answer : So, in an actual hard fork different parties involved so the hard fork coordinator as a state it is kind of just orchestrating different involved parties so on the one hand you have the core developers that are basically let's assume for one moment we are talking about the test net and hard fork. So, in case the hard work activates on the coty or mortar test net, then developers could just basically look very closely or at their code or at their clients they run in certain debugging modes or monitoring modes. They try to actively break it by triggering the new features that are activated, but you also have other stakeholders and validators on the proof of authority networks. You have miners on proof of work networks and also these stakeholders need to carefully monitor what and how their nodes operate and as they operate correctly and what I do as a hard fork coordinator usually is that I get a number of bare metal machines and install it .I also try to install all existing protocol implementations, all clients in different configurations. So I usually have a pre-fork and a post fork configuration ready so that I can easily compare outputs of both clients, both versions of the protocol against the matrix of all clients. So, if you have three clients and two different network versions, you have basically a matrix of six different clients and versions and in the moment, the hard fork activates you can use different tools for monitoring what's going on. I personally use the so called fork monitor which is basically just a very tiny html page with some embedded javascript that queries an RPC end point and gets from all these different versions and clients the latest block information and compares a lot of metrics such as block height block cash block and total difficulty and so on. With all these little metrics if you put them all next to each other, you can easily spot any misbehaviors and if something is going wrong, you can immediately spot it. You can immediately talk to developers, ask questions. You can approach miners and so on and so I will leave the fork monitoring dashboard that is one of the most important tools, but there are also other tools that I use mining pool software to run my own miners I use the start of dashboards .These are also called ethernet network startups dashboards where you can get a more wide overview of the network status and there are some more smaller tools you could use.
Question No 6: I see on top of this you are not just monitoring the network but also potentially reaching out to different stakeholders that might include exchanges and wallet operators for example and I guess depending on the type of problem with the fork would depend on who needs to update that client or who is behind on the old network and it seems like you need to be able to contact basically any major player that has not updated properly or needs to push an update and that requires some level of a central point of contact that are somewhat trusted by these other counterparties?
Answer : Yes, in a way this role of hard-fork coordination is a very crucial that needs to be very carefully executed because you are not a hard fork manager, you are not a chief hard fork executor but it needs to be very clearly communicated as that coordination is a process of management without authority or without hierarchy because the fact that you hold a lot of strings in your hands and try to tie them together does not necessarily mean you are in a position of power and you should also not try to become a position of power. So, with that said, I would say you still if you execute this correctly then you come in a position where people trust you and they understand that if you are working for a certain client team or for the econ Classic community in this regard that people accept your kind of authority when you reach out to them and inform them about certain upgrades in future.
Question No 7 : I see in the example of there being some kind of problem with a chain split what would it look like from the hard fork coordinators perspective to try and fix things like if they need to send a message to an exchange to get them to update for example would that be done by the coordinator themselves or by some other would they be asking the client team to request that or who is pushing messages around?
Answer : So I mean we need to differentiate here that there are two different types of communication. So, one is prior to support and the other is post four communications and the communications leading up towards the hard fork are much more relaxed because you still have time to prepare people to upgrade their notes and this is a process that can be fairly decentralized anyone from the community can reach out to coinbase to assume Classic pools, or they can look up network statistics which are the biggest pools which are the most important they can individually reach out they can just share like common resources from the ecips repository or news items just to prove that there is something going on that pooled or other infrastructure providers needs to be aware of this changes a lot in the event of emergency. So, let us assume the hard fork goes wrong we have a consensus issue between two client implementations or something else goes wrong not enough miners upgraded and I do not know the clients try to reorganize to the wrong chain. It is like a complete mess in this regard then the hard fork coordinator has a certain responsibility to orchestrate people or like to delegate people to directly identify the issue as soon as possible. To reach out to involved parties as soon as possible, it is not necessarily the role of the hard fork coordinator to also reach out personally. It has been done a lot of outreach just because when you have this responsibility that everything goes right and nothing goes wrong and you kind of want to have perhaps on all the involved stakeholders. So, it naturally evolves this way that you start also doing the outreach but I would carefully say that it is not necessarily the job of the hard fork coordinator and specifically in decentralized communities anyone could technically do it.
Question No 8: I see I guess one of the challenges that decentralized networks face in particular is the ongoing managing of these books and maintaining some level of trust in a system that can be decentralized enough but also not so decentralized that you know anyone could just like tell any exchange to use this version of the hardware, sorry this version of the software or this version and that could itself cause issues and the other issue I suppose is sometimes exchangers probably do not want to give out their sort of private battle stations and communications channels to anyone. So doing it in a completely in decentralized way seems like it is very challenging going forward. Do you have any ideas of how like what the boundaries are in terms of how decentralized it could be going forward and how like this could be coordinated in a in a sort of standardized way going forward?
Answer : It is not really that it has always been a pain point to reach out to exchanges especially the ones that are not the major players, but this not just the entire, not the very small ones, but like maybe the medium-sized ones. Some are like really difficult to reach the only way you can really find out how to contact them is basically just creating a support ticket on their zendesk, and it is like really annoying and you get like one support employee that tells you that nothing is wrong and their system is fully operational and then you roll your eyes and say no that is not my point and but I am not coming with a recipe for this. I know that in the past both ETC labs and ETC cooperate, if they were facilitating strong ties towards certain infrastructure providers or exchanges they used just through established business connections contacts, but also through other official channels and I know that I do not know. For example, he maintains a long list of contacts which is well around for these cases and there is really a good recipe. Ecosystem is changing so fast with each and every hard fork that you have to like basically start all over and find out who are the biggest exchanges with regard to volume. So, when I say the biggest unit is important because how much money is at risk who are the biggest miners with regard to network sure. So, how this is important because the more hatch rate you have on the right side of the consensus the better your hard fork will execute or the more smooth, the builder hard work be and this is basically each and every hard fork you have to basically reiterate your list and check, and these players still do you have contacts, do you know anyone worst contact, and still I would hold my point that this is still the processes can be decentralized, because in a large community many people know many more people and you can basically facilitate these contacts and keep them alive, but then again there is no cookbook for this situation. There is no definite guide to upgrading a protocol with regard to communications.
Question No 9: Right, very interesting in the case of a let us say ,it is a temporary chain split because of some client incompatibility, are there any heuristics that are like go-to that you can use to say this side is wrong and they need to upgrade versus the other side like if two clients have the same version and you are not really sure which one is misbehaving like how do you decide which chain to follow in the case of a chain split like that, or is that not really a problem?
Answer : I would not rule this out it certainly is something is always a problem if something goes wrong, how fast can you identify the issue, how fast can you identify rules responsible not in term of head but in term of which line of code is responsible. How fast can the developers fix it patch it releases and announces it, and I would carefully argue this is something where the core developers are really. This is one of the biggest responsibilities during hard forks that might go wrong that they need to be very quick in identifying what the issue is and then based on that you can make calls but I would never make a call without knowing what is going on or what could be wrong. So, it is in most cases you can fairly and quickly find out which of the clients or which of the versions of the client or which parts of the code base misbehave and once you have identified that you can make pre-announcements. Once it is patched and released you can make announcements to to act upon that is but I would say it is a really a huge responsibility on core developers in such a really tough situation to quickly identify these issues and make the calls.
Question No 10 : Let us see this kind of ties in the debate slash conversation about client diversity and whether or not having multiple clients is worth the benefit of these potential problems. When would it be better to have a system closer to Bitcoin where there is a single source of truth in terms of the client, the reference client and then other clients can support it, but if ever there is a consensus issue then it always defaults to one client and they don't have to maintain multiple channels to different core devs, do you have thoughts on the client diversity issue?
Answer : Yes, totally I mean this is just the answer to this question is highly opinionated and I know that there is a Bitcoin way with just one implementation and there is an assumed way with as many implementations as possible and I do not know what is your opinion on that I would say I have been kind of slowly growing into this Humidism Classic ecosystem and I have been working at parity technologies with Gavin wood for several years and he always said I do not know if you know what let me just quickly tell you a story about the parity Bitcoin client. I do not know if anyone remembers or even knows about this Gavin Wood released a parity Bitcoin client I think in 2018 or in 2017 and this was the only client as far as I know back in the day that did not use this central Bitcoin consensus and he refused to use this consensus library published by the Bitcoin core developers and he was attacked heavily for doing this because they said he puts the network at risk. He puts consensus at risk by creating a secondary implementation of the consensus protocol but then again he defended anyone should be able to build their own implementation of this decentralized protocol because if there is a bug in the in the main or in the quote-unquote official implementation, how do you know if there is not an additional implementation and this is a technical aspect, but there is also the political aspect of protocol governments if you have only one implementation that is maybe controlled by only one entity. How do you ensure that this one entity does not abuse a position of power that just you need to literally change this implementation and this is now I can conclude my personal opinion is that the Ethereum assumed Classic way is the better one because by distributing this power of implementation to two three or more teams, ensures whenever anyone wants to make change to the consensus protocol it needs to go not to one place but to all teams and need to convince all teams or the community all together and I believe this is technically a risk I agree and I understand that Bitcoin believes in being technically more on a conservative secure side, but on the political side, I believe it is the strength of having multiple clients implementations for the sake of being more resistant. It is some kind of Meta decentralization you cannot just go to one client and hack it or even if there is a bug in one client you still have other clients that run the correct protocol and it is just I would argue that client diversity is a strength rather than a weakness.
Question No 11 : Yes, it is a very sort of esoteric topic and one that I think there are pros and cons to both sides of the argument and the additional complexity and coordination effort involved can definitely pay off in a lot of cases. I am still personally not really decided as to whether or not diversity without a single at least like clear defined thing is better I am still open to the debate really but hint is one I think that is extremely interesting nonetheless?
Answer : Totally, it is an interesting topic and we have different size of black blockchain ecosystems, I mean Bitcoin is a huge ecosystem assume maybe, it is a huge polka dot might become a huge ecosystem. I would carefully say that assume Classic is more like a medium-sized ecosystem they still have this the strength or the ability to maintain more than one client implementation, but again you can look at all these smaller ecosystems you name it you just scroll down a coin market cap and they only have one implementation and you never know there is a bug in their code. Do they even test, do they even have the ability to test this again, do they have any specification, how do they know that there is a bug and if there is a bug this is part of the protocol now because once a bug is included in a block on a public blockchain, most blockchains would not re-roll a royal back you know and therefore I would say it is very good for issuing Classic to still have this feature of having at least two clients that can be taking on each other. So, I would say it is one of some more major blockchain ecosystems out there.
Question No 12 : Right and I believe that very client diversity has in the past saved Ethereum Classic I think back in Shanghai spurious dragon hard fork right there was a bug in one of the clients that would have caused a major network problem but luckily parity did not have that bug so at least part of the net was able to continue?
Answer: Exactly.
Question No 13 : Okay, so moving on to the topic of I guess the current state of affairs with regards to ETC and what you think having spent a good number of years in the ETC ecosystem of recent events that you know the treasury debate. I am not sure if you've been following the shah 3 but what's your general sort of impression of where ETC is right now?
Answer : That is a tough question I mean is serum Classic is moving very slowly and again this is something you can discuss about this is a feature actually is it like doing the Bitcoin way just rather not move at all before breaking things or could there be more accelerated development towards building out the ecosystem being more developer or application friendly. I do not know I would carefully say esteem Classic has always been in this risk area between these two things and always been in this risk to be not strong enough to be relevant for application developers but also not fast enough to make a difference. So, it is difficult to say but it was also a very broad question so maybe you can talk about certain aspects of what's going on right now in the past.
Question No 14 : Let us put it this way what was it about Ethereum Classic that drew you to it in the first place, and why are we even working on a Classic at all?
Answer : I mean I have been in Classic from the beginning and I have been very close to the Robin Hood group I have never acted upon it, but I have been in touch with them for a long time and I have always been making jokes about how to explain your tax advisor that you not only have one issue but two issues now and I have been always following along and eventually when this card development team kind of imploded due to actions I do not want to comment on right now. It was basically a matter of how can is sum Classic be saved and be moved forward and this was when I realized that I actually have a set of ideas that could improve the network or the net the protocol and eventually stepped up to join edc labs and assist the ECIP editors with hardware coordination and we executed a series of protocol upgrades that brought issue Classic to the point where it is today and I think the most important feature of issuing Classic is as of today protocol parity was with other networks which is really not to underestimate because all tooling solidity everything if you everywhere to have a different version of the evm on Ethereum Classic.It would be a huge mess and we would have to provide our own tooling for developers and this is something I would argue is the biggest benefit of using a swim Classic today and i would say I am partially proud that I could assist Ethereum Classic do it over the last years in getting there and sticking there and yes I think it was also great to meet many people of the issuing Classic community in Vancouver at the ETC summit and there was so much energy, so much good energy and so many people building and moving forward it was a great time.
Question No 15 : Yes, I agree to everything you have said there and for sure the tooling point is on point I really do believe that a lot of the innovation happening on Ethereum, is inherited only because of that fact and the compatibility is super important to maintain but this kind of leads into the next question and the next like obvious big thing on the horizon that is not specifically on ETC but massively affects. It is the merge on Ethereum main net and how do you think well first of all is it going to happen and if it does, do you think miners are going to try and mine the old chain and continue like Ethereum main net version one and if not are they going to come to ETC and if they do does that pose a problem for atc or is it a benefit in your in your eyes?
Answer : yes, that are many questions.So, first of all, I am a miner by heart so I love just how slower miners does not matter. I love this feature of proof of work that anyone can be part of the consensus of the protocol and that is why I believe proof of work is a great way of consensus. I was once going to a museum here in Berlin, they had I think a small programmable calculator that was mining Bitcoin blocks and printing them out on a small piece of paper. So it is literally putting every hash on paper and it was so slow that it was ridiculous to watch but then again is not it amazing that even a small calculator could I know it is not practical, but it is theoretically possible that this calculate their minds a Bitcoin block that just has this potential here and this is something that you entirely lose with proof of stake. There is nothing like this in proof of stake and it is an entire paradigm shift that is just not an easy move when I understand that many people call for example for Bitcoin to also move to proof of stake and then this entire energy consumption debate that everyone hates so much kicks off again but then again ask yourself what is the alternative and I believe proof of stake is not a good replacement for proof of work in terms of their features it gives you and to your question with regard is the Ethereum would totally happen because there I have been contributing to some of the issues to work in the last two years and I am a kind of stopped contributing because it was such a difficult development environment. People are like very competitive you can feel that there is a huge pressure on Ethereum to deliver proof of stake because it has been promised since I do not know six years, because this repeated Bitcoin energy consumption or eco energy consumption debate they just want to ship it no matter what it costs and it will happen. I cannot tell when it will definitely happen and I have mixed feelings about this and with regards to will miners continue mining the proof of work chain. I do not think so for different reasons because the reason number one is that the difficulty bomb is still something that would have to be removed actively. So, this means in addition to the merge you would also have an active actively proposed hard fork to remove the difficulty bone bomb and in this because you have to actively propose it, you need to come up with a name you would have to call it estrogen Classic Classic or Ethereum Classic two or whatever and this is what people will not accept as real Ethereum or Ethereum Classic or issue Classic two or whatever you would call it and the other thing is that I believe that because this entire assumed ecosystem is so keen on delivering proof of stake and I do not know how many million have been deposited onto the beacon chain and already it is basically we are beyond that point of return and Ethereum will certainly move to the proof-of-stake consensus algorithm for sure. Whenever this will happen I do not know but I do not think there is any proof of work future in the Ethiopian foundation network and if these miners will actually move to ecom Classic this is something we will have to see but fact is that there are not so many proof-of-stake systems left and I am sorry, proof of work and Bitcoin is the biggest proof of work network and what comes next right now it is Ethereum but what will be the next one after Ethereum switches to proof of stake. We don't know there is a lot of hash rate that needs to be redistributed and we cannot really tell but if you scroll a coin market cap like by or coin whatever metrics you use most of the top coins are actually moving towards proof of stake and it does not leave many options for miners or mining hardware.
Question No 16: Right, I even heard that doge coin is planning a switch to prove a stake or something it is kind of surprising and yes, I would add that the whole defy ecosystem is basically the deciding factor I think in terms of where the value is going to shift and it seems like it is in their interest if they are holding either to go to staking I think a lot of them, seem to believe that they can reap the rewards of staking and get that value that miners would be providing so in terms of if there was an exodus of miners looking for other chains. This would mean there is a lot of hash rate going around as you mentioned and there are some people in the shah 3 debate they're saying that this is a very dangerous thing for Ethereum Classic because Ethereum Classic will no longer be profitable for most miners and the latent hash rate is just going to be used to 51 attack the chain, do you think that is a reasonable possibility or do you think they're more likely to just honestly mind the chain?
Answer : I mean to answer this question you need to speculate a lot I would argue that 51 percent attacks are very involved and it happened to assume Classic it happened to other chains. It will certainly happen in future again whenever someone believes the effort you put in there is worse the risks you are taking and the 51percent attack is much more complex than having 51 percent of the network hash rate is much more complex because you also need to have someone you can double spend on you need some smaller or mid-size exchange that you can execute these attacks on and this comes with a lot of work. So, I believe there is a fair amount of miners that just do not care as long as they get more coins out of it than they pay on electricity then they would rather mine honestly than go through this extra mile of preparing and executing a very risky 51percent attack right.
Question No 17 : Thanks for your perspective on that is good to add some additional viewpoints into this debate now we're nearing the end of the pre-planned questions and I will open this up to the chat shortly but I just wanted to end on a kind of open thing for your effort what are you up to these days and is there anything you wanted to add to this discussion or wanted to mention a shout out or something like that?
Answer : that is a great question I mean I am working at chain safe now chainsaw systems is it a block chain development company that is very chain agnostic and this is something I really appreciated. I have been in Bitcoin for so long I have been experimenting and developing for so many different altcoins. I have been in this room, I have been in the Classic, I have tried to launch the poker parachainersit is just the system ecosystem is so interesting to just be limited to one project and I would just say everyone should be open to all the projects and just you can easily build on multiple block chains if you want to and you should not be sold to one solution in first place and this is something I appreciate about working at chain safe. I can work on many different block chain ecosystems in many different programming languages without being sold or sold out to one solution and this is something I would just leave here for everyone to, I do not know to appreciate it or hate me for that this is something I do right now and in my free time I actually started to work on evm tooling I am maintaining. I took over maintaining the ruby cerium gem so if any one of you builds applications in ruby or on rails and hit me up it has Ethereum Classic support that is what I do right now.
Question No 18: Yes, I have a question, okay what do you think may happen to Ethereum Classic ecosystem if a chain split would happen a permanent step in case one side moves to SHA-3 and the other one continues to mine the current algorithm?
Answer : Just look at Bitcoin cash and Bitcoin as we, I would say it is always possible and it is I mean we have to appreciate this opportunity that communities if there is no rough consensus or is there no consensus at all. It is always a feature I would say that communities can just fork off if this ETC hatch versus charge three debate can never be resolved it. I mean it might be even healthy for the ecosystem to create two smaller ecosystems or communities that not only separate logically but also technically. Of course, it has shown in the past that there will be always one strong side of the chain and one at one more week fork. So I would not encourage to split the chain over consensus issues but in in the last step you could always do this and consider individuals would not be afraid of forking or splitting if there is no other way.
Question No 19: But in terms of daffy or not, or the apps how do you see this change?
Answer : Yes, it is very involved everyone not only node operators or miners have to make a decision which chains they want to support, but also everyone in communities includes developers of applications of decentralized exchanges d5 everyone has to make call and I know I remember an issue foundation network there, where this risk of I remember when the parity multisec was hacked there was a strong debate what if parity just forks this theorem and unlocks their funds on a minority chain and everyone was like freaking out about the impact on applications from met mask over stable coins such as die what happens to a forked stable coin and I know this is like very involved and that is in first place why it should be avoided. they should roughly consensus that they should be always the ultimate goal but that said as I said there is always this opportunity to decide to make this final decision to say okay. We want this feature so hard that we are willing to fork off and then everyone needs to make the call will your stay let us assume you have a defy stable coin, will you support it on network or network b or will you even go that far that you should support it on both sides contentious as hard forks are always a very difficult task to pull off and many people lost many people lost money in the Dao hard fork for example, when Nissium foundation patched a protocol and there was replay detections on replay attacks on Ethereum Classic and this one Classic was forced to implement a different chain and it is always not recommended but it is still a possible route thank you.
Question No 20 : Another question is related to the treasury debate what are your thoughts on attacks for miners for getting basically money to fund development improvements research and stuff like that?
Answer : This is a very nuanced question the general sentiment I would say it is always good to have funding for ecosystem is always crucial to have funding for developers especially for core development. The treasury proposals we have seen on issue Classic were kind of controversial and this is mainly because of the power that comes with this responsibility. This potential of abuse that could be introduced so the question is less of a technical one but more of the governance question how do you have much money, do you put where who is controlling,who gets money ,how do you make change to the system and I was in the beginning I was following this debate closely and I was another impression this was going completely backwards that some stakeholders and ecosystem tried to fill their own pockets based on those proposals. So, I believe it is better to have no treasury than something like that was proposed back in the day, but then again it is always good to explore ways to fund development long term and communities should not be afraid of doing so, and you could always I mean Islam Classic has a very strictly defined monetary policy you could always revise this, but this is something you need to do with the entire community together, you need to clearly define the goals who should be funded, how much funding is acceptable and also how much can you take away from miners or will you create additional block rewards that not go to miners but to a treasury. However you call it ,you map it out, you need to be very careful and I would not say it should not be done but it is very difficult to do it in a fair way and eventually all mechanisms of governments around us in the end are very messy, let us face it.
Question No 21: Thank you, this is my last question. Do you they think that the developers are now scared of coming to edc or they just bypass it and develop on Ethereum because there is more money there and more users what they think it is is a slowing development for ETC?
Answer : Yes, that is an interesting question I mean there was a time when Ethereum clearly did not scale when the econ foundation network was so contested that you had to pay thousands of dollars to get a transaction broadcasters brought broadcast and included in the blog. This was a time before layer 2 was a thing when side chains were seeing like. I would say POA network was an interesting example x die, these are all chains that were created well after Ethereum existed issue Classic existed was the ultimate goal to provide a cheaper alternative in parallel to the issue foundation network. This is something I have always believed was a huge chance for Ethereum Classic that is why I also tried to assist in bringing issue Classic back to protocol parity so that Ethereum developers could also have this option to not only deploy to one chain but to choose which chain they deployed on and eventually in the end this never worked out and I believe this is always complicated because the differences between assume Classic and assume foundation networks, are not only of technical nature but also in political nature and people rather decided to deploy applications on extern network orit is called nosos network. Now because they believed they do not or they did not want to get involved in politics because the moment you move an application from issue foundation network to assume Classic network it could necessarily have to be but it could look like to outsiders as a political act and this is probably something that prevented a lot of applications to experiment with issue Classic in first place. Today I would say it is a bit more as it is a different situation because now we see layer twos coming up so layer ones in general lose relevance a little bit and at least from an application perspective. So in 2022 I would say it is really even more difficult for his home Classic to attract developers.
Question No 22: Hey afraid Henry, good to hear from you thanks for insight on the hard fork we have always wondered what goes on in the background. My question is related to Ethereum, what do you think the chances are of a 1.0 fork and you know it does pose a lot of difficulties for people trying to carry on the 1.0 chain as they have to try and maintain the for 2.0 chain which is hard to do and then we have also got you know threat of the ice age and the higher difficulty that the core does from Ethereum can impose ?
Answer : Hey Henry thank you for this question as I said earlier I believe the chances for an east one fork are very long for multiple reasons so the one reason is that removing the difficulty bomb would be an active fork you would have to actively fork against the merch you cannot only maintain the status quo and lean back and say we are the original econ foundation network but you would actively have to oppose what not two ,not three but like eight or nine client teams have been working on for several years so this sees one thing and the other thing is that I believe that miners really do not care too much politically about how a network evolves. I mean they are not very happy about the move to proof of stake but I also believe they will not necessarily mine a debt chain because they also have to pay energy bills in the end and the risk that these coins are worthless are fairly high and also I mean technically proof of fake has always been only assumed is on the Ethereum roadmap so it is really difficult to argue that there is some value behind this is one proof of work fork coins.
Question** No 23**: This is Kevin again I just wanted to thank you for continuing to this project as it is pretty noble of you, but about a potential switch of the mining algorithm like I totally agree with you and you know the bit mains user activated hard fork and then be cash and then you know segwit2x and none of that really ever happened because there just was not you know what you were talking about like, there was not any as you know other clients available but I think you make some really good points. I think a lot more people should listen to you more often and thanks for being around.
Answer : Well thanks for having me. I mean it is still interesting developments on Ethereum Classic. I am really curious to see how it moves and works out as I am also interested about I did not really follow but how your discussion around the 1559 concluded in the end. I just saw today that you eventually decided not to include it. I mean I know that you never wanted to include it and it makes totally sense not to include but like not having type two transaction types or a base fee up code for compatibility. It is still interesting because now we are leaving basically the field of protocol parity a little bit.
Question No 24 : Yes, the most definitely would you say or think you know maybe Ethereum is sort of like a test net for Ethereum Classic in a sense?
Answer : In a sense maybe, I mean they have a lot of new features and a lot of users that test these features in the end assume Classic can just cherry pick and technically that is what sim Classic has done in the last years. Yes, I would in 2022, I would even argue it might be worth revisiting the monetary policy of issuing Classic under the circumstances of burning minor fees as it happens with eip 1559, but this is I am just more interested in the technical implications but I am not really following or thinking about economic implications. So, just I am not really opinionated about it, I am just coming more from an application or tooling developer and seeing that Ethereum Classic will not really support type 2 transactions which most of the EVM tooling is moving towards making a default.
Question No 25 :Yes, that was actually one of the concerns at the very beginning of the monetary policy debate that is to happen eventually you know there is not going to be you know the mining rewards there to be sufficient for developers to develop. So, I think for sure that'll probably be revisited because from what I understand and all the research I have looked at everything I have seen ,it was geared more towards the investor side so it will be interesting to see the developer side share their thoughts and opinion on that.
Answer : yes, totally.
Question No 26 : With regards to the base fee opcode lack of support, I am also not sure why that was intentionally avoided. I think it was rejected from the mystique fork right but maybe, it will be added later on and potentially if Ethereum Classic implements a versioning system then that could also be added as one of the many EVM versions that it supports?
Answer : I think the reasoning was that by not completely implementing 1559 this opens up a lot of unknown vectors because you would have to partially implement it and change the way it is supposed to work and by even setting base feed to zero or hard codings certain aspects that we do not want means introducing a lot of complexity and this is probably the reason for convenience that you just or the quarterback decided against implementing it and makes sense from a technical perspective but looking at all as I said I am coming from a developer perspective that most wallets move towards and I mean issue foundation network is the biggest EVM network we have to admit this and they in most cases default to type 2 or like eip 1559 transactions by default because it is otherwise it would be a waste of transaction fees on the issue network and therefore, it could further broaden the gap between Ethereum and the assume Classic and make it more difficult for assume developers to build and deploy applications on the same Classic.
Question No 27: I see so this is a compatibility issue that will affect wallet and message signing primarily or transaction construction as opposed to contract authoring, is that correct?
Answer : Yes, this is basically about how transactions look like but I mean Ethereum Classic, so there are transaction envelopes I don't know how familiar you are this is there are legacy transactions that are basically just the most simple way to have a transaction on an EVM network and these basically get wrapped in an envelope and Ethereum Classic already has this feature ,there are so called type 1 transactions that have this feature. So, you could, maybe also have a different type two implementations that just maps. I don't know max priority fee to guess price or something like that just because the only difference between eip1559 transactions from a transaction perspective to legacy transaction, also called type zero transaction is that you have two different types of gas price.
Question No 28: I have one question about the timing of parts of a hard fork if we look at the final stages of a hard fork then there are things like having a feature freeze for all the things that should go into it, then a point where all the relevant code should be stable and once you have reached that then I guess the next step would be to set that a square transition block just schedule when the hard work will happen and make an announcement and well first of all do I get this sequence right, would you do things in a different order and the second question would be then how much time would pass between the announcement and the actual forks, how much time do people in general need to do I mean like exchange operators and such or maybe wallet developers who have not been paid attention yet h ow much time do they need after the announcement to get right out there on their side?
Answer: That is a very interesting question always there is no general rule to this and that has a lot of moving parts here that need to work together correctly in case to ensure that hard fork will execute properly on a given timeline. I personally always coordinated hard forked backboards so, if you would task me with coordinating a hard fork on Ethereum Classic today I would say okay. Let us do it in June that is five months and I think the minimum time, and minimum convenient time to execute a hard fork if you already know what the features are then you would have to go through governance and I would do this entire process of implementing it and testing it and finding rough consensus something that can be executed in parallel that is not blocked by timing a hard fork because you can always adjust dates later but ideally you don't want to adjust dates too often so it will create confusion between node runners and miners exchanges. You want to avoid announcing dates before you actually know when you want to. So let us assume you want to have five or six months' time now in advance to plan and execute this fork then you basically go backwards to say let us talk on Wednesday the June , 21st and then you go backwards okay. You want to have at least six if not eight weeks of stable test net activate activation so you go six weeks before June 21st. So, you basically have beginning of May this would be the last test net activation. In this case on coty test net maybe two weeks before so, end of April you would do a motor test net more but much less stable than cotty so you would do a mortar test activation and now you already have a very tight timeline. So you already see okay in the end of April is just two months out. So you would have to deliver this entire development cycle this entire private testing or internal testing cycle needs to be delivered within the next. Let us say eight to nine weeks starting now in February and this would also include the ECIP governance process so you would make a proposal to make this hard fork on the state and you can do already run some numbers and suggest number sit is really always numbers block numbers with moving target and it is very difficult to estimate months in advance because block times on proof of work networks are very strong. They are not very consistent. Unfortunately soit is really hard to predict months in advance. So, I think my point is if you want to do a hard fork you basically define a wanted hard fork date in the future and try to estimate, will this work also by calculating backwards the main net activation, the test net activation ,the internal feature freeze and internal testing deadlines and this needs to be coordinated with the core developers and they say yes this is possible or they know they say no it is not or they say it is possible but we need to have certainty from the community governance or from the ECIP process. We don't have some client teams might say they don't start implementing a feature unless it is in last call soas you see there are many moving parts to this. I hope this answers your question.
Question No 29 : It seems like the main arguments for SHA-3 to be implemented that for not to be for them, not to be until implemented is a6 will take over um and then you know it will be a centralized network um and then the opposite side is that you know all these GPU miners are just going to overwhelm the network with their you know one pita hash and that's gonna you know just uh destroy uh ETC um but I mean just like with Bitcoin and how that progressed from when it did when it was worth pennies to where it is now um do you think that would be the most likely um way forward for it or I guess the path of least resistance for that um you know the mining ecosystem
Answer : I honestly don't know um I am I am a big fan of SHA-3 but that said I am also a big fan of many other algorithms uh iron in this entire CPU mining versus GPU mining uh versus specialized hardware FPGAS A6 I never really found my spot in this debate because I can't really tell what's better this is you know you have this CPU mining networks that are run by botnets basically you have this uh you have gpu mining networks that have like this seek I mean there are people that claim that there's there's no way to make something CPU proof gpu asic resistant in first place and you can always have you can tell the community is it is gpo only and then you have the com companies see secretly having specialized chips mining it anyways on their more efficient hardware I don't know I i would say I would carefully say something like chassis would be very fair because it is like a gold standard in cryptography it would it is extremely efficient and fast and it would be easy to optimize for anyone who has access to building specialized hardware and it is also um there might be even uh applications for specialized three beyond mining I don't know I am not an expert on that but I would carefully say it is you should not be afraid of moving towards something like char sri I am not necessarily saying you should do it but I am also not a very opposed either but since we are on a nissium Classic call looking back at I don't know maybe , did this talk in Vancouver and EDC summit advocating for three in 2019 and then looking at the horrible I am I mean I am happy that all teams that were involved in the last months and years where we had to mitigate 51 attacks and patch different you know we had this mess protocol we had we moved from east to ETC all these solutions they kind of worked and we managed to prevent further attacks but then again what if we had taken alex seriously in 2019 and just executed upon his ideas and stand out from move away from Ethereum uh move towards a different algorithm that could be more efficient more fairly distributed with regards to hardware and I mean um yeah what if I mean there's a lot of water autism but uh yeah I cannot give a definite answer but I would say it you should not be afraid of and I also like a lot uh henry's idea about having even more than one algorithm if it is carefully specked out.
Question** No 30**:Afri I want to say um I want to say thank you so much for all your work on the protocol parody I remember the days when you were working on this quite a bit and and um I think that that was a really big value lift for this network one thing I heard you talking and you might have addressed this earlier I apologize I have been kind of in and out of this call was um a lack of users and how we didn't see the shift when the fee markets were extremely high on Ethereum I also was of the opinion that we might start seeing that migration over to Ethereum Classic my question to you is do you have any thoughts on um why we didn't see that shift and perhaps there's some bridges or some sort of products protocols maybe on top of Ethereum Classic that would help in kind of ushering people over to the network um I believe that you cited you know people didn't want the political statement but nowadays I think that that's kind of fallen to the wayside as we've seen with finance smart chain and some of the other ones where um they kind of created those type of bridges some through their centralized exchanges um and you started seeing protocols pop up on those other EVMS do you have any opinion on some of the high priority um protocols that need to be built on Ethereum Classic to try to jumpstart that type of ecosystem
Answer : It is a really interesting one I think it all comes down to network effect do you want to do d5 on issue Classic if there's only limited set of exchanges if there is only limited set of tokens you can trade if there are not sufficient bridges to other networks and um I don't really have a protocol to recommend um I would just try to I mean we are running out of time but I would try to for everyone in new Zealand Classic to zoom out and think about what could be two options what could be the opportunities for assume Classic going forward because I mean let's face it in 2022 assume Classic really you cannot only be immutable and have a monetary policy and stick to your values and then again nobody I am I am trying to be provocative please don't take my word for it but just nobody cares to build applications on museum Classic you need to try to define why you need to find out why would people build on this and maybe it is worse to like take a look at I mentioned layer twos earlier on Ethereum which kind of they kind of fill this gap between they still use this network effect from all these applications and protocols available on Ethereum foundation network but they also fill the skip of being cheaper and faster and still as accessible as issue foundation maintenance but also what I don't know how many of you are following the network effects of polkadot which is also interesting they also have EVM chains they also have very similar uh applications they even use they even work with the same uh browser plugins and they came much later than issue Classic how did they build this up from scratch how what did they do to attract so many people to actually do uh defy on pokedot or I don't know there are other pockets just one example I i could go on and go on um for isilon Classic specifically it might be time to like just really step back zoom out and like get this helicopter view of this ecosystem and think if I were an application developer what needs to happen to actually use or make this attractive to deploy my applications on this network and or as a user stifle user as a trader whatever why would I use sim Classic and maybe it is really time for assume Classic to if cells desire to be more attractive for developers and users maybe it is time to also be open for more radical changes in in the technology stack in in how you position yourself do you always want to be a little sister of Ethereum foundation network or do you want to maybe do a bold move towards a new ecosystem do you want to build upon a much more modern technology stick all these things that could be considerated but you would have to be courageous and step out of this little bsu and coregas cloud is step out of this ecip process I am not saying you should ignore all this and it is so far these values are very high goods in the community and they should be preserved but you should allow yourself to think about where to move to from the point we are here today and we are still here this is a good thing but you also need to think where do you want to go and um eventually this is something I believe this is not a technical not necessarily a technical question but just something um issue Classic needs to needs to discuss uh openly and yeah this is um a discussion I would happy to follow yeah but we are running out of time yeah thank you I am free you've been super generous with your time and left us with a lot of amazing uh food for thought so uh we are over time.
Automatically Generated by YouTube
| Timestamp | |
|---|---|
| 00:00 | [Music] |
| 00:03 | hello and welcome |
| 00:05 | to ethereum classic community calls |
| 00:09 | etc community course is a weekly voice |
| 00:11 | chat that happens on the ethereum |
| 00:12 | classic discord server every tuesday |
| 00:14 | usually at 1500 hours utc |
| 00:17 | the content of these calls is decided by |
| 00:19 | the etc community if you'd like to |
| 00:20 | contribute you can join us on discord at |
| 00:22 | ethereumclassic.org discord and you'll |
| 00:25 | find us in the community course channel |
| 00:27 | if you'd like to help spread the good |
| 00:28 | word of classic make sure you comment on |
| 00:30 | this video like it subscribe share and |
| 00:33 | hit the notification bell |
| 00:36 | thanks to all involved in contributing |
| 00:38 | to etc |
| 00:43 | hello and welcome to ethereum classic |
| 00:44 | community call number 12 on the 8th of |
| 00:47 | february 2022. today we're joined by |
| 00:50 | special guest afri to discuss |
| 00:53 | hard-fought coordination as well as |
| 00:54 | various other etc related topics we've |
| 00:57 | been collecting questions from the |
| 00:58 | community this week and a few lined up |
| 01:00 | but there will be opportunity later on |
| 01:01 | to ask questions directly if you're |
| 01:02 | joining us on the voice chat or you can |
| 01:04 | post a message in the community calls |
| 01:06 | channel and we'll keep an eye on that |
| 01:07 | before we begin with the q a i just |
| 01:09 | wanted to |
| 01:10 | make a couple of quick announcements |
| 01:12 | both related to shah 3 debate which is |
| 01:16 | ongoing |
| 01:17 | first there is a dev call |
| 01:19 | on the 21st of february |
| 01:22 | at 1 500 utc |
| 01:24 | which we'll be discussing a proposal to |
| 01:27 | reject |
| 01:28 | ecip 104.9 and that would be to reject |
| 01:31 | the sha-3 proposal so if you're |
| 01:34 | interested in joining that debate |
| 01:37 | it's it's planned to |
| 01:39 | there's a link in the uh the discord as |
| 01:42 | well as the um |
| 01:43 | the show notes for this um so you can |
| 01:46 | join us on the 21st of february there's |
| 01:49 | also a |
| 01:51 | paper from henry who has just updated |
| 01:54 | the community with his proposal to |
| 01:57 | do a hybrid proof-of-work uh transition |
| 02:00 | using sha-3 so instead of a an immediate |
| 02:03 | switchover some kind of phase transition |
| 02:05 | i believe |
| 02:06 | this white paper has literally just |
| 02:08 | landed so |
| 02:09 | um you're the first to hear about it and |
| 02:12 | there will also be a link |
| 02:14 | in the agenda item to that white paper |
| 02:17 | and we hope to be discussing that white |
| 02:19 | paper in a bit more detail next week |
| 02:22 | but we will |
| 02:24 | recommend you read that |
| 02:26 | if you're interested in continuing the |
| 02:28 | debate there so um |
| 02:30 | let's kick things off with the |
| 02:32 | q a with afri so |
| 02:34 | just a bit of background first of all |
| 02:36 | there is an upcoming hard fork on |
| 02:38 | ethereum classic called mystique which |
| 02:40 | is landing on the 13th of february now |
| 02:43 | previous hard forks i believe have been |
| 02:46 | having a dedicated hardfought |
| 02:47 | coordinator luckily the same is true |
| 02:50 | this time with etc |
| 02:52 | etc co-op taking charge of this fork and |
| 02:54 | they'll be helping with coordination |
| 02:57 | you can follow bob's twitter with |
| 02:58 | updates about that and thank you to |
| 03:01 | etc co-op as etc is likely to be |
| 03:03 | experiencing hard forks for many years |
| 03:05 | to come we wanted to open source some of |
| 03:08 | the knowledge that has been accumulated |
| 03:09 | over the years by speaking to a |
| 03:11 | qualified hard-fought coordinator in |
| 03:13 | hopes that it can help ensure future |
| 03:15 | forks go smoothly so we're pleased to be |
| 03:17 | joined by one of the most experienced |
| 03:19 | and qualified coordinators out there |
| 03:21 | afri who is a veteran and prolific |
| 03:23 | caretaker of various blockchains and |
| 03:24 | test nets afraid has previously helped |
| 03:26 | coordinate walks on etc such as agartha |
| 03:29 | and i believe a number of previous forks |
| 03:31 | as well so first of all warm welcome |
| 03:34 | afree and thank you very much for |
| 03:35 | joining us today to share some knowledge |
| 03:36 | with the etc community |
| 03:38 | um |
| 03:39 | hello thank you thank you for this warm |
| 03:42 | introduction uh |
| 03:43 | tumbled |
| 03:45 | yes and thank you for inviting me and |
| 03:47 | thank you for giving me this opportunity |
| 03:49 | to share my insights with the community |
| 03:52 | great no it's our honor thank you so uh |
| 03:55 | first question and i asked this to |
| 03:56 | pretty much everyone so who is |
| 03:59 | and how has he been involved with |
| 04:01 | blockchain web 3 and etc |
| 04:05 | you spend so much time do you have |
| 04:07 | i am um |
| 04:09 | i i i |
| 04:11 | i'm a long-term member of the crypto |
| 04:13 | community i |
| 04:14 | when i found out about bitcoin i was |
| 04:17 | really excited i i think i would say |
| 04:20 | i got into the space by |
| 04:22 | mining uh i i really really found it so |
| 04:25 | interesting that you can um so like |
| 04:28 | satoshi's vision that one cpu is one |
| 04:31 | vote i mean this does not necessarily |
| 04:33 | hold through today but it was just |
| 04:35 | something that fascinated me about |
| 04:36 | bitcoin and i i in the early days i had |
| 04:39 | really fun just assembling |
| 04:41 | uh mining with like assembling gpus and |
| 04:43 | uh mining |
| 04:45 | not bitcoin necessarily but like a lot |
| 04:47 | of uh |
| 04:48 | altcoins in the back in the day like |
| 04:49 | litecoin and other |
| 04:51 | interesting uh experiments um |
| 04:54 | and |
| 04:55 | for me it was really interesting both |
| 04:57 | from a technical perspective i'm an |
| 04:59 | engineer by degrees so i really enjoy |
| 05:02 | the |
| 05:03 | the |
| 05:03 | the technic |
| 05:05 | technicalities around us but i also uh |
| 05:08 | and really enjoy uh are really uh |
| 05:11 | intrigued by all these um potential |
| 05:14 | impact this could have on uh for the |
| 05:16 | financial system or in society in |
| 05:18 | general |
| 05:20 | so there and eventually i came across |
| 05:22 | issue classic very early on when i read |
| 05:25 | the white paper by vitalik buttering |
| 05:28 | and |
| 05:30 | tried to test |
| 05:33 | test writing my first smart contract in |
| 05:35 | 2015 which was a complete mess but |
| 05:39 | eventually i kind of was sucked into |
| 05:41 | ethereum |
| 05:42 | uh |
| 05:43 | in first place because it was so |
| 05:45 | interesting to see that you have this |
| 05:47 | entire uh |
| 05:50 | potential unlocked by a programmable |
| 05:52 | virtual machine and as i said i'm an |
| 05:54 | engineer uh uh i'm naturally curious |
| 05:57 | about these uh technical aspects |
| 05:59 | and yeah here i am i've been a long-term |
| 06:02 | member of this human community or also |
| 06:03 | iso classic community |
| 06:05 | i |
| 06:06 | i was hard for coordinator for both |
| 06:08 | ethereum and ethereum classic |
| 06:11 | so um yeah i think just how the story |
| 06:14 | begins and um here i am now guest on |
| 06:17 | this |
| 06:18 | call uh uh |
| 06:20 | you have a hard fork scheduled that is |
| 06:23 | basically the first one after the time |
| 06:26 | that i was involved with this classic |
| 06:28 | yeah i'm i'm not really |
| 06:30 | i didn't really had the chance to leave |
| 06:31 | the space in first place i'm kind of |
| 06:34 | still in here with one foot that's |
| 06:36 | awesome yeah it's really good to uh um |
| 06:39 | kind of help us hand over the baton to |
| 06:41 | the next generation of coordinators um |
| 06:43 | so thanks for that and uh let's kick off |
| 06:46 | with the first sort of real question and |
| 06:49 | i guess |
| 06:50 | what would you say is the goal of |
| 06:51 | hard-fought coordination |
| 06:54 | hard for coordination is technically |
| 06:57 | nothing |
| 06:58 | is basically the same as traditional |
| 07:01 | software engineering project management |
| 07:04 | um you have to coordinate |
| 07:06 | a group of people to reach a common goal |
| 07:09 | and eventually in the specification to |
| 07:12 | hit a certain deadline of delivering |
| 07:16 | delivering |
| 07:17 | the various pieces of software |
| 07:20 | towards certain deadlines that need to |
| 07:22 | be met because |
| 07:24 | in this case it's very interesting uh |
| 07:26 | with all these aspects around consensus |
| 07:29 | between different uh clients different |
| 07:31 | client teams between different themes |
| 07:33 | that might work on applications or tests |
| 07:35 | or whatever else involved |
| 07:38 | so the heart for coordination is |
| 07:39 | basically just |
| 07:41 | just a new application of a traditional |
| 07:44 | software engineering profession |
| 07:46 | and it |
| 07:47 | it's a lot around orchestrating |
| 07:50 | engineers |
| 07:52 | doing a lot of qa but also doing a lot |
| 07:54 | of project management around |
| 07:57 | around um timing estimating um and and |
| 08:01 | yeah all these those kind of things |
| 08:03 | okay and the |
| 08:05 | in in the process of coordinating hard |
| 08:07 | fork what are the things that you're |
| 08:08 | trying to avoid happen uh i guess |
| 08:11 | there's a number of potential things |
| 08:13 | that you could say this this hard fork |
| 08:15 | didn't go well so what what might those |
| 08:17 | be and uh how do you try and avoid them |
| 08:20 | typically |
| 08:21 | yeah that's an interesting question so a |
| 08:22 | hard fork is not really |
| 08:25 | strict there's no no no strong |
| 08:27 | definition of this term hard fork but i |
| 08:30 | think we can all agree that that this is |
| 08:32 | a set of changes applied to |
| 08:34 | a consensus system such such as a |
| 08:36 | blockchain protocol that introduces |
| 08:39 | breaking changes so |
| 08:40 | the ultimate goal of a hard fork |
| 08:43 | coordinator should be |
| 08:45 | to first of all |
| 08:46 | convince or not convince but um help the |
| 08:50 | community to find consensus on such an |
| 08:52 | upgrade not only on a technical level |
| 08:55 | but also on a community level because |
| 08:57 | there needs to be |
| 08:58 | rough consensus to move forward because |
| 09:00 | if the community is not |
| 09:02 | if the community am i |
| 09:05 | i'm sorry i'm just confused by my push |
| 09:06 | to talk if the community is not aligned |
| 09:09 | on a hard fork then it might not happen |
| 09:11 | or you risk a chain split if to if the |
| 09:14 | community goes in in different |
| 09:16 | directions or creates different tribes |
| 09:19 | with different opinions |
| 09:20 | and a hard fork coordination basically |
| 09:23 | assists community in in finding the path |
| 09:26 | to rough consensus and |
| 09:29 | this is both uh important on um |
| 09:33 | on logical level or on community level |
| 09:34 | but also on technical level and the risk |
| 09:37 | here is as |
| 09:39 | to to answer your question is that um |
| 09:42 | it's there are many facets to it um |
| 09:45 | it could happen that the community does |
| 09:47 | not care about an upgrade and just does |
| 09:49 | not upgrade at all so you have to take |
| 09:51 | ready but |
| 09:52 | miners keep running the old software |
| 09:54 | they don't upgrade |
| 09:55 | another risk is that like only a small |
| 09:58 | amount of |
| 10:00 | miners or other network operators |
| 10:02 | upgrade and then you risk a chain split |
| 10:04 | because you have two different protocol |
| 10:06 | versions |
| 10:07 | and |
| 10:08 | and the worst case is obviously that you |
| 10:10 | have if you have different protocol |
| 10:13 | implementations that you have consensus |
| 10:14 | issues that only reveal on the main net |
| 10:17 | activation and this needs to be |
| 10:20 | carefully prevented and prepared and |
| 10:24 | that's all what hard fork coordination |
| 10:25 | is about planning |
| 10:27 | testing iterating |
| 10:30 | both on technical but also on community |
| 10:33 | and communications level |
| 10:35 | so a lot of things can go wrong and i |
| 10:37 | guess um especially when operating with |
| 10:39 | a live test net some of these issues are |
| 10:41 | not going to be apparent even on um |
| 10:44 | even in testing and it's only on like a |
| 10:46 | an economically incentivized real world |
| 10:48 | use case that some of the problems might |
| 10:50 | emerge |
| 10:51 | totally this is always a risk and |
| 10:55 | um that's |
| 10:56 | why we have so many different testnets |
| 10:58 | in first place so usually the process is |
| 11:00 | that you |
| 11:01 | um that the engineers test uh |
| 11:04 | everything in private on the i don't |
| 11:06 | know under development or feature |
| 11:07 | branches and |
| 11:08 | eventually when they believe when they |
| 11:11 | you know software |
| 11:13 | software development is never final but |
| 11:16 | in the end if you believe that your |
| 11:18 | feature is ready then you test then you |
| 11:20 | talk to other client teams and then you |
| 11:21 | create private test nets and and you |
| 11:24 | test different implementations of the |
| 11:26 | same thing against each other |
| 11:28 | and even then |
| 11:29 | you you just grow confident that your |
| 11:31 | code is working and that the other |
| 11:33 | team's code is working and then |
| 11:34 | eventually you can |
| 11:36 | approach community and and try to |
| 11:38 | schedule |
| 11:39 | these |
| 11:40 | features on test nets and even on |
| 11:42 | testness you you don't have the same |
| 11:44 | utility as on the mainnet and you can |
| 11:46 | really try to stress test everything on |
| 11:49 | testnet and |
| 11:50 | even on extremely heavily used test nets |
| 11:53 | such as the old modern classic test net |
| 11:56 | even such as uh assume foundations |
| 11:58 | robson testnet you still can miss |
| 12:01 | certain edge cases and there's always a |
| 12:03 | small risk that the day you activate a |
| 12:05 | feature on mainnet you you miss |
| 12:07 | something |
| 12:08 | and it eventually will trigger |
| 12:10 | only on maintenance and uh |
| 12:13 | eventually |
| 12:15 | break mainnet consensus which would be |
| 12:17 | the worst case or the biggest failed of |
| 12:19 | hard-fought coordination in that regard |
| 12:21 | i see |
| 12:22 | um and i guess uh the the big day of |
| 12:25 | those four walks must be fairly uh |
| 12:27 | stressful it's like a a lot of work |
| 12:29 | coming into one thing and if nothing |
| 12:31 | happens uh you've done your job but if |
| 12:33 | it goes badly then yeah it sucks |
| 12:36 | so |
| 12:38 | in terms of the actual |
| 12:41 | like |
| 12:41 | fork block arriving on mainnet what kind |
| 12:44 | of |
| 12:45 | uh tooling and monitoring systems would |
| 12:48 | a hard fork coordinator typically |
| 12:50 | utilize to ensure that things are going |
| 12:52 | smoothly and how would you detect any |
| 12:54 | anomalies that you weren't expecting |
| 12:57 | yeah so in an actual hard fought |
| 13:00 | different parties involved so the hard |
| 13:01 | fought coordinator as a state it's kind |
| 13:03 | of just orchestrating different involved |
| 13:05 | parties so on the one hand you have the |
| 13:07 | core developers that are basically |
| 13:11 | let's let's assume for one moment we are |
| 13:13 | talking about the test net hard fork so |
| 13:15 | in case the hard work activates on the |
| 13:17 | coty or mortar test net then developers |
| 13:20 | could just basically look very closely |
| 13:23 | or |
| 13:24 | at their code or at their clients |
| 13:26 | they run in certain debugging modes or |
| 13:29 | monitoring modes they try to actively |
| 13:32 | break it by |
| 13:33 | triggering the new features that are |
| 13:35 | activated |
| 13:36 | and |
| 13:37 | but you also have other stakeholders you |
| 13:39 | have uh validators on the proof of |
| 13:41 | authority networks you have miners on |
| 13:43 | proof of work networks and also these |
| 13:46 | um stakeholders needs to carefully |
| 13:50 | monitor what how their nodes operate and |
| 13:53 | as they |
| 13:54 | operate |
| 13:55 | operating uh correctly and what i do as |
| 13:58 | a hard fork coordinator usually is that |
| 14:00 | i get a |
| 14:02 | number of bare metal machines and i |
| 14:04 | install |
| 14:05 | i try to install |
| 14:07 | all |
| 14:08 | existing protocol implementations all |
| 14:12 | clients |
| 14:14 | in different configurations so i |
| 14:17 | usually have a prefork and a post fork |
| 14:19 | configuration ready so that i can |
| 14:22 | easily compare outputs of both |
| 14:25 | clients both versions of the protocol |
| 14:27 | against the matrix of all clients so if |
| 14:30 | you have three clients and uh two |
| 14:32 | different network versions you have |
| 14:33 | basically a matrix of |
| 14:35 | six different uh clients and versions |
| 14:38 | and um in |
| 14:40 | in the moment the hard fork activates |
| 14:42 | you can use different tools for |
| 14:44 | monitoring what's going on and |
| 14:46 | i personally use the |
| 14:49 | so called fork monitor which is |
| 14:50 | basically just |
| 14:51 | um a |
| 14:53 | very tiny html page with some embedded |
| 14:56 | javascript that |
| 14:59 | queries an rpc endpoint and |
| 15:02 | gets from all these different versions |
| 15:05 | and clients |
| 15:06 | the latest block information and |
| 15:09 | compares a lot of metrics such as uh |
| 15:12 | block height |
| 15:14 | block cash block uh |
| 15:16 | total difficulty and so on and with all |
| 15:19 | these little metrics |
| 15:20 | if you put them all next to each other |
| 15:22 | then you can easily spot any |
| 15:24 | misbehaviors and if something is is |
| 15:27 | going wrong you can immediately spot it |
| 15:29 | you can immediately uh talk to |
| 15:31 | developers uh |
| 15:32 | ask questions you can approach miners |
| 15:35 | and so on |
| 15:36 | um and so i will leave the fork |
| 15:39 | monitoring dashboard is one of the most |
| 15:43 | excuse me |
| 15:44 | one of the most important tools but |
| 15:46 | there are also other tools uh i use |
| 15:50 | mining pool software to run my own |
| 15:52 | miners |
| 15:53 | i use |
| 15:55 | the the start of dashboards uh the these |
| 15:58 | is also called ethernet network startups |
| 16:01 | dashboards where you can get a more |
| 16:04 | more |
| 16:05 | wide overview of the network status um |
| 16:08 | and yeah there are some more smaller |
| 16:11 | tools you could use |
| 16:12 | i see and uh |
| 16:14 | on top of this you're not just |
| 16:15 | monitoring the network but also |
| 16:17 | potentially reaching out to different |
| 16:19 | uh |
| 16:20 | stakeholders um which might include uh |
| 16:24 | exchanges and |
| 16:25 | uh wallet operators for example and i |
| 16:28 | guess depending on the type of |
| 16:30 | uh |
| 16:31 | problem with the fork would depend on |
| 16:33 | who needs to update that client or |
| 16:37 | yeah who's behind on the old network and |
| 16:39 | it seems like you need to be able to |
| 16:40 | contact basically any major player that |
| 16:43 | hasn't updated properly or needs to push |
| 16:45 | an update |
| 16:47 | and that requires some level of i guess |
| 16:50 | you as a central point of contact are |
| 16:52 | somewhat trusted by these other |
| 16:54 | counterparties right |
| 16:56 | yes in a way |
| 16:59 | this |
| 17:00 | role of hard-fought coordination is a |
| 17:02 | very um is |
| 17:05 | a role that needs to be very carefully |
| 17:07 | executed because you are not a hard fork |
| 17:10 | manager you're not a |
| 17:12 | chief uh |
| 17:14 | chief hard fork uh |
| 17:16 | executor but but it needs to be very |
| 17:19 | very clearly um |
| 17:21 | very clearly communicated as that |
| 17:23 | coordination is a process of |
| 17:25 | management without |
| 17:27 | authority or without hierarchy because |
| 17:30 | the |
| 17:32 | the fact that you |
| 17:34 | hold a lot of strings in your hands and |
| 17:36 | try to tie them together doesn't |
| 17:38 | necessarily mean you are in a position |
| 17:40 | of power and you should also not try to |
| 17:42 | become a position of power so um with |
| 17:46 | that said |
| 17:47 | um |
| 17:48 | with that said uh i i would say uh |
| 17:50 | you you |
| 17:52 | still uh if you execute this correctly |
| 17:54 | then you come in a position where people |
| 17:56 | trust you and they understand that if |
| 17:58 | you are working for a |
| 18:01 | certain client team or for the econ |
| 18:02 | classic community in this regard |
| 18:04 | that people accept your kind of |
| 18:07 | authority when you reach out to them and |
| 18:09 | inform them about |
| 18:11 | uh |
| 18:12 | certain upgrades in future |
| 18:14 | i see so |
| 18:15 | in in the example of there being some |
| 18:18 | kind of problem with a with a chain |
| 18:19 | split what would it look like from the |
| 18:22 | hard fought coordinators perspective to |
| 18:24 | try and fix things like if they need to |
| 18:27 | send a message to an exchange to get |
| 18:29 | them to update for example would that be |
| 18:31 | done by the coordinator themselves or by |
| 18:33 | some other would they be asking the |
| 18:36 | client team to request that or who's |
| 18:39 | who's pushing messages around |
| 18:42 | so i mean we need to differentiate here |
| 18:45 | uh there are two different types of |
| 18:47 | communication so one is prior to support |
| 18:49 | and the other is post four |
| 18:50 | communications and |
| 18:52 | the communications leading up towards |
| 18:55 | the hard fork are much more relaxed |
| 18:56 | because you still have time to prepare |
| 18:58 | people to upgrade their notes and this |
| 19:01 | is a process that can be fairly |
| 19:03 | decentralized anyone from the community |
| 19:05 | can reach out to coinbase to |
| 19:08 | assume classic pools or they can look up |
| 19:11 | um network statistics which are the |
| 19:14 | biggest pools which are the most |
| 19:15 | important they can individually reach |
| 19:17 | out they can just share like common uh |
| 19:20 | resources from the ecips repository or |
| 19:23 | news items just to prove that there is |
| 19:25 | something going on that pooled or other |
| 19:27 | infrastructure providers needs to be |
| 19:29 | aware of |
| 19:30 | um this changes a lot in |
| 19:33 | the event of emergency so let's assume |
| 19:37 | let's let's say the hard fork goes wrong |
| 19:39 | we have a consensus issue between two |
| 19:41 | client implementations or something else |
| 19:43 | goes wrong not enough miners |
| 19:45 | uh uh |
| 19:47 | upgraded and |
| 19:48 | i don't know clients try to reorganize |
| 19:50 | to the wrong chain and it's like a |
| 19:51 | complete mess in this regard then the |
| 19:54 | hard fork coordinator has a certain |
| 19:57 | responsibility to orchestrate people or |
| 20:00 | like to delegate people to |
| 20:02 | directly identify the issue |
| 20:05 | as soon as possible and reach out to |
| 20:08 | involved parties as soon as possible |
| 20:10 | it is not necessarily the role of the |
| 20:12 | hardfork coordinator to also reach out |
| 20:15 | um i personally have done a lot of |
| 20:17 | outreach um just because um |
| 20:20 | when you have this responsibility that |
| 20:22 | everything goes |
| 20:23 | right and nothing goes wrong and and you |
| 20:26 | kind of want to have perhaps on all all |
| 20:28 | the |
| 20:29 | all the involved stakeholders so |
| 20:31 | um |
| 20:32 | it naturally evolves this way that you |
| 20:34 | um |
| 20:34 | start also doing the outreach but |
| 20:37 | i would carefully say that uh |
| 20:40 | it's not necessarily the job of uh uh |
| 20:43 | the hardcore coordinator and uh |
| 20:44 | specifically in decentralized |
| 20:46 | communities anyone could technically do |
| 20:48 | it |
| 20:49 | i see |
| 20:50 | i guess one of the um |
| 20:52 | challenges that uh decentralized |
| 20:54 | networks face in particular is the |
| 20:56 | ongoing |
| 20:58 | managing of these books and |
| 21:00 | maintaining some |
| 21:02 | level of trust in a system that can be |
| 21:06 | decentralized enough but also |
| 21:08 | not so decentralized that |
| 21:10 | you know anyone could just like tell |
| 21:13 | any exchange to use this version of the |
| 21:14 | hardware sorry this version of the |
| 21:16 | software or this version and that could |
| 21:18 | itself cause issues and the other issue |
| 21:20 | i suppose is |
| 21:22 | sometimes exchangers probably don't want |
| 21:24 | to give out their sort of |
| 21:27 | private battle stations uh |
| 21:29 | communications channels to anyone so uh |
| 21:33 | doing it in a completely decentralized |
| 21:35 | way seems like it's uh |
| 21:37 | very challenging going forward do you |
| 21:39 | have any ideas of how |
| 21:41 | like what the boundaries are in terms of |
| 21:43 | how decentralized it could be |
| 21:45 | going forward and how |
| 21:47 | like how this could be coordinated in a |
| 21:50 | in a sort of standardized way going |
| 21:51 | forward |
| 21:53 | not really it's it's it has always been |
| 21:56 | a pain point to reach out to exchanges |
| 21:57 | especially |
| 21:59 | the ones that are not the major players |
| 22:01 | but this not just the entire not the |
| 22:03 | very small ones but like maybe the |
| 22:04 | medium-sized medium-sized ones some are |
| 22:06 | like really difficult to reach the only |
| 22:09 | way you can really find out to to |
| 22:12 | how to contact them is basically just |
| 22:14 | creating a support ticket on their |
| 22:16 | zendesk and it's like really annoying |
| 22:18 | and then you get like a |
| 22:19 | uh tire one support uh |
| 22:22 | employee that tells you that nothing is |
| 22:24 | wrong and their system is fully |
| 22:25 | operational and then you roll your eyes |
| 22:27 | and say no that's not my point |
| 22:29 | and but |
| 22:31 | i i don't i don't i'm not coming with a |
| 22:32 | recipe for this i know that in the past |
| 22:35 | uh both etc labs and etc cooperate if |
| 22:38 | they were facilitating |
| 22:42 | strong ties towards certain |
| 22:44 | infrastructure providers or exchanges |
| 22:46 | they used just through |
| 22:48 | established business |
| 22:49 | connections contacts |
| 22:52 | but also |
| 22:53 | through other official channels and |
| 22:56 | i know i don't know for example |
| 22:58 | he maintains a long list of uh |
| 23:01 | of contacts which is well around for for |
| 23:03 | these uh |
| 23:05 | cases and uh there's really not not |
| 23:08 | really a good recipe also this uh |
| 23:10 | ecosystem is changing so fast so with |
| 23:12 | each and every hard fork you have to |
| 23:14 | like basically start all over and find |
| 23:16 | out who are the biggest exchanges |
| 23:18 | um with regard to volume so when i say |
| 23:21 | biggest uh it's important because how |
| 23:23 | much money is at risk who are the |
| 23:25 | biggest miner with regard to network |
| 23:27 | sure so so how |
| 23:29 | so this is important because the more |
| 23:32 | hatch rate you have on the right |
| 23:34 | side of the consensus uh |
| 23:36 | the better your hard fork will execute |
| 23:38 | or the more smooth |
| 23:40 | uh |
| 23:41 | the builder hard work be |
| 23:42 | and |
| 23:43 | this is basically each and every heart |
| 23:45 | fork you have to basically reiterate |
| 23:48 | your list and check are these players |
| 23:51 | still do you have contacts do you know |
| 23:52 | anyone worst contact and this is in and |
| 23:55 | still i would hold my point this is |
| 23:57 | still um |
| 23:58 | the processes can be decentralized |
| 24:00 | because in a large community many people |
| 24:02 | know many more people and you can |
| 24:05 | basically facilitate these |
| 24:07 | uh contacts and keep them alive |
| 24:10 | but then again there is no |
| 24:12 | no cookbook for this situation there is |
| 24:15 | no |
| 24:16 | definite guide to upgrading a protocol |
| 24:18 | with regard to communications |
| 24:21 | right very interesting um in in the case |
| 24:24 | of a |
| 24:25 | let's say it's a temporary chain split |
| 24:28 | because of some client incompatibility |
| 24:30 | are there any heuristics that are |
| 24:33 | like go-to that you can use to |
| 24:36 | say oh this side is wrong and they need |
| 24:39 | to upgrade versus the other side like if |
| 24:42 | if two clients have the same version and |
| 24:44 | you're not really sure which one is uh |
| 24:46 | misbehaving like how do you decide which |
| 24:48 | chain to follow in the case of a chain |
| 24:50 | split like that |
| 24:52 | or is that not really a problem |
| 24:54 | uh |
| 24:55 | i would not rule this out |
| 24:57 | it certainly is |
| 24:59 | something is always a problem if |
| 25:01 | something goes wrong how fast can you |
| 25:03 | identify the issue how fast can you |
| 25:05 | identify rules responsible not not in |
| 25:07 | term of head but in term of which line |
| 25:10 | of code is responsible how fast can the |
| 25:14 | developers fix it patch it release it |
| 25:16 | and announce it and |
| 25:19 | i would carefully argue this is |
| 25:20 | something where the |
| 25:22 | core developers are |
| 25:24 | really this is one of the biggest |
| 25:26 | responsibilities during hard forks that |
| 25:29 | might go wrong that they need to be very |
| 25:32 | quick in identifying what the issue is |
| 25:35 | and then based on that you can make |
| 25:37 | calls but i would never make a call |
| 25:39 | without knowing what's going on or what |
| 25:41 | could be wrong so it's it's in most |
| 25:43 | cases you can fairly quickly |
| 25:45 | find out which of the clients or which |
| 25:48 | of the versions of the client or which |
| 25:50 | parts of the code base misbehave and |
| 25:53 | once you have identified that you can |
| 25:54 | make pre-announcements once it's patched |
| 25:56 | and released you can make announcements |
| 25:58 | to to to act uh |
| 26:00 | upon that and yeah that's |
| 26:04 | but i would say it's |
| 26:06 | this is a really a huge responsibility |
| 26:09 | on core developers in such a really uh |
| 26:12 | tough situation to quickly identify |
| 26:15 | these issues and make the calls |
| 26:17 | let's see this kind of ties in with the |
| 26:20 | um |
| 26:21 | the |
| 26:22 | debate slash conversation about client |
| 26:25 | diversity and whether or not having |
| 26:27 | multiple clients is |
| 26:29 | uh |
| 26:30 | worth the benefit of of these potential |
| 26:33 | problems when |
| 26:35 | would it be better to to have a system |
| 26:37 | closer to bitcoin where there's a single |
| 26:39 | source of truth in terms of the client |
| 26:41 | the reference client and then other |
| 26:43 | clients can support it but if ever |
| 26:45 | there's a consensus issue then it always |
| 26:47 | defaults to one client and they don't |
| 26:49 | have to maintain multiple |
| 26:51 | channels to different core devs uh do |
| 26:54 | you have thoughts on the client |
| 26:55 | diversity issue |
| 26:57 | uh yes totally i mean this is just the |
| 27:00 | answer to this question is highly |
| 27:01 | opinionated and |
| 27:03 | i know that there is a bitcoin way with |
| 27:05 | just one implementation and there is a |
| 27:07 | assumed way with as many implementations |
| 27:10 | as possible |
| 27:11 | and |
| 27:12 | i don't know what's your opinion on that |
| 27:13 | i |
| 27:14 | i would |
| 27:15 | say i have been |
| 27:17 | kind of slowly growing into this |
| 27:19 | humidism classic ecosystem and i have |
| 27:22 | been working at parity technologies with |
| 27:24 | gavin wood for several years and he |
| 27:27 | always said |
| 27:28 | i don't know if you know what let me |
| 27:29 | just quickly uh tell you a story about |
| 27:31 | um |
| 27:32 | the parity bitcoin client i don't know |
| 27:33 | if anyone remembers or even knows about |
| 27:35 | this gavin wood um released a parity |
| 27:38 | bitcoin client i think in 2018 or 2017 |
| 27:42 | and this was the only client as far as i |
| 27:45 | know back in the day that did not use |
| 27:47 | this central bitcoin consensus and he |
| 27:51 | refused to use this consensus library |
| 27:54 | published by by the bitcoin core |
| 27:55 | developers and he was attacked |
| 27:58 | heavily for doing this because they said |
| 28:01 | he puts the network at risk he puts |
| 28:03 | consensus at risk by |
| 28:05 | creating a secondary implementation of |
| 28:09 | the consensus protocol but then again he |
| 28:11 | defended |
| 28:12 | anyone should be able to build their own |
| 28:16 | implementation of this decentralized |
| 28:18 | protocol because |
| 28:20 | uh |
| 28:21 | if there's a bug in the in |
| 28:23 | in the main or in the |
| 28:25 | quote-unquote official implementation |
| 28:28 | how do you know if there's not an |
| 28:31 | additional implementation |
| 28:32 | and this is a technical aspect and but |
| 28:35 | there's also the political aspect of |
| 28:37 | protocol governments if you have only |
| 28:40 | one implementation that is maybe |
| 28:42 | controlled by only one entity |
| 28:44 | how do you ensure that this one entity |
| 28:46 | does not abuse a position of power |
| 28:49 | to just uh |
| 28:51 | you need to literally change this |
| 28:53 | implementation and |
| 28:55 | this is um now i can conclude my |
| 28:57 | personal opinion is that the ethereum |
| 28:59 | assume classic way is the better one |
| 29:01 | because |
| 29:02 | by |
| 29:03 | distributing this power of |
| 29:05 | implementation to |
| 29:07 | two three or more teams |
| 29:09 | ensures whenever |
| 29:11 | anyone wants to make change to the |
| 29:13 | consensus protocol it needs to go not to |
| 29:16 | one place but to all teams and need to |
| 29:18 | convince all teams or the community all |
| 29:20 | together and i believe this is |
| 29:23 | technically a risk i i agree um and i |
| 29:26 | understand that bitcoin |
| 29:28 | believes in being |
| 29:29 | technically more on |
| 29:31 | a |
| 29:32 | on a conservative |
| 29:35 | secure side but on the political side i |
| 29:39 | believe it's the strength of having |
| 29:40 | multiple clients implementations |
| 29:43 | um |
| 29:44 | for the sake of |
| 29:45 | being more resistant it's it's some kind |
| 29:47 | of meta decentralization you cannot just |
| 29:50 | go to one client and hack it or |
| 29:53 | or or even if there's a bug in one |
| 29:56 | client you still have other clients that |
| 29:57 | run the correct protocol and it's just i |
| 30:00 | would argue client diversity is a |
| 30:02 | strength rather than a weakness |
| 30:04 | yeah it's a very um sort of esoteric |
| 30:06 | topic and one that uh i think there's |
| 30:10 | uh |
| 30:11 | pros and cons to both sides of the |
| 30:13 | argument and the |
| 30:14 | additional complexity and coordination |
| 30:17 | effort involved can definitely pay off |
| 30:20 | uh in a lot of cases um |
| 30:22 | i i'm still personally not really |
| 30:24 | decided as to whether or not um |
| 30:27 | diversity per se |
| 30:29 | um |
| 30:30 | without a single at least like clear |
| 30:33 | defined thing |
| 30:34 | is better i'm still open to the debate |
| 30:36 | really uh but uh it's one i think that |
| 30:39 | is extremely interesting nonetheless |
| 30:41 | totally it's an interesting topic and um |
| 30:45 | uh |
| 30:46 | we have different size of black |
| 30:47 | blockchain ecosystems i mean bitcoin is |
| 30:49 | a huge ecosystem assume |
| 30:51 | maybe it's a huge polka dot might be |
| 30:53 | become a huge ecosystem i would |
| 30:55 | carefully say |
| 30:57 | assume classic is more like a |
| 30:58 | medium-sized ecosystem they still have |
| 31:01 | this the strength or the ability to |
| 31:03 | maintain more than one client |
| 31:05 | implementation but then again you can |
| 31:07 | look at all these smaller ecosystems uh |
| 31:10 | yeah you name it you just scroll down a |
| 31:12 | coin market cap and they only have one |
| 31:15 | implementation and and you never know is |
| 31:17 | there a bug in their code |
| 31:19 | do they even test do they even have the |
| 31:20 | ability to test this against do they |
| 31:22 | have any specification how do they know |
| 31:24 | that there's a bug and is if there's a |
| 31:26 | bug |
| 31:27 | this is part of the protocol now because |
| 31:29 | once |
| 31:30 | uh a bug is included in a block on a |
| 31:32 | public blockchain |
| 31:34 | most blockchains wouldn't re-roll a |
| 31:36 | royal back uh you know and um therefore |
| 31:39 | i i would say it's it's very good for |
| 31:41 | issuing classic to still have this |
| 31:42 | feature of having at least two clients |
| 31:45 | that can uh be |
| 31:46 | taking on each other so uh i would say |
| 31:49 | it's it's one of some more |
| 31:50 | major blockchain ecosystems out there |
| 31:53 | right and i believe that very client |
| 31:55 | diversity has in the past saved ethereum |
| 31:58 | classic um i think back in shanghai |
| 32:02 | uh spurious dragon hard fork right there |
| 32:04 | was a bug in one of the clients that |
| 32:05 | would have caused a major network |
| 32:07 | problem but luckily parity did not have |
| 32:09 | that bug so |
| 32:11 | at least part of the net was able to |
| 32:13 | continue exactly |
| 32:15 | okay so um moving on to the topic of i |
| 32:19 | guess um |
| 32:21 | the current state of affairs |
| 32:23 | with regards to |
| 32:26 | etc |
| 32:27 | and |
| 32:28 | what do you think having spent a good |
| 32:30 | number of years in the etc ecosystem |
| 32:34 | of recent events the |
| 32:37 | you know the treasury debate i'm not |
| 32:38 | sure if you've been following the shah 3 |
| 32:40 | but |
| 32:41 | what's your general sort of impression |
| 32:42 | of where etc is right now |
| 32:46 | that's a tough question i mean um |
| 32:48 | i mean |
| 32:49 | is serum classic is moving very slowly |
| 32:52 | and |
| 32:53 | again this is something you can |
| 32:55 | discuss about this is a feature actually |
| 32:56 | is it like |
| 32:57 | doing the bitcoin way just rather not |
| 32:59 | move at all before breaking things |
| 33:02 | or could could could there be more |
| 33:05 | accelerated development towards um |
| 33:08 | building out the ecosystem being more |
| 33:10 | developer or |
| 33:12 | application friendly |
| 33:14 | i don't know i i would carefully say |
| 33:16 | esteem classic has always been |
| 33:18 | in this risk area between these two |
| 33:20 | things and always been in this risk to |
| 33:22 | be not strong enough to be |
| 33:26 | relevant for application developers but |
| 33:28 | also not |
| 33:29 | not not fast enough to to make a |
| 33:31 | difference so um it's difficult to say |
| 33:34 | um but it was also a very broad question |
| 33:37 | so maybe you can |
| 33:39 | talk about certain aspects of what's |
| 33:41 | going on right now in the past |
| 33:43 | let's let's put it this way what what |
| 33:45 | was it about ethereum classic that drew |
| 33:47 | you to it in the first place why are we |
| 33:49 | even working on a classic at all |
| 33:52 | i mean i have been in classic from from |
| 33:54 | the beginning and uh |
| 33:57 | i have been |
| 33:59 | very close to |
| 34:00 | the robin hood group i have never |
| 34:03 | acted upon it but i've been in touch |
| 34:05 | with them for a long time and |
| 34:08 | i've always been |
| 34:11 | making jokes about how to uh explain |
| 34:14 | your tax advisor that you you not only |
| 34:16 | have one issue but two issues now and |
| 34:19 | i've been always following along and |
| 34:20 | eventually when |
| 34:22 | when uh |
| 34:24 | this |
| 34:25 | card development team kind of imploded |
| 34:28 | due to |
| 34:30 | actions i don't want to comment on right |
| 34:31 | now |
| 34:33 | it was basically a matter of how can |
| 34:36 | issum classic be saved and be moved |
| 34:38 | forward and this was when i realized |
| 34:41 | that there that i actually have |
| 34:43 | a set of ideas that could improve the |
| 34:46 | network or the net the protocol |
| 34:49 | and um eventually stepped up to |
| 34:52 | join edc labs and |
| 34:54 | assist |
| 34:55 | the ecip |
| 34:57 | editors with hardware coordination |
| 34:59 | and |
| 35:00 | we executed a |
| 35:03 | a series of |
| 35:05 | protocol upgrades that brought issue |
| 35:07 | classic to the point where it is today |
| 35:09 | and um |
| 35:10 | i think the most important feature of |
| 35:12 | issuing classic is as of today |
| 35:16 | protocol parity was with other evm |
| 35:18 | networks which is |
| 35:21 | really not to underestimate because all |
| 35:24 | tooling uh solidity uh |
| 35:27 | everything |
| 35:28 | if you everywhere to have a different |
| 35:31 | version of the evm on ethereum classic |
| 35:34 | um |
| 35:35 | it would be a huge mess and we would |
| 35:37 | have to provide our own tooling for |
| 35:39 | developers and this is something i would |
| 35:42 | argue is um the biggest benefit of using |
| 35:45 | a swim classic today |
| 35:47 | um |
| 35:48 | and um |
| 35:49 | i i would say i'm partially proud that i |
| 35:52 | could assist ethereum classic do it over |
| 35:54 | the last years in in getting there and |
| 35:56 | and sticking there and yeah i think uh |
| 35:59 | it was also great to meet many people of |
| 36:02 | the issuing classic community in |
| 36:04 | vancouver at the etc summit and |
| 36:07 | uh there was so much uh so much energy |
| 36:09 | so much good energy |
| 36:11 | and so many people building and |
| 36:13 | moving forward it was a great time |
| 36:16 | yeah i agree with everything you've said |
| 36:17 | there um and for sure the um the tooling |
| 36:21 | point is on point uh i really do believe |
| 36:25 | that a lot of the innovation happening |
| 36:26 | on ethereum |
| 36:27 | is |
| 36:28 | inherited only because of that fact and |
| 36:30 | the compatibility is super important to |
| 36:32 | maintain um but this kind of leads into |
| 36:34 | the next question um |
| 36:36 | and the next like obvious big thing on |
| 36:38 | the horizon |
| 36:40 | that's not specifically on etc but |
| 36:42 | massively affects it is the merge on |
| 36:45 | ethereum mainnet and |
| 36:47 | how do you think well first of all |
| 36:50 | is it going to happen and |
| 36:52 | if it does |
| 36:53 | do you think miners are going to try and |
| 36:55 | mine the old chain and continue like |
| 36:57 | ethereum mainnet version one and |
| 37:00 | if not uh are they gonna come to etc and |
| 37:03 | if they do does that pose a problem for |
| 37:05 | atc or is it a benefit in your in your |
| 37:07 | eyes |
| 37:08 | um yeah that's that's many questions um |
| 37:11 | so first of all i'm a miner by heart so |
| 37:13 | i love just |
| 37:15 | how however slower miners doesn't matter |
| 37:17 | i love |
| 37:19 | this |
| 37:20 | feature of proof of work that anyone can |
| 37:23 | be part of the consensus of the protocol |
| 37:26 | and |
| 37:27 | that's why i believe proof of work is is |
| 37:31 | a great way of consensus |
| 37:35 | i |
| 37:36 | was once um |
| 37:38 | going to a museum here in berlin |
| 37:40 | um they had um |
| 37:42 | i think they had a small programmable |
| 37:45 | calculator that was mining bitcoin |
| 37:47 | blocks and printing them out on a small |
| 37:49 | piece of paper so it's literally putting |
| 37:51 | every hash on on paper and it was so |
| 37:53 | slow it was ridiculous to watch |
| 37:56 | but |
| 37:56 | then again isn't it amazing that even a |
| 37:59 | small calculator could |
| 38:01 | i know it's not practical but it is |
| 38:03 | theoretically possible that this |
| 38:04 | calculate their minds a bitcoin block |
| 38:07 | yeah that just has this potential here |
| 38:10 | and this is something that you entirely |
| 38:12 | lose with proof of stake there is |
| 38:13 | nothing like this in proof of stake and |
| 38:16 | it's an entire paradigm shift that is um |
| 38:20 | it's just not an easy move when i i |
| 38:22 | understand that many people call for |
| 38:24 | example for bitcoin to also move to |
| 38:26 | proof of stake and then this entire |
| 38:28 | energy consumption |
| 38:30 | debate that everyone hates so much uh |
| 38:32 | kicks off again but then again ask |
| 38:34 | yourself what is the alternative and i |
| 38:36 | believe proof of stake is not uh |
| 38:40 | a good replacement for proof of work in |
| 38:42 | terms of |
| 38:43 | their |
| 38:44 | the features it gives you |
| 38:46 | and to to your question with regard uh |
| 38:49 | is the ethereum merch would totally |
| 38:51 | happen because there i have been |
| 38:53 | contributing to some of the issue to |
| 38:55 | work in the last two years |
| 38:57 | and |
| 38:58 | um i kind of stopped contributing |
| 39:00 | because it was |
| 39:02 | it's such a difficult uh development |
| 39:05 | environment |
| 39:06 | people are like very competitive uh you |
| 39:09 | you can feel that there is a huge |
| 39:11 | pressure on ethereum to deliver proof of |
| 39:14 | stake because it has been promised since |
| 39:16 | i don't know six years |
| 39:18 | um because this repeated bitcoin energy |
| 39:22 | consumption or eco energy consumption |
| 39:23 | debate they just |
| 39:25 | want to ship it no matter what what it |
| 39:27 | costs and it will happen i cannot tell |
| 39:30 | when it will definitely happen |
| 39:32 | um |
| 39:33 | i have mixed feelings |
| 39:36 | about this um |
| 39:37 | and with regards to will miners continue |
| 39:40 | mining the uh |
| 39:43 | proof of work chain |
| 39:44 | i don't think so |
| 39:46 | for different reasons because the reason |
| 39:49 | number one is that |
| 39:50 | the difficulty bomb is still something |
| 39:52 | that would |
| 39:53 | uh would have to be removed actively so |
| 39:56 | this means |
| 39:57 | in in addition to the merge you would |
| 39:59 | also have an active actively proposed |
| 40:03 | hard fork to remove the difficulty bone |
| 40:05 | bomb and in this in this |
| 40:08 | because you have to actively propose it |
| 40:10 | you need to come up with a name you |
| 40:11 | would have to call it estrogen classic |
| 40:12 | classic or ethereum classic two or |
| 40:14 | whatever and this is what people will |
| 40:17 | not accept as real ethereum or ethereum |
| 40:19 | classic or issue classic two or whatever |
| 40:21 | you would call it |
| 40:22 | and the other thing is that i believe |
| 40:25 | that |
| 40:25 | because this entire assumed ecosystem is |
| 40:28 | so keen on delivering proof of stake and |
| 40:31 | i don't know how many million e's have |
| 40:33 | been deposited onto the beacon chain |
| 40:35 | already |
| 40:36 | it is basically we are beyond that uh |
| 40:38 | point of uh |
| 40:40 | return and uh |
| 40:42 | ethereum will certainly move to to the |
| 40:46 | proof-of-stake consensus algorithm for |
| 40:48 | sure whenever this will happen i don't |
| 40:50 | know but um i don't think there is any |
| 40:53 | proof of work future in the ethiopian |
| 40:56 | foundation network and if these miners |
| 40:59 | will actually move to ecom classic this |
| 41:01 | is something we will have to see |
| 41:03 | but fact is that there are not so many |
| 41:07 | proof-of-stake |
| 41:08 | systems left and |
| 41:10 | it's uh i'm sorry proof of work and um |
| 41:13 | bitcoin is the biggest proof of work |
| 41:15 | network and what comes next |
| 41:18 | right now it's ethereum but what will be |
| 41:19 | the next one after ethereum switches to |
| 41:21 | proof of stake we don't know we there is |
| 41:23 | a lot of hash rate that needs to be |
| 41:24 | redistributed and uh we cannot really |
| 41:27 | tell but if you scroll a coin market cap |
| 41:30 | like by |
| 41:32 | or coin gekko whatever metrics you use |
| 41:34 | most of the top coins are |
| 41:36 | actually moving towards proof of stake |
| 41:39 | and |
| 41:39 | it does not leave many options for |
| 41:41 | miners or mining hardware |
| 41:43 | right i even heard that dogecoin is |
| 41:45 | planning a switch to prove a stake or |
| 41:46 | something it's uh kind of surprising and |
| 41:49 | uh yeah i would add that the uh the |
| 41:51 | whole defy ecosystem |
| 41:53 | is basically |
| 41:54 | the deciding factor i think in terms of |
| 41:56 | where the value is going to shift and it |
| 41:58 | seems like it's in their interest if |
| 41:59 | they are holding ether to go to staking |
| 42:02 | i think a lot of them seem to believe |
| 42:04 | that |
| 42:05 | they can reap the rewards of staking |
| 42:09 | and get that value that miners would be |
| 42:10 | providing |
| 42:12 | um so |
| 42:13 | so |
| 42:14 | in terms of if there was a |
| 42:17 | an exodus of miners looking for other |
| 42:19 | chains this would mean there's a lot of |
| 42:21 | hash rate going around um as you |
| 42:23 | mentioned and there are some people in |
| 42:26 | the shah 3 debate they're saying that |
| 42:28 | this is a very dangerous thing for |
| 42:30 | ethereum classic because uh ethereum |
| 42:33 | classic will no longer be profitable for |
| 42:34 | most miners and the latent hash rate is |
| 42:37 | just going to be used to 51 attack the |
| 42:39 | chain do you think that's a a reasonable |
| 42:42 | possibility or do you think they're more |
| 42:44 | likely to just honestly mind the chain |
| 42:47 | um i mean to answer this question you |
| 42:49 | need to speculate a lot i would argue |
| 42:52 | that |
| 42:53 | 51 |
| 42:55 | attacks are very involved and it's it |
| 42:58 | happened to assume classic it happened |
| 42:59 | to other chains it it will certainly |
| 43:02 | happen in future again whenever whenever |
| 43:05 | someone believes the effort you put in |
| 43:07 | there is worse the risks you are taking |
| 43:10 | and |
| 43:11 | the 51 attack is much more complex than |
| 43:14 | having 51 percent of the network hash |
| 43:16 | rate is much more complex because you |
| 43:17 | also need to to have someone you can |
| 43:20 | double spend on you need some |
| 43:22 | smaller or mid size exchange that you |
| 43:24 | can execute these uh attacks on and this |
| 43:27 | is this comes with a lot of work so i |
| 43:31 | believe there is a fair amount of miners |
| 43:33 | that just does not care as long as they |
| 43:35 | get more coins out of it than they pay |
| 43:38 | on electricity then they would rather |
| 43:41 | mine |
| 43:42 | honestly than go through this uh extra |
| 43:45 | mile |
| 43:46 | of preparing and executing a very risky |
| 43:49 | 51 |
| 43:51 | attack |
| 43:51 | right thanks for your perspective on |
| 43:53 | that it's uh it's good to add some |
| 43:54 | additional viewpoints into this debate |
| 43:57 | now |
| 43:58 | um |
| 43:59 | we're nearing the end of the pre-planned |
| 44:01 | questions and i will open this up to the |
| 44:03 | chat shortly but i just wanted to end on |
| 44:06 | a kind of open thing for you efforty |
| 44:08 | what are you up to these days and is |
| 44:10 | there anything you wanted to add to this |
| 44:12 | discussion or wanted to mention a shout |
| 44:14 | out or something like that |
| 44:16 | uh that's uh that's a great question um |
| 44:18 | i mean i'm i'm working at chainsafe now |
| 44:21 | chainsaw systems is |
| 44:23 | it's a blockchain |
| 44:26 | company development company that is very |
| 44:29 | chain agnostic and this is something i |
| 44:31 | really appreciated i i have been |
| 44:34 | in bitcoin for so long i have been |
| 44:36 | experimenting and developing four so |
| 44:39 | many different altcoins i have been in |
| 44:41 | this room i've been in the siom classic |
| 44:43 | uh |
| 44:44 | i i have i tried to launch the poker |
| 44:46 | parachainers it's just the the system |
| 44:49 | ecosystem is so interesting to just be |
| 44:52 | limited to one project and i would just |
| 44:55 | i would just say everyone should be open |
| 44:57 | to to all the projects and just you can |
| 45:00 | easily build on multiple blockchains if |
| 45:03 | you want to and you should not be sold |
| 45:05 | to one solution in first place and this |
| 45:08 | is something |
| 45:09 | i appreciate about working at chainsafe |
| 45:11 | i can work on many different blockchain |
| 45:14 | ecosystems in many different programming |
| 45:16 | languages without being sold or |
| 45:19 | sold out to one solution and |
| 45:22 | this is something i would just leave |
| 45:24 | here for everyone to i don't know |
| 45:26 | appreciate it or hate me for that um |
| 45:28 | this is something i i do right now |
| 45:31 | and in my free time i actually started |
| 45:33 | to work on evm tooling i'm maintaining |
| 45:37 | i took over maintaining the ruby cerium |
| 45:40 | gem so if any one of you builds |
| 45:43 | applications in ruby |
| 45:45 | or on rails and uh hit me up |
| 45:48 | it has ethereum classic support |
| 45:51 | um |
| 45:52 | yeah that's that's what i do right now |
| 45:54 | awesome um and i know the chain save guy |
| 45:57 | is a fellow team and uh doing really |
| 45:59 | good work and i would add that i think |
| 46:02 | that |
| 46:02 | whilst uh we all love ethereum classic |
| 46:04 | it's um |
| 46:05 | really it's the end goal that matters |
| 46:07 | and if that means then |
| 46:10 | using other chains and connecting the |
| 46:11 | chains i think the future is a |
| 46:14 | multi-chain system so i think you're |
| 46:16 | you're right on the money with that |
| 46:18 | so yeah uh |
| 46:19 | thank you afri for answering these uh |
| 46:22 | pre-planned questions um and if we have |
| 46:25 | time i would now like to open the floor |
| 46:27 | up to some |
| 46:28 | other questions from some community |
| 46:30 | members if there are any |
| 46:33 | yes i have a question |
| 46:35 | okay |
| 46:37 | what what do you think |
| 46:39 | may happen to ethereum classic ecosystem |
| 46:43 | if |
| 46:45 | if a chain split would happen a |
| 46:48 | permanent jstip |
| 46:49 | in case one side |
| 46:52 | moves to chattery and the other one |
| 46:55 | continues to |
| 46:56 | to mine the current algorithm |
| 46:59 | um just look at bitcoin cash and |
| 47:02 | bitcoin as we i would say it's it's |
| 47:05 | always possible and it's uh i mean we |
| 47:07 | have to appreciate this |
| 47:09 | this opportunity that |
| 47:11 | communities if there is no rough |
| 47:14 | consensus or is there no consensus at |
| 47:16 | all it's always it's always a feature i |
| 47:18 | would say that communities can just fork |
| 47:21 | off |
| 47:22 | if if this um |
| 47:24 | etc hatch versus charge three |
| 47:26 | debate can never be resolved it i mean |
| 47:29 | it might be even healthy for the |
| 47:31 | ecosystem to create |
| 47:32 | two smaller ecosystems or communities |
| 47:35 | that uh not only separate uh logically |
| 47:38 | but also technically |
| 47:40 | um |
| 47:41 | of course |
| 47:42 | it has shown in the past that there will |
| 47:45 | be always one strong |
| 47:47 | side of the chain and one at |
| 47:49 | one more week |
| 47:51 | fork so |
| 47:53 | i would not encourage to |
| 47:56 | uh to split the chain over consensus |
| 47:58 | issues but |
| 48:00 | in |
| 48:00 | in the last |
| 48:02 | uh |
| 48:03 | the last step you could always do this |
| 48:04 | and consider individuals would not be |
| 48:05 | afraid of forking or splitting if there |
| 48:08 | is no other way |
| 48:10 | but uh but in terms of |
| 48:12 | daffy |
| 48:13 | or nfts |
| 48:16 | or the apps |
| 48:18 | how do you see this |
| 48:20 | this change |
| 48:22 | yeah it's very involved everyone |
| 48:24 | not only node operators or miners have |
| 48:27 | to make a decision which chains they |
| 48:29 | want to support but also everyone in |
| 48:30 | communities includes developers of |
| 48:33 | applications of |
| 48:35 | decentralized exchanges d5 |
| 48:37 | everyone has to make call and um i know |
| 48:41 | i remember an issue foundation network |
| 48:43 | there where this risk of |
| 48:46 | i remember when when the parity multisec |
| 48:49 | was hacked there was a strong debate |
| 48:52 | what what if parity just forks this |
| 48:54 | theorem and unlocks their |
| 48:57 | unlocks their funds on a minority chain |
| 48:59 | and everyone was like |
| 49:01 | freaking out about uh the impact on |
| 49:04 | on applications from metamask over |
| 49:07 | stable coins such as die what happens to |
| 49:09 | a forked stable coin and i know this is |
| 49:11 | like very involved and that's in first |
| 49:14 | place why it should be avoided they |
| 49:16 | should rough consensus should be always |
| 49:18 | the ultimate goal |
| 49:19 | but that said as i said there is always |
| 49:22 | this opportunity to decide to make this |
| 49:25 | final decision to say okay |
| 49:27 | we want this feature so hard that we are |
| 49:30 | willing to fork off and then everyone |
| 49:33 | needs to make the call will |
| 49:36 | will your stay let's assume you uh have |
| 49:39 | a defy stable coin will you support it |
| 49:41 | on |
| 49:42 | network a or network b or will you even |
| 49:44 | go that far that you should support it |
| 49:46 | on both sides |
| 49:48 | um |
| 49:49 | contentious |
| 49:50 | uh hard forks are always |
| 49:53 | a very difficult task to pull off and |
| 49:55 | many people lost many many people lost |
| 49:58 | money in the dao hard fork for example |
| 50:01 | when nissium foundation patched uh a |
| 50:04 | protocol and there was replay detections |
| 50:07 | on replay attacks on ethereum classic |
| 50:10 | and this one classic was forced to |
| 50:11 | [Music] |
| 50:13 | implement a different chain id |
| 50:15 | it's always not recommended but it's |
| 50:17 | still a possible route |
| 50:20 | thank you another question is |
| 50:23 | related to |
| 50:24 | the treasury debate |
| 50:26 | what are your thoughts on |
| 50:29 | on attacks for miners |
| 50:32 | for |
| 50:34 | for getting basically money to |
| 50:37 | to fund development improvements |
| 50:40 | uh research |
| 50:42 | and stuff like that |
| 50:44 | um |
| 50:45 | this is a very nuanced question the the |
| 50:48 | general sentiment i would say it's |
| 50:50 | always good to have funding for |
| 50:51 | ecosystem is always it's it's crucial to |
| 50:54 | have funding for developers especially |
| 50:56 | for core development |
| 50:57 | um |
| 50:58 | the |
| 50:59 | treasury proposals we've seen we've seen |
| 51:02 | on issue classic |
| 51:03 | were kind of controversial |
| 51:06 | and this is mainly because of |
| 51:08 | the power that comes with this |
| 51:10 | responsibility uh |
| 51:12 | this |
| 51:13 | potential of abuse that could be |
| 51:15 | introduced so the question is less of a |
| 51:18 | technical one but more of the governance |
| 51:20 | question how do you |
| 51:22 | how how much money do you put where |
| 51:25 | who is controlling who gets money uh how |
| 51:28 | do you make change to the system and i |
| 51:31 | was in the beginning i was following |
| 51:32 | this debate closely and i was another |
| 51:35 | impression this was going completely |
| 51:37 | backwards that some stakeholders and |
| 51:39 | ecosystem tried to fill their own |
| 51:41 | pockets |
| 51:42 | based on those proposals so i believe |
| 51:45 | it's |
| 51:46 | better to have no treasury than |
| 51:48 | something like that that was proposed |
| 51:50 | back in the day |
| 51:52 | but then again it's always good to |
| 51:53 | explore |
| 51:55 | um |
| 51:56 | ways to fund development long term |
| 51:59 | and communities should not be afraid of |
| 52:03 | doing so |
| 52:04 | and you could always i mean islam |
| 52:06 | classic has a very strictly defined |
| 52:08 | monetary policy you could always revise |
| 52:10 | this but this is something you need to |
| 52:12 | do with the entire community together |
| 52:15 | you need to clearly define the goals who |
| 52:17 | should be funded how much funding is |
| 52:19 | acceptable also how much can you take |
| 52:21 | away from miners |
| 52:23 | or will you create additional block |
| 52:24 | rewards that not go to miners but to a |
| 52:26 | treasury |
| 52:28 | however you call it however you map it |
| 52:29 | out you need to be very careful and i |
| 52:31 | would not say it should not be done but |
| 52:33 | it's very difficult to do it in a fair |
| 52:35 | way and eventually |
| 52:37 | all mechanisms of governments around us |
| 52:41 | in the end are very messy let's face it |
| 52:44 | thank you this is my last question |
| 52:47 | um |
| 52:48 | do you they think that the developers |
| 52:51 | are |
| 52:52 | are now |
| 52:54 | scared of |
| 52:55 | coming to edc or |
| 52:58 | they just bypass it and |
| 53:01 | develop on ethereum |
| 53:03 | because there there is more money there |
| 53:06 | and more users what what they think it's |
| 53:10 | uh |
| 53:11 | it's a slowing development for etc |
| 53:15 | oh yeah that's an interesting question i |
| 53:16 | mean |
| 53:17 | there was a time |
| 53:19 | when ethereum clearly didn't scale |
| 53:22 | when the econ foundation network was so |
| 53:25 | contested that um |
| 53:27 | that you had to pay |
| 53:30 | thousands of dollars to get a |
| 53:32 | transaction broadcasters brought uh |
| 53:34 | broadcast and included in the blog |
| 53:36 | this was a time before layer 2 was a |
| 53:39 | thing when |
| 53:40 | side chains uh were seeing like uh i |
| 53:44 | would say poa network was an interesting |
| 53:46 | example x die these are all chains that |
| 53:49 | were created well after ethereum existed |
| 53:52 | issue classic existed |
| 53:53 | um was the ultimate goal to provide a |
| 53:57 | cheaper alternative in parallel to the |
| 53:59 | issue foundation network |
| 54:01 | this is something i've always believed |
| 54:02 | was a huge chance for ethereum classic |
| 54:05 | that's why i also tried to assist in |
| 54:08 | bringing issue classic back to protocol |
| 54:10 | parity so that ethereum |
| 54:12 | developers could also have this option |
| 54:14 | to not only deploy to one chain but to |
| 54:16 | choose which chain they deployed on |
| 54:19 | and eventually in the end this never |
| 54:22 | worked out and i believe this is always |
| 54:24 | complicated because |
| 54:26 | the differences between |
| 54:28 | assume classic and assume foundation |
| 54:30 | networks are not only |
| 54:32 | of technical nature but also in |
| 54:33 | political nature and people rather |
| 54:36 | decided to deploy applications on extern |
| 54:38 | network or it's called nosos network now |
| 54:42 | because they believed they don't or they |
| 54:45 | didn't want to get involved in politics |
| 54:48 | because the moment you move an |
| 54:50 | application from issue foundation |
| 54:51 | network to assume classic network it |
| 54:53 | could it doesn't necessarily have to be |
| 54:56 | but it could look like to outsiders as a |
| 54:58 | political act and this is probably |
| 55:00 | something that prevented a lot of |
| 55:02 | applications to |
| 55:04 | experiment with issue classic in first |
| 55:05 | place |
| 55:07 | today i would say it's a bit more it's a |
| 55:09 | different situation because now we see |
| 55:12 | layer twos coming up so |
| 55:14 | layer ones in general |
| 55:16 | lose |
| 55:17 | relevance a little bit uh at least from |
| 55:20 | an application perspective so |
| 55:22 | in 2022 i would say it's really it's |
| 55:25 | even more difficult for his home classic |
| 55:27 | to attract developers |
| 55:29 | thank you |
| 55:31 | i just wanted to |
| 55:32 | because kevin i just got a quick uh |
| 55:35 | question kevin could i just quickly jump |
| 55:37 | in here um |
| 55:39 | i i previously um |
| 55:41 | just wanted to |
| 55:43 | allow henry because he has a a hardcore |
| 55:45 | offline to quickly make a comment about |
| 55:48 | his uh his white paper before he leaves |
| 55:50 | and then we can get back to the q a if |
| 55:52 | that's possible |
| 55:53 | cool |
| 55:55 | great thanks um thanks everybody for the |
| 55:58 | opportunity um |
| 55:59 | i've been listening to the |
| 56:01 | you know i've been involved in the |
| 56:02 | discussions |
| 56:04 | you know about the fork to shaw three |
| 56:06 | you know all the implications on the |
| 56:08 | ecosystem you know people's thoughts |
| 56:10 | about |
| 56:11 | security and whatnot and um |
| 56:15 | you know while i really appreciate the |
| 56:17 | work that alex did and want to see |
| 56:20 | etc succeed you know with a more secure |
| 56:24 | proof of work chain i think that the |
| 56:26 | differences are |
| 56:28 | hard to hard to bridge |
| 56:31 | you know we've seen that repeatedly |
| 56:33 | through all the other gpu communities |
| 56:36 | you know ethereum being a good example |
| 56:38 | of the |
| 56:40 | threat you know their stance against |
| 56:42 | asics |
| 56:43 | nevertheless in this case |
| 56:45 | you know there's a threat of a big |
| 56:47 | onslaught of hardware that comes in that |
| 56:50 | will |
| 56:51 | that will be |
| 56:52 | basically will render mining |
| 56:53 | unprofitable and uh you know i |
| 56:56 | personally feel that ethereum classic |
| 56:59 | needs to make some changes so um looking |
| 57:02 | at other networks and |
| 57:04 | you know how |
| 57:07 | i came up with the |
| 57:08 | uh stole this idea from grand ashley and |
| 57:11 | you know from |
| 57:13 | from some of the ongoing work of monero |
| 57:15 | is came out with a scheme for dual proof |
| 57:18 | of work where the |
| 57:20 | we have the ability for gp existing etc |
| 57:23 | hash to coexist with |
| 57:25 | pacheck and really the what this does is |
| 57:29 | allows existing miners on gpus to |
| 57:32 | continue mining and then adds a nuclear |
| 57:35 | security with the |
| 57:37 | sha-3 |
| 57:38 | chains and are proof of work the you |
| 57:41 | know |
| 57:42 | adding the sha-3 will basically render a |
| 57:46 | lot of the gpus |
| 57:48 | will make the chain more secure because |
| 57:51 | you know each |
| 57:52 | each gpu |
| 57:54 | is equal to about |
| 57:56 | you know 10 |
| 57:58 | somewhere between 10 and 30 fpga so |
| 58:00 | right away you've got a new class of |
| 58:02 | hardware that can come in and bolster |
| 58:03 | security and uh you know if you divide |
| 58:06 | the divide the proof of work in half |
| 58:09 | then basically it makes it impossible to |
| 58:12 | attack this also addresses the issues |
| 58:14 | around silicon right difficulty |
| 58:17 | because there's a lot of concern about |
| 58:19 | the initial setting the initial |
| 58:20 | difficulty on shaw three could check and |
| 58:23 | that could disrupt the chain if the |
| 58:25 | difficulty is too high or too low as we |
| 58:27 | saw in other chains so um you know we |
| 58:30 | took a look at |
| 58:31 | work that's been done in other chains |
| 58:33 | and really came to thought that this |
| 58:36 | would be the best for the community i |
| 58:38 | put together white paper that describes |
| 58:41 | you know |
| 58:42 | what other chains are doing and how etc |
| 58:44 | might want to do it and then i've also |
| 58:46 | answered on an faq at the back of the |
| 58:49 | white paper |
| 58:51 | you know concerns i heard from the |
| 58:52 | community like what happens is there |
| 58:55 | risk of a chain split you know what kind |
| 58:56 | of |
| 58:57 | what kind of hardware is out there you |
| 58:59 | know is it unprofitable mine and so |
| 59:02 | there's i think if i remember there's |
| 59:04 | about 10 questions i answered and you |
| 59:07 | know i welcome |
| 59:08 | discussion with the community to |
| 59:11 | try and improve |
| 59:13 | etc and especially on the security side |
| 59:16 | so look forward to everyone's comments |
| 59:17 | uh next week uh in the meantime we've |
| 59:20 | posted this on github there's a link and |
| 59:22 | i look forward to people's input |
| 59:26 | thanks henry and yeah um |
| 59:28 | you can find the link on the agenda of |
| 59:29 | this community call and we will be uh |
| 59:32 | looking at that in detail next week so |
| 59:34 | uh thank you over to you |
| 59:36 | to you kevin |
| 59:37 | okay sorry can i before i go can i ask |
| 59:39 | after your question oh yeah sure go |
| 59:41 | ahead |
| 59:42 | hey afraid henry um good to hear from |
| 59:44 | you thanks for insight on on the hard |
| 59:46 | fourth we've always wondered what goes |
| 59:48 | on in the background uh my question is |
| 59:50 | related to ethereum |
| 59:53 | what do you think the chances are of a |
| 59:55 | 1.0 fork |
| 59:57 | and you know it does pose a lot of |
| 59:59 | difficulties |
| 60:00 | for people trying to carry on the 1.0 |
| 60:02 | chain as |
| 60:03 | they have to try and maintain |
| 60:05 | the for 2.0 chain which is hard to do |
| 60:09 | and then we've also got the |
| 60:11 | you know threat of the ice age and the |
| 60:13 | higher difficulty that the core does |
| 60:16 | from ethereum can impose |
| 60:18 | uh hey henry thank you for this question |
| 60:20 | um |
| 60:21 | as i said earlier i believe the |
| 60:23 | chances for an |
| 60:25 | east one fork are very long for multiple |
| 60:28 | reasons so the one reason is that |
| 60:31 | removing the difficulty bomb would be an |
| 60:33 | active fork you would have to actively |
| 60:36 | fork against the merch you cannot only |
| 60:38 | maintain the status quo and lean back |
| 60:40 | and say we are the original econ |
| 60:42 | foundation network but you would |
| 60:44 | actively have to oppose what |
| 60:46 | not not not two not three but like eight |
| 60:49 | or nine client teams have been working |
| 60:51 | on for several years so um this is see |
| 60:55 | one thing and the other thing is that i |
| 60:57 | believe that miners really don't care |
| 61:01 | too much politically about how |
| 61:04 | a network evolves i mean they are not |
| 61:06 | very happy about the move to proof of |
| 61:08 | stake but i also believe they will not |
| 61:10 | necessarily mine a debt chain because |
| 61:13 | they also have to pay energy bills in |
| 61:15 | the end and the risk that these coins |
| 61:17 | are |
| 61:18 | worthless are fairly high and also i |
| 61:21 | mean technically proof of fake has |
| 61:22 | always been only assumed |
| 61:24 | is on the ethereum |
| 61:27 | roadmap so it's really really difficult |
| 61:29 | to argue that |
| 61:31 | there is |
| 61:32 | um |
| 61:33 | some value behind this is one proof of |
| 61:36 | work fork coins i know does this make |
| 61:39 | sense |
| 61:40 | yes it does thank you very much i i |
| 61:41 | missed the i guess i missed the part |
| 61:43 | about the dead chain um but that was a |
| 61:45 | that was a valuable contribution thanks |
| 61:47 | for that |
| 61:48 | also um i wanted to comment on your |
| 61:50 | paper uh |
| 61:52 | i haven't read it but |
| 61:53 | uh we had early ideas about when this |
| 61:56 | chart three debate um i mean we have |
| 61:58 | been having this debate for what two or |
| 62:00 | three years now and there was always |
| 62:02 | this notion of |
| 62:04 | what if we had a transition phase where |
| 62:06 | we have both |
| 62:07 | uh consensus algorithms |
| 62:10 | available so i would be really curious |
| 62:12 | to read about your paper also about the |
| 62:14 | implications or how you balance out both |
| 62:16 | algorithms would be really interesting |
| 62:18 | to learn more about this look forward to |
| 62:20 | input on that effort |
| 62:23 | okay so anyways aubrey this is kevin |
| 62:26 | again i just wanted to uh thank you for |
| 62:29 | to continuing to contribute to this |
| 62:31 | project |
| 62:32 | um it's pretty |
| 62:34 | it's pretty uh noble of you but um |
| 62:38 | about |
| 62:41 | a potential |
| 62:43 | switch of the mining algorithm |
| 62:46 | like |
| 62:47 | i totally agree with you with the the |
| 62:49 | you know the the bit mains or bit means |
| 62:52 | user activated hard fork and then be |
| 62:55 | cash and then |
| 62:56 | you know segwit2x and |
| 62:59 | none of that really ever |
| 63:01 | happened because there just wasn't |
| 63:03 | um you know what you were talking about |
| 63:06 | like there wasn't any um you know |
| 63:09 | other clients available but |
| 63:12 | i think you make some really good points |
| 63:13 | i think a lot a lot more people should |
| 63:15 | um |
| 63:16 | should listen |
| 63:18 | to you more often |
| 63:19 | and um |
| 63:21 | yeah thanks for for um |
| 63:23 | being |
| 63:24 | being around |
| 63:25 | well thanks for having me |
| 63:27 | it's not up to me |
| 63:29 | i mean it's still interesting |
| 63:30 | developments on ethereum classic uh i'm |
| 63:33 | really curious to see how it |
| 63:35 | moves works out |
| 63:37 | i'm also interested about um i didn't |
| 63:39 | really follow but how your discussion |
| 63:42 | around the |
| 63:43 | 1559 concluded in the end i i just saw |
| 63:47 | today that you eventually decided not to |
| 63:49 | include it i mean i i |
| 63:51 | know that you never wanted to include it |
| 63:54 | and it makes totally sense not to |
| 63:55 | include but like not having type two |
| 63:57 | transaction types |
| 63:59 | or a base fee up code for compatibility |
| 64:02 | um it's that's still interesting because |
| 64:05 | now we are leaving basically we are |
| 64:06 | leaving the the |
| 64:08 | the field of protocol parity a little |
| 64:10 | bit |
| 64:11 | yeah most definitely uh |
| 64:14 | would would you |
| 64:15 | say |
| 64:16 | or |
| 64:17 | think |
| 64:19 | you know maybe ethereum is sort of like |
| 64:22 | a test net for ethereum classic |
| 64:25 | in a sense |
| 64:26 | in a sense maybe i i mean it's |
| 64:29 | they have a lot of new features and a |
| 64:31 | lot of users that test these features |
| 64:33 | and in the end assume classic can just |
| 64:35 | cherry pick and technically that's what |
| 64:38 | sim classic has done in the last years |
| 64:40 | yeah uh i would i would at in 2022 i |
| 64:43 | would even argue it might be worth |
| 64:45 | revisiting uh the the monetary policy of |
| 64:48 | issuing classic under the circumstances |
| 64:50 | of uh burning minor fees |
| 64:53 | as it happens with eip |
| 64:56 | 1559 but this is i'm just i'm more |
| 65:00 | interested about the technical |
| 65:01 | implications but i'm not really |
| 65:04 | following or thinking about economic |
| 65:06 | implications so just i'm not really |
| 65:08 | opinionated about it i'm just coming |
| 65:10 | more from an application or tooling |
| 65:12 | developer and |
| 65:13 | seeing that ethereum classic will not |
| 65:15 | really support type 2 transactions which |
| 65:18 | most of the |
| 65:20 | evm tooling is moving towards uh to make |
| 65:23 | a default |
| 65:24 | yeah that was actually one of the |
| 65:26 | concerns uh |
| 65:28 | at the very beginning of the monetary |
| 65:30 | policy debate was that |
| 65:34 | that is to |
| 65:35 | happen eventually um you know there's |
| 65:38 | not going to be |
| 65:39 | you know |
| 65:41 | the the |
| 65:42 | mining rewards there to be sufficient |
| 65:45 | for developers to develop |
| 65:48 | so i think for sure that'll probably be |
| 65:50 | revisited because uh from what i |
| 65:53 | understand and all the research i've |
| 65:54 | looked at everything i've seen um it was |
| 65:57 | geared more towards |
| 65:59 | the investor side so |
| 66:01 | it'll be interesting to see the |
| 66:04 | developer side |
| 66:05 | share their thoughts and opinion on that |
| 66:08 | yeah totally |
| 66:09 | with regards to the the base fee uh |
| 66:12 | opcode lack of support |
| 66:14 | i'm also not sure why that was |
| 66:16 | intentionally avoided i think it was |
| 66:18 | rejected from the mystique fork right |
| 66:20 | but um maybe it will be added later on |
| 66:23 | and potentially if ethereum classic |
| 66:26 | implements a versioning system then that |
| 66:28 | could also be added as one of the many |
| 66:31 | evm versions that it supports |
| 66:34 | yeah i think the reasoning was that |
| 66:36 | by |
| 66:37 | by not completely implementing 1559 |
| 66:42 | this opens up a lot of unknown |
| 66:45 | vectors because you would have to |
| 66:47 | partially implement it and change the |
| 66:50 | way it is supposed to work and |
| 66:52 | by even even setting base feed to zero |
| 66:54 | or |
| 66:55 | hard codings certain aspects that we |
| 66:57 | don't want means introducing a lot of |
| 67:00 | complexity and this is probably the |
| 67:02 | reason |
| 67:02 | for convenience that you just or the |
| 67:05 | quarterback decided against implementing |
| 67:06 | it and makes makes sense from a |
| 67:08 | technical perspective but |
| 67:10 | um looking at all |
| 67:13 | as i said i'm coming from a developer |
| 67:15 | perspective from a tooling developer |
| 67:17 | perspective |
| 67:18 | that most wallets move towards and i |
| 67:21 | mean issue foundation network is the |
| 67:23 | biggest evm network we have to admit |
| 67:25 | this and |
| 67:26 | they in most cases default to type 2 or |
| 67:29 | like eip 1559 transactions by default |
| 67:33 | because it is |
| 67:35 | otherwise it would be |
| 67:37 | a waste of transaction fees on the issue |
| 67:40 | network and therefore it could con |
| 67:44 | could further broaden the gap between |
| 67:47 | ethereum and the assume classic and make |
| 67:48 | it more difficult for assume |
| 67:51 | developers to |
| 67:52 | build and deploy applications on the |
| 67:54 | same classic |
| 67:55 | i see so this is a compatibility |
| 67:57 | compatibility issue that will affect uh |
| 68:00 | wallet and message signing primarily or |
| 68:03 | transaction construction as opposed to |
| 68:06 | contract authoring is that correct yes |
| 68:08 | this is basically about |
| 68:11 | how |
| 68:11 | transactions look like um |
| 68:13 | but i mean ethereum classic so there are |
| 68:16 | transaction envelopes i don't know how |
| 68:18 | familiar you are this is |
| 68:20 | there are legacy transactions that are |
| 68:21 | basically just uh |
| 68:24 | the most |
| 68:25 | simple way to |
| 68:26 | have a transaction on an evm network and |
| 68:30 | these basically get wrapped in an |
| 68:32 | envelope and and ethereum classic |
| 68:34 | already has this feature there are so |
| 68:35 | called type 1 transactions that have |
| 68:37 | this feature so you could maybe also |
| 68:40 | have a different type two |
| 68:42 | implementations that just |
| 68:44 | maps i don't know max priority fee to |
| 68:47 | guess |
| 68:48 | price or something like that just |
| 68:49 | because the only difference between |
| 68:52 | eip1559 transactions from a transaction |
| 68:55 | perspective to |
| 68:56 | to legacy transaction also called type |
| 68:59 | zero transaction is that you have two |
| 69:02 | different |
| 69:03 | types of gas price |
| 69:05 | looks like something that's worth |
| 69:06 | looking at for future updates and uh |
| 69:09 | definitely to keep track of in terms of |
| 69:11 | as you say like diverging from |
| 69:13 | compatibility be a real shame if one one |
| 69:16 | of the major libraries for example |
| 69:18 | stopped working with ethereum classic |
| 69:24 | i have one question about |
| 69:26 | the timing of |
| 69:28 | parts of a heart fork |
| 69:30 | if we look at the |
| 69:32 | final stages of a hard fork then |
| 69:34 | there are things like having a feature |
| 69:36 | freeze for all the things that should go |
| 69:38 | into it |
| 69:39 | then |
| 69:41 | a point where all the |
| 69:42 | relevant code should be stable |
| 69:45 | and |
| 69:46 | once you've reached that then i guess |
| 69:48 | the next step would be to to set the |
| 69:51 | to set that a square transition block |
| 69:53 | just schedule the when the hard work |
| 69:55 | will happen and make an announcement and |
| 69:58 | um |
| 70:00 | well first of all do i get this this |
| 70:02 | sequence right would you |
| 70:04 | do things in a different order and the |
| 70:06 | second question would be then um how |
| 70:09 | much time would pass between the |
| 70:11 | announcement and the actual forks how |
| 70:14 | much time do people in general need |
| 70:16 | um |
| 70:17 | to do the |
| 70:19 | i mean like like exchange operators and |
| 70:21 | such and or maybe wallet developers who |
| 70:25 | haven't been |
| 70:27 | haven't paid attention yet how much time |
| 70:29 | do they need |
| 70:30 | after the announcement to to get right |
| 70:33 | out there on their side |
| 70:35 | um that's that's a very interesting |
| 70:37 | question so |
| 70:38 | um |
| 70:39 | as always there's no general rule to |
| 70:42 | this and um |
| 70:44 | that has a lot of moving parts here that |
| 70:46 | uh |
| 70:47 | need to work together correctly in case |
| 70:51 | to |
| 70:52 | ensure that the the the hard fork will |
| 70:55 | execute properly on a given timeline i |
| 70:58 | personally always |
| 71:00 | coordinated uh hard forked backboards so |
| 71:04 | if you would task me with coordinating a |
| 71:06 | hard fork on ethereum classic today i |
| 71:08 | would say okay let's do it in june |
| 71:11 | that's that's |
| 71:12 | five months that's the |
| 71:14 | i think the minimum time |
| 71:16 | um |
| 71:17 | the minimum convenient time to execute a |
| 71:19 | hard fork if you already know what the |
| 71:21 | features are then you would have to go |
| 71:23 | uh through governance and i would this |
| 71:25 | entire process of implementing it and |
| 71:27 | testing it and finding rough consensus |
| 71:30 | something that can be executed in |
| 71:31 | parallel that is not blocked by |
| 71:34 | timing a hard fork |
| 71:36 | because you can always adjust dates |
| 71:39 | later but |
| 71:40 | ideally you don't want to adjust dates |
| 71:42 | too often so it will create confusion |
| 71:44 | between |
| 71:46 | node runners miners exchanges you want |
| 71:49 | to avoid announcing dates before you |
| 71:51 | actually know |
| 71:53 | uh when you want to so let's assume |
| 71:55 | you want to you have five or six months |
| 71:57 | time now in advance to plan and execute |
| 71:59 | this fork then you basically go |
| 72:02 | backwards to say uh let's let's talk on |
| 72:04 | wednesday the june uh 21st of june and |
| 72:08 | then you go backwards okay you want to |
| 72:10 | have at least six if not eight |
| 72:13 | weeks of stable |
| 72:15 | test net activate activation so you go |
| 72:18 | six weeks before |
| 72:20 | june |
| 72:22 | 21st so you basically have beginning of |
| 72:25 | may this would be the last testnet |
| 72:28 | activate activation in this case on coty |
| 72:30 | test net maybe two weeks before so end |
| 72:32 | of |
| 72:33 | april you would do a motor test net more |
| 72:36 | bus much less stable than cotty so you |
| 72:38 | would do a mortar test activation and |
| 72:40 | now you already have a very tight |
| 72:41 | timeline so you already see okay |
| 72:44 | end of april is just |
| 72:46 | two months out so you would have to |
| 72:49 | deliver this entire |
| 72:50 | development cycle this entire |
| 72:52 | private testing or internal testing |
| 72:55 | cycle needs to be |
| 72:57 | delivered within the next |
| 72:59 | uh let's say |
| 73:01 | eight to nine |
| 73:02 | weeks starting now in in february and |
| 73:06 | this would also include the ecip |
| 73:08 | governance process so you would |
| 73:10 | make a proposal to make this hard fork |
| 73:12 | on the state |
| 73:14 | um |
| 73:15 | and you can |
| 73:16 | do already run some numbers and and |
| 73:18 | suggest numbers it's really always |
| 73:20 | numbers block numbers is always a moving |
| 73:22 | target and it's very difficult to |
| 73:23 | estimate months in advance because block |
| 73:25 | times on proof of work networks are very |
| 73:29 | strongly uh |
| 73:31 | they're not very uh consistent |
| 73:34 | unfortunately so it's really hard to |
| 73:36 | predict uh months in advance so |
| 73:38 | yeah i think my point is um |
| 73:41 | if you want to do a hard fork you |
| 73:43 | basically |
| 73:44 | define |
| 73:46 | a wanted hard fork date in the future |
| 73:49 | and try to estimate |
| 73:50 | will this work also by calculating |
| 73:52 | backwards the mainnet activation the |
| 73:54 | testnet activation the internal feature |
| 73:58 | freeze |
| 73:59 | and internal testing deadlines and this |
| 74:02 | needs to be coordinated with the core |
| 74:04 | developers and they say yes this is |
| 74:07 | possible or they know they say no it's |
| 74:09 | not or they say |
| 74:10 | it's possible but |
| 74:12 | we need to have certainty from the |
| 74:14 | community governance or from the ecip |
| 74:16 | process we don't some client teams might |
| 74:19 | say they don't start implementing a |
| 74:20 | feature unless it's in last call |
| 74:23 | so there are as you see there are many |
| 74:25 | moving parts to this i hope this answers |
| 74:27 | your question |
| 74:28 | yes thank you thanks a lot hey offering |
| 74:31 | um |
| 74:32 | i mean if nobody else has a question or |
| 74:35 | anything i don't want to take up you |
| 74:36 | know any any other time so um |
| 74:40 | i just wanted to mention i just wanted |
| 74:41 | to mention that uh |
| 74:44 | i believe afree has a hard cut off in |
| 74:46 | the next few minutes so if there's any |
| 74:48 | burning last questions then now is the |
| 74:50 | time to ask |
| 74:51 | and if not you can take the floor kev |
| 74:53 | cool so um aubrey it seems like the main |
| 74:56 | arguments for um |
| 74:58 | for shot three to be implemented |
| 75:01 | are that |
| 75:02 | um |
| 75:03 | [Music] |
| 75:05 | for not to be for them not to be until |
| 75:07 | implemented is a6 will take over |
| 75:11 | um and then you know it will be a |
| 75:13 | centralized network |
| 75:15 | um |
| 75:16 | and then the opposite side is that you |
| 75:19 | know all these |
| 75:20 | gpu miners are just going to overwhelm |
| 75:23 | the network with their you know one pita |
| 75:25 | hash |
| 75:26 | and that's gonna you know just uh |
| 75:30 | destroy uh etc |
| 75:32 | um |
| 75:33 | but i mean just like with bitcoin |
| 75:36 | and how that progressed from from when |
| 75:39 | it did when it was worth pennies to |
| 75:41 | where it is now |
| 75:43 | um do you think that would be the most |
| 75:46 | likely |
| 75:47 | um |
| 75:48 | way forward for it or i guess the the |
| 75:51 | path of |
| 75:52 | least resistance for for that um |
| 75:56 | you know the mining ecosystem |
| 75:59 | i honestly don't know um i'm |
| 76:02 | i'm a big fan of uh |
| 76:04 | shar3 um but that said i'm also a big |
| 76:07 | fan of many other algorithms uh |
| 76:10 | iron in this entire |
| 76:13 | cpu mining versus gpu mining uh |
| 76:17 | versus |
| 76:18 | specialized hardware fpgas a6 |
| 76:22 | i never really |
| 76:24 | found my spot in this debate because |
| 76:27 | i can't really tell what's better this |
| 76:29 | is you know you have this cpu mining |
| 76:31 | networks that are run by botnets |
| 76:33 | basically you have this uh you have gpu |
| 76:37 | mining networks that have like this seek |
| 76:40 | i mean there are people that claim that |
| 76:41 | there's there's no way to make something |
| 76:44 | cpu proof |
| 76:45 | uh gpu asic resistant |
| 76:48 | in first place and you can always have |
| 76:50 | you can tell the community is it's gpo |
| 76:52 | only and then you have the com companies |
| 76:54 | see secretly having specialized chips uh |
| 76:57 | mining it anyways |
| 76:59 | on their more efficient hardware i don't |
| 77:02 | know i i would say |
| 77:03 | i would carefully say something like |
| 77:05 | chassis would be very fair because it's |
| 77:08 | uh it's it's it's like a gold standard |
| 77:11 | in cryptography |
| 77:12 | um |
| 77:13 | it would it is extremely efficient and |
| 77:16 | fast and it would be easy to optimize |
| 77:20 | for anyone who has access to |
| 77:22 | uh |
| 77:25 | building specialized hardware and it's |
| 77:27 | also |
| 77:28 | um there might be even uh applications |
| 77:32 | for specialized char three uh uh a6 |
| 77:35 | beyond mining i don't know i'm not an |
| 77:37 | expert on that but i would carefully say |
| 77:39 | it's you should not be afraid of |
| 77:42 | moving towards something like char sri |
| 77:45 | i'm not necessarily saying you should do |
| 77:47 | it um |
| 77:48 | but i'm also not a very opposed either |
| 77:52 | but |
| 77:52 | since we are on a nissium classic call |
| 77:54 | looking back um at i don't know maybe |
| 77:56 | alex did this talk in vancouver and edc |
| 77:59 | summit uh advocating for three in 2019 |
| 78:03 | and then looking at the |
| 78:05 | the horrible i'm i mean i'm happy that |
| 78:08 | all teams that were involved in the last |
| 78:11 | months and years where we had to |
| 78:13 | mitigate 51 attacks and |
| 78:16 | patch different you know we had this |
| 78:19 | mess protocol we had |
| 78:20 | we moved from east to etc |
| 78:23 | all these solutions they kind of worked |
| 78:25 | and we we managed to prevent further |
| 78:28 | attacks but then again |
| 78:30 | what if we had taken alex seriously in |
| 78:33 | 2019 and just executed upon his ideas |
| 78:36 | and |
| 78:37 | stand out |
| 78:38 | from |
| 78:39 | from uh move away from ethereum uh move |
| 78:42 | towards a |
| 78:44 | different algorithm |
| 78:47 | that could be more more efficient more |
| 78:49 | fairly distributed with regards to |
| 78:51 | hardware and i mean um yeah what if i |
| 78:54 | mean there's a lot of water autism but |
| 78:56 | uh |
| 78:56 | yeah i cannot give a definite answer but |
| 78:58 | i i would say it you should not be |
| 79:00 | afraid of and i also like a lot uh |
| 79:03 | henry's idea about having even more than |
| 79:05 | one algorithm if if it's carefully |
| 79:08 | specced out |
| 79:09 | yeah i totally agree uh you know if it's |
| 79:13 | uh there's if there's a time and a place |
| 79:16 | you know |
| 79:17 | go for it um |
| 79:19 | if there's not then you know that i i |
| 79:22 | don't think it should and i guess i'm |
| 79:24 | impartial yeah well we don't have |
| 79:27 | consensus for it so we're just wasting |
| 79:29 | wasting time talking about it so um afri |
| 79:31 | i want to say um |
| 79:33 | i want to say thank you so much for all |
| 79:35 | your work on the protocol parody uh i |
| 79:38 | remember the days when you were working |
| 79:39 | on this quite a bit and uh |
| 79:41 | and |
| 79:42 | um |
| 79:43 | i think that that was a really big value |
| 79:46 | lift for this network um |
| 79:49 | one thing i heard you talking and you |
| 79:51 | might have addressed this earlier i |
| 79:52 | apologize i've been kind of in and out |
| 79:54 | of this call was um |
| 79:56 | a lack of users and how we didn't see |
| 79:59 | the shift when the fee markets were |
| 80:01 | extremely high on ethereum i also was of |
| 80:04 | the opinion that we might start seeing |
| 80:06 | that migration over to ethereum classic |
| 80:09 | um my question to you is do you have any |
| 80:11 | thoughts on |
| 80:12 | um |
| 80:13 | why we didn't see that shift and perhaps |
| 80:16 | there's um |
| 80:18 | some bridges or some sort of products uh |
| 80:22 | protocols maybe on top of ethereum |
| 80:24 | classic that um |
| 80:26 | would help in kind of |
| 80:28 | ushering people over to the network um i |
| 80:32 | believe that you cited you know people |
| 80:33 | didn't want the political statement but |
| 80:36 | nowadays i think that um that's kind of |
| 80:39 | fallen to the wayside as we've seen with |
| 80:40 | finance smart chain and some of the |
| 80:42 | other ones where um they kind of created |
| 80:45 | those type of bridges uh some through |
| 80:47 | their centralized exchanges um and you |
| 80:50 | started seeing protocols pop up on those |
| 80:53 | other evms um |
| 80:56 | do you have any opinion on some of the |
| 80:58 | high priority |
| 80:59 | um |
| 81:00 | protocols that need to be built on |
| 81:02 | ethereum classic to try to uh |
| 81:06 | jumpstart that type of ecosystem we are |
| 81:08 | we are running very close to time so i |
| 81:11 | will let apprey finish this question |
| 81:13 | pretty quickly because i know he has to |
| 81:14 | go in a couple minutes so uh uh |
| 81:17 | yeah you could wrap up and then uh we'll |
| 81:20 | say |
| 81:20 | very big thanks to afri for joining us |
| 81:22 | and uh yeah massive thanks from everyone |
| 81:25 | here and it's been extremely useful to |
| 81:28 | have this conversation so i'll leave you |
| 81:30 | to finish it every |
| 81:32 | um yeah thank you for having me and also |
| 81:34 | thank you for those questions it's a |
| 81:35 | really interesting one |
| 81:37 | um |
| 81:38 | i think it all comes down to network |
| 81:41 | effect um |
| 81:43 | do you want to |
| 81:45 | do d5 on issue classic if there's only |
| 81:48 | limited set of exchanges if there's only |
| 81:50 | limited set of tokens you can trade if |
| 81:53 | there are not sufficient bridges to |
| 81:55 | other networks and um |
| 81:58 | i don't really have a protocol to |
| 82:00 | recommend |
| 82:02 | um i would just try to i mean we are |
| 82:05 | running out of time but i would |
| 82:07 | try to for everyone in new zealand |
| 82:09 | classic to zoom out and |
| 82:11 | think about what could be |
| 82:13 | two options what could be the |
| 82:14 | opportunities for assume classic going |
| 82:15 | forward because i mean |
| 82:18 | let's face it in 2022 assume classic |
| 82:21 | really you cannot only be immutable and |
| 82:24 | have a monetary policy and |
| 82:25 | [Music] |
| 82:28 | stick to your values and then again |
| 82:30 | nobody |
| 82:31 | i'm i'm trying to be provocative please |
| 82:33 | don't take my word for it but just |
| 82:35 | nobody cares to build applications on |
| 82:37 | museum classic |
| 82:39 | you need to |
| 82:40 | try to define why you need to find out |
| 82:42 | why would people build on this and maybe |
| 82:45 | it's it's worse to like take a look at |
| 82:48 | i i mentioned layer twos earlier on |
| 82:50 | ethereum which kind of they kind of fill |
| 82:53 | this gap between |
| 82:55 | they still use this network effect from |
| 82:57 | all these applications and protocols |
| 82:59 | available on ethereum foundation network |
| 83:02 | but they also fill the skip of being |
| 83:04 | cheaper and |
| 83:06 | faster and still as accessible as issue |
| 83:09 | foundation maintenance |
| 83:11 | but also what i don't know how many of |
| 83:13 | you are following the network effects of |
| 83:15 | polkadot which is also interesting they |
| 83:18 | also have evm chains they also have |
| 83:20 | very similar uh |
| 83:22 | applications they even use they even |
| 83:25 | work with the same uh browser plugins |
| 83:28 | and |
| 83:29 | they came much later than issue classic |
| 83:31 | how did they build this up from scratch |
| 83:33 | how how |
| 83:35 | what what did they do to |
| 83:37 | um |
| 83:38 | to attract so many people to actually do |
| 83:41 | uh defy on pokedot or i don't know there |
| 83:43 | are other pockets just one example i |
| 83:47 | i could go on and go on um for |
| 83:50 | isilon classic specifically it might be |
| 83:52 | time to like just really step back |
| 83:55 | zoom out and and like get this |
| 83:56 | helicopter view of of this ecosystem and |
| 83:59 | think if i were an application developer |
| 84:02 | what what needs to happen to |
| 84:05 | to actually use or make this attractive |
| 84:07 | to to deploy my applications on this |
| 84:09 | network and or as a user stifle user as |
| 84:12 | a trader whatever |
| 84:14 | why would i use sim classic and maybe |
| 84:16 | it's it's it's really time for assume |
| 84:19 | classic to if cells desire to be more |
| 84:22 | attractive for |
| 84:23 | developers and users maybe it's time to |
| 84:26 | also be open for more radical |
| 84:28 | changes in |
| 84:30 | in the technology stack in |
| 84:32 | in how |
| 84:34 | how you position yourself do you always |
| 84:37 | want to be a little sister of ethereum |
| 84:39 | foundation network or do you want to |
| 84:41 | maybe |
| 84:42 | do a bold move towards a new ecosystem |
| 84:45 | do you want to build |
| 84:46 | upon a much more modern technology stick |
| 84:50 | all these things that could be |
| 84:51 | considerated but you would have to |
| 84:54 | be courageous and |
| 84:57 | step out of this little uh bsu and |
| 85:00 | coregas cloud is step out of this ecip |
| 85:04 | process i'm not saying you should ignore |
| 85:06 | all this and it's it's so far these |
| 85:08 | values are very |
| 85:09 | high goods in the community and they |
| 85:11 | should be preserved but you should allow |
| 85:13 | yourself to think about where to move |
| 85:16 | to |
| 85:17 | from the point we are here today and we |
| 85:20 | are still here this is a good thing but |
| 85:22 | you also need to think where do you want |
| 85:23 | to go and um eventually this is |
| 85:25 | something i believe this is not a |
| 85:26 | technical not necessarily a technical |
| 85:28 | question but just something um |
| 85:30 | issue classic needs to needs to discuss |
| 85:32 | uh |
| 85:34 | openly and |
| 85:36 | yeah this is um a discussion i would |
| 85:39 | happy to follow yeah but we are running |
| 85:41 | out of time yeah thank you i'm free |
| 85:43 | you've been super generous with your |
| 85:45 | time and left us with a lot of amazing |
| 85:47 | uh food for thought so uh we are over |
| 85:50 | time and uh thanks for joining us |
| 85:52 | thank you have a great day |
| 85:55 | you too thanks bye-bye |
| 85:58 | okay so that was uh afree um the call is |
| 86:01 | continuing uh as long as we still have |
| 86:05 | enough coffee in us um because we do |
| 86:06 | have some other items but before i |
| 86:09 | continue to the next section were there |
| 86:10 | any other comments on uh afri um |
| 86:14 | ball's open |
| 86:16 | uh |
| 86:17 | wish there were more devs |
| 86:19 | like him |
| 86:20 | especially on the other side of the uh |
| 86:24 | ethereum |
| 86:25 | yep he's definitely uh |
| 86:27 | i guess an mvp |
| 86:30 | yeah very agnostic too |
| 86:33 | okay so um |
| 86:34 | i wanted to uh continue the call with |
| 86:37 | the next section um with i guess a mini |
| 86:40 | announcement of a an mvp product uh |
| 86:43 | that's related to etc dao which uh has |
| 86:45 | just been sort of launched in a very |
| 86:47 | beta stage but will be over time |
| 86:50 | evolving into hopefully a |
| 86:53 | grants system or funding platform type |
| 86:56 | thing currently it's just a github repo |
| 86:59 | github repo at uh github.com etc |
| 87:03 | gigs and over time |
| 87:05 | this is going to |
| 87:06 | grow and |
| 87:08 | basically be used as a testing ground |
| 87:09 | for how we might be able to raise funds |
| 87:11 | and allocate funds um |
| 87:13 | via various different dows that are |
| 87:15 | running in etc so uh thanks to ronin for |
| 87:18 | the initiative there |
| 87:20 | that's awesome you're the one that fired |
| 87:22 | it up |
| 87:24 | thanks to you |
| 87:25 | inspired from uh monero so uh credit |
| 87:28 | where where is you |
| 87:29 | and if anyone has any suggestions or |
| 87:31 | updates um |
| 87:32 | questions yeah feel free to contribute |
| 87:35 | to the repo sorry kid |
| 87:37 | i i i know somebody who really likes |
| 87:39 | monero |
| 87:40 | yeah me too |
| 87:42 | yeah so i actually i attended one of |
| 87:44 | their conferences here in denver and uh |
| 87:46 | it was one of the most insightful |
| 87:48 | conferences i had um but |
| 87:51 | one thing that i really like about i |
| 87:52 | think that community is that they figure |
| 87:55 | out a way to fund and improve their |
| 87:57 | protocol |
| 87:58 | and they're pretty honest about their |
| 88:00 | protocol too that's what i learned at |
| 88:01 | that conference was they they really do |
| 88:04 | take privacy privacy seriously and uh |
| 88:07 | they're honest about their shortcomings |
| 88:09 | uh which i think is really helpful when |
| 88:11 | you're just trying to make the tech |
| 88:13 | better um and here i i i feel like we |
| 88:16 | have a lot to learn from monero in that |
| 88:18 | regard um |
| 88:20 | i think uh i think sometimes we aren't |
| 88:23 | entirely honest with ourselves of what |
| 88:25 | we need uh to do for this network and i |
| 88:27 | think afri was really hitting on uh on a |
| 88:29 | great thing there is i think we need to |
| 88:31 | zoom out take a bird eye view of you |
| 88:34 | know how do we stay competitive in this |
| 88:36 | landscape you know we get in these very |
| 88:39 | micro debates |
| 88:41 | over um you know stuff that franklin |
| 88:44 | isn't adding value to the network it may |
| 88:47 | in a very very long time but the network |
| 88:49 | might not even be around if you don't |
| 88:50 | get traction so the whole thought of |
| 88:53 | this etc dao |
| 88:55 | thing was this actually was something |
| 88:57 | that i had noticed in maniro a long time |
| 88:59 | ago um and uh when i came into the |
| 89:03 | ethereum classic ecosystem kind of um i |
| 89:06 | think i was watching it in |
| 89:08 | 2018 um |
| 89:10 | and |
| 89:11 | i was saying these p you know |
| 89:14 | there should be some sort of funding |
| 89:15 | mechanism |
| 89:17 | in this system and i thought something |
| 89:19 | like this made sense |
| 89:21 | i remember posting about it in the |
| 89:23 | server and there was no appetite at all |
| 89:25 | for it um and it was hey we have three |
| 89:28 | private teams um or i can't remember if |
| 89:32 | it was three or two uh |
| 89:34 | but anyways there was no appetite for it |
| 89:36 | and now what we've seen is we've kind of |
| 89:38 | seen |
| 89:39 | those teams starting to fall to the |
| 89:40 | wayside uh and then we've also seen the |
| 89:43 | risk of um |
| 89:45 | of |
| 89:46 | of losing funding and how that affects |
| 89:48 | the network and so |
| 89:51 | my whole thought was you build it like a |
| 89:53 | business where you create positive |
| 89:56 | revenue |
| 89:57 | um |
| 89:58 | loops right so you have a protocol that |
| 90:01 | uh |
| 90:02 | you start building little gigs that |
| 90:05 | generate more funds to build more little |
| 90:07 | gigs and fun more gigs and it's just |
| 90:10 | that's that's my thought of doing it um |
| 90:12 | i always never won that thought that we |
| 90:14 | needed to adjust the protocol um |
| 90:17 | to build a treasury and all that uh so |
| 90:19 | anyways so you know i think that's kind |
| 90:22 | of where this has started is that the |
| 90:24 | treasury fell to the wayside there is a |
| 90:27 | real funny need um and there's tons of |
| 90:30 | great protocols on the ethereum |
| 90:32 | foundation network that could be ported |
| 90:35 | over here um people just need some money |
| 90:38 | to do that and you can start |
| 90:41 | filling up blocks with transactions on |
| 90:42 | ethereum classic and give it a go |
| 90:45 | um |
| 90:46 | and i think that that's a more |
| 90:47 | productive |
| 90:48 | uh use of our time |
| 90:50 | um |
| 90:51 | than us fighting over extremely |
| 90:53 | contentious ecips and trying to shake |
| 90:56 | the foundation of this network again |
| 90:59 | um so that's just my piece on it is that |
| 91:02 | i believe that this is the right |
| 91:04 | direction for this network um |
| 91:08 | and |
| 91:08 | you know hopefully it grows to be |
| 91:10 | something that's meaningful you know |
| 91:12 | over time and hopefully as |
| 91:15 | it props up protocols |
| 91:17 | um |
| 91:18 | via out you know open source development |
| 91:21 | right uh |
| 91:22 | hopefully |
| 91:23 | transactions increase on their on |
| 91:25 | ethereum classic and the fee market gets |
| 91:29 | sparked and then |
| 91:30 | um |
| 91:31 | all of a sudden all of the great things |
| 91:33 | that we've seen on the ethereum |
| 91:35 | foundation network which we watched over |
| 91:37 | it was about two or three years it took |
| 91:39 | to really jump start it hopefully we |
| 91:41 | have that happen over here |
| 91:43 | and we didn't have to |
| 91:45 | do |
| 91:46 | crazy changes to the network protocol |
| 91:49 | um |
| 91:50 | that are destabilizing in nature |
| 91:52 | to achieve |
| 91:53 | that type of user adoption um so anyways |
| 91:57 | that's just that's just where this kind |
| 91:58 | of came from and uh |
| 92:00 | and kind of what i think it can do and |
| 92:02 | you know and thanks to uh estora for |
| 92:06 | setting this up you know |
| 92:08 | do you think something like that is a |
| 92:10 | lot uh more efficient than something |
| 92:12 | like bitcoin |
| 92:14 | well i think they probably can't be used |
| 92:15 | the goal was to use git coin with this |
| 92:17 | as well if i if i understand correctly |
| 92:20 | right |
| 92:21 | the thing with git coin is uh it's more |
| 92:24 | for |
| 92:25 | finding |
| 92:27 | or actually funding projects that you |
| 92:28 | know that you want to create as opposed |
| 92:30 | to deciding which projects to fund in |
| 92:32 | the first place and i think i think why |
| 92:34 | we wanted to use bitcoin was uh the |
| 92:36 | developers already there so rather than |
| 92:38 | making the developers come to us we just |
| 92:40 | go to where they're hanging out um i |
| 92:42 | know i know many open source developers |
| 92:44 | just go and they check in there and they |
| 92:46 | see oh is there you know is there a gig |
| 92:48 | that um that i already know how to do so |
| 92:51 | i can make a you know a scalp of that |
| 92:53 | real quick um also i think that is good |
| 92:56 | i um we had talked about um last call it |
| 92:59 | was you know are we paying the right |
| 93:02 | amount for these jobs i think that um |
| 93:04 | it's a good market to look at that too |
| 93:06 | like what's a reasonable fee for |
| 93:08 | development um of a certain code base |
| 93:11 | that we want on ethereum classic so |
| 93:14 | yeah for sure um i envisaged this giggs |
| 93:17 | platform as a kind of like |
| 93:20 | meta |
| 93:21 | like central organizing location for |
| 93:24 | deciding what stuff should get funded |
| 93:27 | and it could be that |
| 93:28 | like |
| 93:29 | one gig is use get use github sorry use |
| 93:33 | git coin to fund blah blah blah another |
| 93:36 | is use this uh |
| 93:39 | charity llc or whatever it is to fund |
| 93:41 | this other thing but uh it could be |
| 93:44 | using any number of different sort of |
| 93:45 | funding mechanisms or |
| 93:47 | um |
| 93:48 | something like that but it's more of |
| 93:50 | just like a |
| 93:51 | coordination um |
| 93:53 | central point |
| 93:55 | do you are you guys aware of any um |
| 93:58 | potential competitors or uh potential |
| 94:01 | competition in in the dial space um with |
| 94:04 | etc |
| 94:06 | not that i'm aware of |
| 94:08 | yeah and i'm not i'm not sure what you |
| 94:09 | mean by that of a competitor to adapt |
| 94:12 | okay yeah so um |
| 94:14 | yeah saturn that that project they're |
| 94:17 | they're working on um developing some |
| 94:19 | dowels uh they're still you know trying |
| 94:22 | to get their their stuff together |
| 94:24 | um there's that other molok dao |
| 94:27 | um the etc version of that um i think |
| 94:31 | alex might have been the only con |
| 94:32 | contributor to that um |
| 94:36 | and i think there might be one other one |
| 94:37 | but i was just curious if you guys had |
| 94:39 | heard of any any other ones yeah i |
| 94:41 | actually i knew about those but uh |
| 94:44 | but i thought saturn folded and then i |
| 94:47 | thought alex's thing never took off um i |
| 94:49 | think that that wasn't that spurred |
| 94:51 | around that when the treasury was coming |
| 94:53 | up from iohk um i can't remember but i |
| 94:57 | thought that that's that's where that |
| 94:58 | came up um i think i don't i don't know |
| 95:01 | if those are i wouldn't think of those |
| 95:03 | as |
| 95:04 | competitors because i think just the |
| 95:06 | concept of this is to try to |
| 95:08 | figure to try to organize in some sort |
| 95:11 | of way of getting stuff built on uh |
| 95:14 | ethereum classic we had we had three |
| 95:16 | private teams that built no protocols |
| 95:19 | not one protocol went up you know and so |
| 95:22 | um we're seeing we're seeing uh ethereum |
| 95:25 | co-op or etc co-op and we're just not |
| 95:28 | seeing the funds go into |
| 95:31 | meaningful protocol development on top |
| 95:33 | of ethereum classic we're seeing it go |
| 95:35 | to |
| 95:36 | ecips that may be beneficial way down |
| 95:39 | the road but you know it's not |
| 95:41 | addressing any immediate needs um so |
| 95:44 | this is i think the urgency of this is |
| 95:47 | starting to come up because there just |
| 95:49 | isn't anyone uh that's pushing on that |
| 95:52 | type of like immediate need on this |
| 95:55 | network which is um to prop up protocols |
| 95:58 | and get it so that the end user can fire |
| 96:02 | up a token and there's an ecosystem you |
| 96:04 | know there's an amm there's just just |
| 96:06 | all of the other stuff that you see on |
| 96:08 | other evms i mean the model is out there |
| 96:10 | it's extremely easy to see as aphro said |
| 96:13 | zoom out to a bird eye view you know |
| 96:16 | it's a barren landscape on this network |
| 96:18 | in the sense of uh saturn was probably |
| 96:20 | the only thing that uh |
| 96:22 | was a |
| 96:24 | type of amm to trade tokens on this |
| 96:27 | network uh but even so i mean that was a |
| 96:29 | really really i mean i'm sorry if one of |
| 96:32 | you guys are work worked on that or |
| 96:33 | whatever but i mean that was some old |
| 96:35 | looking web that just wasn't enticing at |
| 96:37 | all and it also like |
| 96:40 | it also |
| 96:42 | i what's that |
| 96:43 | i said yeah you're right |
| 96:45 | yeah it was like it was like old-ass php |
| 96:47 | i mean it's just like it just didn't |
| 96:49 | even look like it was of this decade um |
| 96:52 | which you know it's fine if it was an |
| 96:54 | mvp but |
| 96:55 | you know it got no adoption right and |
| 96:57 | and there's no surprise to me on that uh |
| 97:00 | we have the models out there there's the |
| 97:01 | protocols out there i think the i think |
| 97:03 | the thought is to |
| 97:05 | get this going um and i we've had |
| 97:08 | previous calls on this and it was |
| 97:10 | um let's start really small |
| 97:13 | let's do you know identify small things |
| 97:15 | just start trying on the proper you know |
| 97:19 | or really it's kind of like try get coin |
| 97:22 | try any way to start getting stuff built |
| 97:24 | onto this network um because as afria |
| 97:27 | was saying is you know the hourglass is |
| 97:29 | is ticking here you know we have to |
| 97:32 | start doing stuff on top of the network |
| 97:34 | you know the the network in itself is in |
| 97:37 | a pretty good shape um it just needs |
| 97:40 | the right protocols on top of it um we |
| 97:43 | can't just be stuck in 2018 we got it we |
| 97:46 | got to keep moving it forward that's |
| 97:48 | that's |
| 97:49 | what i think is the general purpose of |
| 97:51 | this i don't think it's to compete with |
| 97:52 | another dow to to do any of that it's to |
| 97:55 | really try to get stuff built on top of |
| 97:57 | ethereum classic so |
| 97:59 | all of our etc is worth more money yeah |
| 98:02 | that's a really good motivation behind |
| 98:04 | that um |
| 98:06 | yeah sounds like a really good project |
| 98:08 | but i as far as saturn goes they're |
| 98:11 | trying to do the exact same thing i mean |
| 98:14 | all the all the original developers |
| 98:16 | they're gone but a new set of people |
| 98:19 | have have come in and |
| 98:21 | really devoted their own time and stuff |
| 98:23 | and tried to are trying to get this |
| 98:26 | thing back together but |
| 98:28 | um |
| 98:29 | yeah it'll be interesting to see what |
| 98:31 | what happens with etc because |
| 98:33 | this space is so valuable and it's going |
| 98:36 | to be such a missed opportunity um for a |
| 98:38 | lot of projects if they choose not to |
| 98:42 | use |
| 98:42 | ctc yeah and you know i look forward to |
| 98:46 | seeing whatever comes out of the saturn |
| 98:47 | guys um |
| 98:48 | well you know we'll see what goes with |
| 98:50 | that but you know something needs to |
| 98:52 | happen over you know something needs to |
| 98:54 | happen in this discord and |
| 98:56 | uh |
| 98:57 | you know we need to we need to be |
| 98:58 | propping up protocols you know there's |
| 99:00 | plenty of solidity developers out there |
| 99:03 | right there's tons of them and why are |
| 99:05 | they not building on this because no |
| 99:07 | one's paying them to prop up these |
| 99:08 | protocols so that's you know it's it's a |
| 99:11 | money thing it's a put the money in the |
| 99:13 | right spot um |
| 99:15 | there it's there it's not a lack of |
| 99:17 | development talent it's not like uh |
| 99:19 | the the network is not integrated in |
| 99:22 | damn near every exchange right |
| 99:24 | like it's everywhere |
| 99:26 | literally everywhere |
| 99:28 | yeah it's it's literally everywhere and |
| 99:29 | then on the wallet side for an exchange |
| 99:31 | it's extremely easy to add the ethereum |
| 99:35 | classic network uh just like you would |
| 99:37 | do anything with ethereum so so anyways |
| 99:40 | um we just you need to have the use |
| 99:42 | cases on there and i think that that's |
| 99:44 | the direction that this network needs to |
| 99:46 | go um |
| 99:47 | we really need to start get filling |
| 99:49 | these blocks with transactions on chain |
| 99:51 | transactions |
| 99:53 | and not just someone moving funds back |
| 99:54 | and forth we're talking you know trading |
| 99:57 | transactions um all of the stuff you see |
| 99:59 | on the ethereum network that fee market |
| 100:01 | uh you know when people are saying oh |
| 100:04 | the merge is a very bad thing for |
| 100:06 | ethereum classic well if you have that |
| 100:07 | fee market you have that activity it's |
| 100:09 | not it just means that ethereum etc will |
| 100:11 | be worth a lot of money in the future um |
| 100:14 | but you got to build it you got to build |
| 100:16 | what what do they call them in ethereum |
| 100:18 | the lego stack i think is what they used |
| 100:20 | to always say you got to build the lego |
| 100:22 | stack on top of the etc network |
| 100:26 | i haven't heard that one |
| 100:28 | yes oh i think i think it was their 2019 |
| 100:30 | uh marketing thing to get people to |
| 100:32 | build build uh protocols on top |
| 100:35 | yeah and i hope to see uh maybe as an |
| 100:38 | action item for this week hopefully we |
| 100:40 | can get one or two uh proposals |
| 100:43 | into this uh giggs thing so we can start |
| 100:45 | testing out the system because uh yeah i |
| 100:48 | think as long as we do something every |
| 100:51 | week and make some progress we'll |
| 100:52 | eventually get there it's not gonna |
| 100:54 | happen instantly but we just need to |
| 100:55 | constantly be |
| 100:57 | uh having activity |
| 100:59 | yeah and i think if there's any uh if |
| 101:00 | there's any developers and you know you |
| 101:03 | know |
| 101:04 | what i've already what i've learned is a |
| 101:06 | lot of developers just learn like a |
| 101:08 | single code base and they try to apply |
| 101:10 | that to numerous networks uh if any |
| 101:12 | developers are listening and you're like |
| 101:15 | hey i know how to put that on the |
| 101:17 | ethereum classic network prop up a |
| 101:19 | proposal you know this is this is an |
| 101:21 | open thing uh go and submit the proposal |
| 101:25 | on this repo and get it in line um |
| 101:28 | and you know we'll figure out how to get |
| 101:32 | money to you guys that's i think that's |
| 101:34 | the goal |
| 101:35 | yep sounds awesome um i wanted to uh |
| 101:38 | move on now to the uh topic of uh pool |
| 101:42 | centralization and |
| 101:44 | uncle production because this was an |
| 101:46 | interesting uh item that was brought up |
| 101:48 | this week i believe by |
| 101:50 | wp |
| 101:51 | whack rack i'm not sure how i should |
| 101:53 | pronounce your name um did you want to |
| 101:55 | jump in there |
| 101:57 | um |
| 101:58 | easier the easiest pronunciation is just |
| 102:00 | to say werner |
| 102:05 | this this this cryptic acronym is simply |
| 102:07 | to have something that's reasonably |
| 102:09 | unique so that i don't have to pick a |
| 102:10 | new name a different name for for every |
| 102:13 | every site |
| 102:14 | um yeah the uncle rewards that was |
| 102:16 | something brought up by mr crazy who i |
| 102:19 | think is still on vacation |
| 102:22 | so um |
| 102:24 | the issue is basically that if you have |
| 102:27 | pools that are very big with a lot of |
| 102:29 | hash rate um |
| 102:31 | then they have a very good then when |
| 102:32 | they mine a block |
| 102:34 | um then they have a very good |
| 102:35 | probability to be also able to mine the |
| 102:38 | next block and they have also have a |
| 102:42 | time advantage |
| 102:43 | and because um they will see |
| 102:46 | the |
| 102:47 | if they mine up a block that will end up |
| 102:49 | on the blockchain they will |
| 102:51 | they will see this block immediately and |
| 102:53 | all the other other pools or the other |
| 102:56 | clients channel i will see this block |
| 102:59 | with some delay so they they start they |
| 103:02 | start later |
| 103:04 | being able to make blocks that sit on |
| 103:06 | top of this of this new block so if |
| 103:09 | there's a if there's a pool that |
| 103:10 | controls a lot of the hash rate this |
| 103:13 | block has a good chance of at this pool |
| 103:16 | it has a good chance of being able to |
| 103:19 | get |
| 103:20 | runs of consecutive blocks that come |
| 103:23 | from that |
| 103:24 | from that same pool this in turn means |
| 103:27 | that they have a good chance of blocks |
| 103:30 | that they that they find to be |
| 103:34 | blocks that really move the chain |
| 103:36 | forward instead of of being ankles |
| 103:39 | and |
| 103:40 | now on only feel you |
| 103:42 | if you find an anchor then you get paid |
| 103:44 | a bit but you get paid less but could |
| 103:47 | you briefly explain for the audience |
| 103:49 | what an uncle is |
| 103:51 | an uncle is a block that |
| 103:53 | that is correct that that passes all the |
| 103:56 | controls but it |
| 103:59 | it didn't make it |
| 104:00 | at the |
| 104:01 | into the longest chain instead some some |
| 104:04 | other block wonder wounded ways and |
| 104:08 | then uh future blogs can reference those |
| 104:11 | ankles and say by the way i found that |
| 104:13 | there was this this other block that was |
| 104:15 | submitted but it |
| 104:19 | it wasn't it wasn't there to be part of |
| 104:22 | the of the lowest chain um but it would |
| 104:25 | still like to acknowledge that this was |
| 104:27 | a valid block and its content can be |
| 104:30 | considered part of the blockchain and |
| 104:33 | when you when you make such a reference |
| 104:35 | then the the one making a block that |
| 104:38 | contains such a reference gets a little |
| 104:41 | reward and also the um the the |
| 104:45 | producer of the uncle block gets a |
| 104:47 | reward and only fear well i don't know |
| 104:50 | the numbers for a few but only film it's |
| 104:53 | it's a relatively significant um uh |
| 104:56 | compensation you get for for your uncles |
| 104:59 | so |
| 105:00 | it's it's they're not not worth as much |
| 105:02 | as as blocks that move the chain for |
| 105:06 | what they on on its on the longitudinal |
| 105:08 | direction but uh but um you still get |
| 105:12 | get something from for making blocks |
| 105:14 | that's that make it a bit wider |
| 105:16 | while in therm classic you get very |
| 105:18 | little |
| 105:19 | and |
| 105:20 | this means that uh |
| 105:22 | any pool that has |
| 105:24 | a lot of hash weight |
| 105:26 | which is the k especially the case |
| 105:27 | around the field classic where |
| 105:29 | even mine is currently |
| 105:32 | must be close to 50 percent and let me |
| 105:35 | just check how much it has at the moment |
| 105:38 | at the moment it has |
| 105:40 | um |
| 105:42 | 50 |
| 105:43 | 46. |
| 105:44 | seven percent of the global hash rate of |
| 105:47 | ethereum classic so they're very close |
| 105:50 | to fifty percent already and |
| 105:53 | so this means that um |
| 105:55 | because they're so dominant they have a |
| 105:58 | very good chance of being of being able |
| 106:00 | to make consecutive |
| 106:02 | blocks and |
| 106:03 | cash and receive always the um the full |
| 106:06 | block rewards while other other pools |
| 106:08 | only get well not only gets unknowns but |
| 106:12 | have a much higher chance of getting |
| 106:15 | only ankle rewards instead of full block |
| 106:17 | block rewards so this creates an |
| 106:18 | unfairness between the poles |
| 106:21 | which goes beyond the |
| 106:24 | um the uh the differences you would |
| 106:27 | expect based on hash rate so it is |
| 106:29 | basically uh |
| 106:31 | a bonus for the |
| 106:32 | for |
| 106:33 | for the biggest |
| 106:35 | it's sort of kind of the |
| 106:37 | subsidiaries for the elites in a way and |
| 106:41 | also does the this is well first of all |
| 106:43 | it's not nice for the smaller pools |
| 106:45 | and because it also encourages i mean at |
| 106:48 | the moment it doesn't seem to be um |
| 106:52 | to happen to the to the |
| 106:54 | full to the worst extent imaginable |
| 106:57 | which would be the uh |
| 106:58 | this uh the largest pool trying to |
| 107:01 | actually suppress other pools by simply |
| 107:03 | ignoring their blocks then they could |
| 107:05 | probably already be able to get away |
| 107:07 | with this by just making by just looking |
| 107:09 | at their own blocks ignoring all the |
| 107:11 | others and eventually |
| 107:13 | well no other pool could could keep up |
| 107:14 | with them and it's unvery unlikely that |
| 107:17 | they all or would agree on the |
| 107:18 | understand the same competing chain |
| 107:21 | and then they could basically |
| 107:23 | make all the other other pools |
| 107:25 | unprofited we don't see this happen so |
| 107:26 | that's good they're not doing anything |
| 107:28 | actively agnostic but |
| 107:32 | still we can see that |
| 107:33 | there's there are benefits from the |
| 107:35 | synergy effect and this might get worse |
| 107:37 | over time and of course one big issue |
| 107:40 | one issue with |
| 107:42 | having such a massive pool concentration |
| 107:44 | is also that um |
| 107:46 | well first first of all the the pool |
| 107:48 | diversity the system drops so you have |
| 107:52 | less diversity in the software |
| 107:55 | higher risk but you create a single |
| 107:58 | point of failure and it will cross it |
| 108:00 | will also make the pool more attractive |
| 108:02 | for attacks i mean |
| 108:04 | you don't need to have 50 51 of the hash |
| 108:07 | rate if you can control a pool that has |
| 108:09 | that is 52 |
| 108:11 | then you just need to take over the pool |
| 108:13 | and make it make it to your bidding and |
| 108:15 | you control the chain just as much and |
| 108:17 | you haven't spent anything in hash rate |
| 108:18 | so it's even cheaper so um |
| 108:22 | what idea is to improve the |
| 108:25 | the uncle rewards to make |
| 108:28 | make make things more attractive for |
| 108:31 | smaller pools |
| 108:32 | and to |
| 108:33 | to |
| 108:35 | reduce the risk of of such such an |
| 108:38 | unintentional |
| 108:41 | benef boosts basically to the |
| 108:43 | to a very large pool so that the |
| 108:47 | minor distribution would |
| 108:49 | be a bit more even so that we don't get |
| 108:51 | get one dominant pool and |
| 108:53 | that could then cause all kinds of |
| 108:56 | centralization issues |
| 108:58 | and |
| 108:59 | um of course it's just one of many |
| 109:01 | possibilities i may have there have been |
| 109:03 | some criticism that we think uncle |
| 109:06 | rewards |
| 109:07 | would |
| 109:09 | would mean changing the monetary policy |
| 109:12 | um |
| 109:13 | this could be well if in a way it would |
| 109:16 | obviously um |
| 109:18 | it wouldn't necessarily have to mean |
| 109:21 | that |
| 109:22 | there would be an increase of a |
| 109:25 | significant increase of overall emission |
| 109:27 | but instead |
| 109:29 | we just be done by reducing the the |
| 109:31 | block reward and moving moving some of |
| 109:35 | them moving that |
| 109:36 | through the two angular wave to the |
| 109:38 | unclear words part of the |
| 109:40 | of the |
| 109:42 | general reward scheme but um there might |
| 109:45 | be other options so that's |
| 109:47 | uh the |
| 109:48 | there's no specific proposal on on that |
| 109:50 | side just |
| 109:51 | the general consideration that those |
| 109:53 | small anchor rewards mean that small |
| 109:56 | pools have have a disadvantage that is |
| 109:59 | implied by this structure |
| 110:01 | and that can |
| 110:03 | lead to problems |
| 110:05 | interesting um is there a |
| 110:07 | link or document that we can add to the |
| 110:09 | show notes to uh to help people get |
| 110:11 | their heads around this |
| 110:12 | no there's nothing yet um i was thinking |
| 110:16 | of trying to |
| 110:18 | to do a numerical simulation |
| 110:21 | that would let us |
| 110:23 | see how |
| 110:24 | how how things go um |
| 110:26 | how do you see how to see how does he |
| 110:28 | start his effects um depends upon his |
| 110:30 | parameters and and |
| 110:32 | what uh what the possible outcomes are |
| 110:35 | of such conscious concentration but i |
| 110:37 | haven't gotten around to this there's no |
| 110:39 | larger description of this thing it's |
| 110:42 | it's basically something something that |
| 110:44 | uh |
| 110:45 | that mr crazy race |
| 110:46 | uh i guess he noticed that that he was |
| 110:49 | seeing more uncles on the small pool |
| 110:51 | then |
| 110:52 | then we see on only on on ether mine and |
| 110:57 | then he realized this probably due to |
| 110:59 | this and i think this is |
| 111:01 | a very very plausible observation um the |
| 111:04 | airport hypothesis for this effect and |
| 111:06 | there's the indeed science that's the |
| 111:08 | that there's there's such a such an |
| 111:11 | unbalance um |
| 111:13 | but no there's there's nothing uh |
| 111:15 | there's no |
| 111:16 | there's no paper on this yet interesting |
| 111:19 | one of the potential ways to mitigate uh |
| 111:23 | an increase in |
| 111:25 | the reward of uncles is by having longer |
| 111:28 | block times so that you get lesser |
| 111:31 | uncles overall |
| 111:32 | i'm not sure the number of er either the |
| 111:35 | block time changes this this effect |
| 111:38 | i wouldn't really expect |
| 111:40 | i mean |
| 111:41 | the effect is simply that you have a |
| 111:43 | higher chance of of mining |
| 111:45 | the next block and |
| 111:48 | this |
| 111:49 | if you change the block time this |
| 111:51 | doesn't change your probabilities |
| 111:53 | because they are determined by your hash |
| 111:54 | rate |
| 111:55 | okay i guess uh yeah i was going to say |
| 111:59 | i'm pretty sure this has been discussed |
| 112:01 | i think like six or seven years ago |
| 112:04 | um |
| 112:06 | i'll try to find the the |
| 112:08 | ecip i think it was uh |
| 112:10 | in ecip or maybe it was just a |
| 112:12 | discussion um but it was by dexran he |
| 112:15 | was he was trying to propose all this uh |
| 112:18 | all these types of solutions so i'll try |
| 112:20 | to find that um |
| 112:21 | and post it |
| 112:23 | that's great thanks kevin |
| 112:24 | so we are reaching the two hour uh time |
| 112:27 | and uh |
| 112:29 | that's a fairly long one um it's been a |
| 112:31 | very fruitful discussion once again uh |
| 112:34 | are there any other final topics that |
| 112:35 | people want to bring up before we wrap |
| 112:37 | up |
| 112:38 | okay so yeah you and all people |
| 112:42 | yeah it's good isn't it |
| 112:43 | it's uh it's got some momentum now we'll |
| 112:45 | just keep on rolling |
| 112:47 | most definitely |
| 112:48 | all right so that concludes this week's |
| 112:50 | call thank you to those who contributed |
| 112:53 | and for listening and sharing if we |
| 112:55 | don't if we didn't cover something that |
| 112:56 | you'd like to discuss you can always |
| 112:57 | submit your questions and topic |
| 112:59 | suggestions in the community course |
| 113:00 | channel and we can bring it up in a |
| 113:02 | future talk hope to see you all hope to |
| 113:04 | see you all again next week thanks bye |
- Upcoming Mystique Hard Fork coming ~13th Feb
- Currently ETC Coop has taken charge of this fork including coordination/outreach, you can follow bob's twitter (thank you)
- ETC will likely be experiencing hard forks for many years to come, so we wanted to "open source" some of the knowledge that has been accumulated over the years by speaking to a qualified hard fork coordinator, in the hopes that it can help ensure future forks go smoothly
- We are pleased to be joined by one of the most experienced and qualified coordinators out there, Afri, who is veteran and prolific caretaker of various blockchains and testnets. Afri has previously helped coordinated forks on ETC, such as Agharta, and (I believe that series of A-name forks?).
- Firstly, warm welcome, and thank you very much for joining us today to share some knowledge with the ETC community.
- Who is Afri, and how has he been involved with Blockchain/Web3 & ETC?
- What is the goal of hard fork coordination?
- What is involved in hard fork coordination?
- What are the pitfalls; what kind of things can go wrong when transitioning to a new fork, and how can this be mitigated?
- What kind of network monitoring tools do you use, do you spin up your own nodes to check?
- What happens if there's a chain split; from a coordinator's perspective, what should be done?
- What are the kinds of chain splits that can occur? Accidental, intentional, temporary, permenant, etc...
- If a hard fork results in a chain split, how to resolve things?
- What do you think would happen to applications on a network if there is a permenant chain split (DeFi, NFTs, etc)?
- It seems that part of the role of HF coordinator is to act as a trusted point of contact on behalf of a project, but does this pose any centralization risk that could be exploited?
- How can projects with no central organizing comittee like ETC coordinate forks in a maximally decentralized way?
- What is your perspective on multiple client implementations, is it helpful or annoying, and would a bitcoin-like approach make coordinating forks easier?
- Thoughts on where ETC is at right now?
- Do you have any thoughts on how The Merge on Ethereum will go, will miners continue the legacy chain?
- What is Afri up to these days? Anything you'd like to shout out?
- Q&A OPEN TO CHAT
- SHA3
- Bridges, Chainsafe?