ETC Core Devs Call 13 & 14 #362
Comments
|
After recent critique, I will try to host this call on Jitsi as alternative, open-source, and federated conference calling platform. |
|
The goal of this is to crowd-source an agenda as we did in the past. I rescheduled the call to have more time to gather proposals and out of respect for the 9/11 victims. |
|
Hi, I would like to stick with original plan of a meeting on Sept 11 2020 @ 4 PM UTC. I have invited a number of guests for that time to attend the call, and computed a block activation strategy for this time. This fellow gitr0n1n has said in numerous places that he disagrees with this proposal, and has been harassing everyone associated with the proposal. This is another one of his ploys. Also he did not show up to the previous meeting, he can take 90 minutes to show up to this one. Second of all, the block release schedule of 14,000,000 has been calculated to be aprox. 1 year from date of acceptance. If we move this meeting it's actively affecting the ECIP itself. I respect GitR0n1n's concerns and will happily talk to him directly during the call and address his concerns, one by one, with actual experts in the field of supply chain and mining. However this 9/11 excuse does not justify moving the meeting. I am an american and New Yorker who knows people directly affected, and Friday is a normal working day. So I say we continue. |
|
@antsankov |
|
I will answer all questions that are presented to me on the call, but I am too busy to answer everything posted in the comments. My apologies. |
|
Thank you for adjusting the time away from 9/11. I will be available for the September 25th meeting. @q9f I appreciate you. Last CDC CDC Results on 8/28: #362 My vote for the agenda is to narrow in on the proposed 51% attack solutions with motions for the following:
And no other topics to prevent distracting from the issue at hand. @antsankov or @pc3_bot, please keep the personal attack to the discord server. This is for professional conversations. Thank you. There are plenty of criticisms to your proposal that need to be addrssed before you're ready from a proper CDC meeting. But I look forward to attending that. As you have mentioned personally and I share the sentiment, we have more important topics to discuss than your proposal; the 51% attack solutions are the most important topic. Let's keep our focus there and we can schedule review of your ECIP-1049 SHA3 proposal at 6 weeks mark of Thank you for clarifying why this meeting's date was being rushed (#333 (comment)) by pro-SHA3 participants due to their proposal timeline goals, but I don't think ECIP-1049 is more important than addressing the 51% attack solutions with our limited time on this call. For the record, your ECIP was not present on the agenda when I recommended we don't hold the meeting on 9/11. The meeting's agenda was blank with "To Be Determined". There was no correlation to my recommendation that we move away from the 9/11 date and my opposition to your proposal. This is paranoia of a strong and vocal opposition to your proposal. Let's save that for October 9th as laid out in the 8/28 CDC. #333 (comment)
Thank you for your passion to ETC and thank you for contributing to the ECIP process. We can disagree, but be agreeable. We both want whats best for the network or we wouldn't be here. Stay blessed. |
|
When someone write TBD. It gives participants a heads up that a meeting is coming and to expect a date/time sometime later. It seems like we are making concessions on behalf of one individual who failed to read the agenda last week and attend the meeting. These meetings aren't being sneaked around so that certain people don't show up thats just ridiculous. @q9f has done fantastic jobs setting up and leading thees calls. Besides that Ronin is the champion for the RandomX proposal. I've seen no other supporters for RandomX but Ronin. It's not anyone's fault but their own for missing a meeting. |
|
@developerkevin please keep your comments on the topic of the 9/25 CDC meeting. Thank you. You're welcome to attack me personally in Discord. |
|
I absolutely do no think we should move it back nearly a week. We should stick with the original date and time, as @antsankov said as well. Those are not attacks. They are facts. |
|
Perhaps you would rather it be 9/10? Or the monday following 9/11? Some people might be mourning the death of loved ones, the scheduler made the decision to honor their mourning and the date was adjusted within 24 hours from being posted. I believe that was an empathic decision and I appreciate him for that. So we should likely just keep moving on here and discuss the agenda for 51% attacks as that is the pressing issue for the network. But to entertain your thoughts and opinions, outside of the human element of this scheduling: Personaly, I think 9/25 is a good time as that is plenty of time for the public to become aware of the CDC meeting for large attendence and sufficient time to digest the 51% attack proposal presentations. |
|
No I think we should keep it at Sept. 11, 2020 @ 4 PM UTC. One week from now is plenty of time. |
|
Has ECIP-1092 scheduled their presentation? #364 The ECIP-1097 presentation was today #361 and ECIP-1043 is humming along in Assuming @Dexaran and the people presenting ECIP-1092 are comfortable presenting their proposal prior to 9/11 and think the community will have sufficient time to digest the material, then I think you can make a case for a rushed 9/11 meeting for the ECIP-1049 timeline. But then we have to fit the ECIP-1049 discussion on top of the 51% conversation. Which is a very large meeting with high impact on the network. it will likely be one of the biggest meetings Ethereum Classic has ever held. While it might not be an exceptional day and may result in surpressed turnout, is a satisfactory date and could be poetic due to the significance of 9/11. So there is that element to the idea. I personally am a bit more conservative and think the general public needs more time to digest the material, as they are not likely as plugged in as all of us. That is why I think 9/25 was a good alternative by @q9f. Also i think if we try to jam too many important large topic ECIPs in this meeting we will lose focus and the ECIPs at the end of the meeting will likely suffer proper discussion due to time constraints. |
Should we be eating up time on a CDC so you can hold a Q&A on your ECIP-1049 proposal that has so many comments you don't have time to answer them? (#8 , #13 , #342) Let's think of a productive approach to this: Can you host your own Q&A outside of the CDC process like other development teams are doing (1097 and 1092)? This is a win/win because it does not drain the limited CDC resources to your proposal and let's ECIP participants focus on the immediate 51% attack solutions that could improve the network right now. And it allows you to host a ECIP-1049 specific Q&A meeting on 9/11. That feels like a nice accommodation. Format thought: You could read through every comment that is unanswered, Record the response to them on 9/11 for the public to consume and digest. Then your proposal can continue to be reviewed on the October 9th date that was set on the 8/28 CDC 6 week review timeline. #333 (comment) That seems like a fair compromise to the process and the proponents of ECIP-1049. Your proposal would not help the network for at least a year if I am reading correctly. So that is why I am suggesting we prioritize the 51% attack solutions that help in the immediate over long term approaches to network stability like ECIP-1049. @antsankov |
|
@q9f Can you clarify what the intent of Call 13 for clear messaging to the general public? Are we doing Q&A and engaging in Can you explain the process for those of us that are new? Thank you @q9f. You are appreciated. This is what i see from the 8/28 CDC results: #333 (comment)
|
Great @antsankov I am compiling every unanswered question for your team to address during this 9/11 Q&A on ECIP-1049. Right now I count 27 questions (#8 , #13 , #342), some are multi-pointed questions though. So we should schedule a substantial amount of time for this review as it is not my intent to dominate the entire conversation, but to give your proposal a thorough review for the general public to digest the full ramifications of what you're pushing on the network during these chaotic times. I've posted two large lists of the questions in the While I heavily disagree with your proposal and will be there to represent the vocal opposition, I'm looking forward to learning how your team has addressed the abundant criticism of ECIP-1049 in detail. (#8 , #13 , #342) Thank you. |
|
@q9f i'm reading the discussion in #general occurring right now. Since we are hold a 9/11 call. Should we prioritize the 51% solutions to get them moving through the process? I am having a hard time mentally justifying prioritizing ECIP-1049 (a one year plus roll out) over the 51% attack solutions that address the immediate threat to the network: So high priority ECIPs: Once these three ECIPs are in motion we have ALL year to discuss moving the network to SHA3, as the network will then be out of the current fire. Do any of the current ECIP participants feel that the priority should be on these three 51% attack ECIPs right now and we shouldn't be rushing a miner algorithm change before addressing these solutions and stabilizing the network? Maybe my logic is flawed regarding this issue. Feel free to explain why. |
The priority is the "51% attack protection", in which the ECIP-1043 #11 is the most favorite at the moment (there are no objections till now). But sure, there should be no rush. The proposal championings and discussions can run parallel, if the capacity of the developers/network participants allow it. |
|
ECIP-1043: Just some findings regarding the DAG size.
The theoretical possible limit should be epoch 383 (3.99GB), however, we didn't manage to find a miner that is capable to actually deal with that. Current epoch is 372 (3.91GB) at the time of writing. So we have a soft limit of around 351 and a hard limit of 383. Therefore, we already entered the critical phase of DAG size.
This really needs to be updated. It looks like this is no longer a viable option. Edit: and block 10M passed a while ago. We should freeze on epoch 382 which starts on block |
|
@q9f I would suggest to test Phoenix Miner 5.1c as it seem to be the most effective from my previous experience. |
|
Phoenix does not work on my operating system. |
|
ECIP-1049: Just some findings on interoberability - I did some research on the implications of vanilla Sha3 and I would strongly encourage to go for Keccak256 rather than Sha3. The main reason is having an OPCODE As an alternative, we could implement a SHA3 precompile but that's also unlikely on Ethereum Foundation network. That way we might lose the freshly gained protocol parity indefinitely. Adopting Keccak256 does not only reduce the complexity but also retains highest compatibility between these ecosystems without much effort as the OPCODE |
|
just a generic concern around adding opcodes, if we added |
That's exactly what I tried to say. ref ethereum/EIPs#2951 |
|
meeting was just moved to Discord because of a security flaw in jitsi https://discord.gg/bNgqUb7 |
|
^ will continue at 4:20 pm UTC. please get setup. |
|
sucks jitsi didn’t work out but the moderation in the other discord prevents many of the team from joining the call. |
|
We can make Jitsi work if we have our own server. This enables us proper moderation roles and tools as far as I understand. I'm sorry that I didn't look into that earlier. |
q9f
added
the
meta:1 governance
|
Hello, I just have to lift the opposition to the Algo change that some people wants to see here. In my eyes, this is very clear; and i don't know who you panic and cry for a CHANGE of algo. We have to keep in mind that a BIG part of ETH mining is ASIC rigs, we know that there are some different ASIC creators that can resume the production if its needed. WE ALSO KNOW that ETH have a thing called ProgPOW in the making, wouldnt this alone make 51% attacks nearly impossible??? What im saying is straight forward and not hard to get. Dont change algo, you will regret it. Upgrade the system to prevent 51%:s, but dont miss out on the big network change with ETH 2.0 Rollup!!! |
|
I am suggesting to make the Call 14, 25th of September, on ETC discord as well: https://discord.gg/3J7ztm. @q9f I need your confirmation to update your first post here. Thank you. |
|
Yes, let's do discord. |
Your link is dead. I believe this is an active invite: https://discord.gg/hQs894U. I've updated a PR for the website's blog. |
|
Given that ECIP-1049 has dominated CDC 11, 12, and 13. It's probably great to allow other proposals to be addressed within the limited 90 minute call on CDC 14 @q9f:
I've scheduled a 120 minute max CDC 15 specifically to talk about ECIP-1049. The author has agreed to show up to that call. So continued conversation on ECIP-1049 can likely wait a week to let all these other proposals have a chance to be discussed. |
Yes, @gitr0n1n, it got invalid. I took your shared one. cc @q9f |
|
I won't be able to speak at the 14 Dev Call, but will be able to listen. However on October 2nd @ 4PM UTC, I will be doing a full call that will be devoted entirely to the subject of ECIP-1049 and Keccak256. Ideally this call can be entirely focused on PirlGuard and Mess, and which one is a better approach. |
|
The 14th's call link was updated again. |
|
Please can we add "ECIP 1097: Checkpointing based 51% attack resistance (Draft)" to the agenda, @q9f? |
|
Good point @bobsummerwill I also see 1094 was proposed, but not sure where that one is at. Agenda51% Proposals
|
|
OK, removed ECIP-1049 and added the other proposals 👍 I'm assuming that the authors of the proposals are informed, otherwise this will be confusing on the call. |
|
Thanks for adding ECIP 1096. We'll be there to present and respond to questions. What is your idea? How much time will be assigned to ECIP 1096 ? |
|
Updated the block numbers for 1099:
Which basically means 4 weeks for Mordor and 8 weeks for the Classic main network. We will reevaluate this in tomorrow's call. |
So, first thing will be finalizing ECIP 1099 which is in last call and we need to update the block numbers to allow for Besu to implement the changes and second part will be discussing the "51% proposals." In the end we will have to decide for one as we most likely will not implement all of them and the core devs have to evaluate if it's sufficient to just implement one protective measure or whether we need multiple. The community sentiment appears to either favor 1092 "Pirlguard" by Callisto or the 1100 "MESS" proposal by the ETC Core working group. The discussion on 1092 was cut off last time, unfortunately, so we will start with that and also allow for comparing with the other proposals. What we could do, because it's five different proposals, that I ask 3-4 questions that each proposal champion has to answer and this will allow us to create some matrix of what the proposals do, what they don't do, and what they require. I'll come up with something by tomorrow. |
|
Will the Berlin HF eips be included in this fork or will there be another later fork for bls12-381 and simple subroutines? |
|
@realcodywburns There has been no discussion about ETH Berlin changes for ETC to my knowledge. |
|
I'm unsure if we should have the Veriblock ECIP on the table for this call as they have not presented their proposal, but plan to. I've been in contact with Max. He says, "We are writing up a ETC-focused "what is PoP and how will it protect ETC" layman's explanation article which we want to publish prior to the call [presentation]." Based on the fact they haven't presented, although having much time to do so, I'm unsure if it would be fair to them to measure a consensus on moving their ECIP either way in the process. They plan on presenting their solution mid-next week as noted by Max here: #360 (comment) To be honest based on what I've seen I see the MESS solution as being the most effective out of the bunch. It also seems it would be much easier to implement into Besu given Chainsafe's affiliation in its creation. Mess seems much less complex and more in line with ETC's decentralized manifesto and declaration of independence, more than nearly all the others which either introduce layers of unnecessary complexity i.e. through new mining mechanisms, adding validators which will require some sort of on-chain governance mechanism (also we've maintaining a network with validators become a bit difficult on Kotti), or relying on a trusted third party whether it be another network or validators. By the way thanks for coordinating this call Afri! . |
|
@bobsummerwill in your absence prior to the attacks we had initial discussions on berlin. Then it was delayed on eth due to geth being the majority client and was postponed until the fall for eth. But it looks to still be un planned for eth so no real rush. |
I like to see the following questions answered during the call (1 min/proposal max):
I will add all answers live to the matrix: https://hackmd.io/@q9/etc-dev-14 |
|
ECIP 1096 :
I would also like to mention that ECIP 1096 provides some key benefits, such being a decentralized solution. |
|
To be more precise on (1) I should add: If ETC wants the solution to be fully decentralized, then some part of the subsidy must be channeled to visibility proof miners by a hard fork. |
|
Thanks everyone. Kevin has a recording. Here are my rough notes:
Important items are bold. |
|
@SergioDemianLerner I have a question regarding your comment below.
Hypothetically if there was some collaboration between the two, would there still be a required tax on mining rewards to pay for "visibility proof miners?" I recall you saying it is possible to use your solution without the need to give any portion of the miner's block rewards to visibility proof miners—would that make this proposal non viable? Would the subsidy provided be temporary and what are the reciprocations of not providing any subsidy to them? To be honest, I don't think taking away a portion of block rewards to subsidize third party miners in order to temporarily protect the network will sit well with the people in ETC, especially the ETC miners and given the many other solutions that don't involve such a mechanism and incentive to outside miners. |
|
An audio recording for the Call 14 was added in the first post (q9f). |
ETC Core Devs Call 14
Agenda
ECIP 1049 KECCAK256 (Last Call)Moved to call 15 on requestLive-Agenda: https://hackmd.io/@q9/etc-dev-14
Please post all relevant proposals below that should be discussed and evaluated.Agenda submissions are closed.Audio recording: https://youtu.be/_VChbJd87WM
ETC Core Devs Call 13
1401 7587 98for ETCCoreDevsCall13 numbersAgenda
Audio recording: https://youtu.be/9r_q_z81eh4
The text was updated successfully, but these errors were encountered: