Ethereum Core Devs Meeting 54 Agenda

[Souptacular]

Ethereum Core Devs Meeting 54 Agenda

• Meeting Date/Time: Friday 1 February 2019 at 14:00 UTC
• Meeting Duration 1.5 hours
• YouTube Live Stream Link
• Livepeer Stream Link

Agenda

1. Roadmap a) Constantinople - Ropsten fork? b) Istanbul Hardfork Roadmap c) Outlook: PoS finality gadget on PoW chain (Serenity) d) ProgPoW audit?
2. Working Group Updates a) Ethereum 1.x Stanford Meetings Overview b) State Rent c) EWasm d) Pruning/Sync e) Simulation
3. Testing Updates (time allowing)
4. Client Updates (time allowing) a) Geth b) Parity Ethereum c) Aleth/eth d) Trinity/PyEVM e) EthereumJS f) EthereumJ/Harmony g) Pantheon h) Turbo Geth i) Nimbus j) Mana/Exthereum
5. Research Updates (time allowing)

[atlanticcrypto]

My two cents:

https://medium.com/@brianventuro/saving-ethereum-why-i-stand-behind-progpow-b4679c3089dd

[holiman]

That would be a chain split. I think we should all try to avoid it

I don't know. I think it may be the ideal solution at this point. So,

• If we make sure not to bundle the progpow switch with anything else,
• And agree on a block number,
• And make sure that both Geth and Parity have releases that are capable of switching to progpow at the given block number,

Then let the world decide. At this point, I personally feel that we've already had all the discussions, and it's about time to progress.

I'm not saying that we shouldn't do an audit, the more eyes the better, sure, but I don't have any illusions that an audit will settle any debates or even make a decision easier.

Also, regarding an audit, what is to be audited?

• The technical sanity of Progpow over Ethash?
• Cryptographical analysis of progpow hashing algo in general?
• The feasibility of building progpow in specialized hardware?
• The security of GPU-mining versus specialized hardware-mining?

My point is, there are so many different aspects being discussed, and an audit will only focus on one of these points -- hence why I don't think it will settle anything.

[AndreaLanfranchi]

@gcolvin I'm not saying 1.0 will be iced. Proof of Work on 1.0 will be iced. Difficulty bomb will drive the transition from PoW sealing (which will become so difficult to be practically only a waste of of electricity) to PoS sealing. Thus the stake on 1.0 has reasons. Blocks will continue to be chained but will be sealed under different rules.

[ASICseer]

All current proponents of progPOW fail to understand these two points:

1. The original proponents of any proof-of-work change will stand to benefit if they are well-prepared to take advantage of it. ProgPOW was first proposed in May of 2018, and it has been 8 months since then. This is plenty of time for the original proponents to develop secret mining optimizations for it, for which the rest of the ecosystem is not privy. This means that, if progPOW is activated, they will be able to spin up optimized farms very quickly. Note that, even though the algorithm is open source, it does not mean that optimizations cannot be made for it. Remember that scrypt, x11, and equihash all had neat little memory-hardness tricks that were supposed to stop ASICs, but they didn't. Which leads me to my next point:

2. Either the original proponents of progPOW (ifdefelse) are stupid (Scenario A), or they think YOU, the listeners are stupid enough to believe their lies (Scenario B). There is simply no room for anything else.

Scenario A: Even though the last 6 years of history has shown that cute little memory-hardness tricks fail to stop ASICs, the progPOW team thinks that they are so smart that they've thought of every single nuance, every single caveat, every single way, for their algorithm to be exploited. Somehow, they are different from every other team. And you know, maybe there are. But, that is extremely unlikely and especially unlikely given that 2/3rds of the team are anonymous with absolutely no track record. We can't verify their previous work even if we wanted to.

Scenario B: The progPOW team is actually smart, so smart that they've already figured out how to optimize hardware for their algorithm, and are spinning a bunch of populist/socialist platitudes to get their algorithm adopted so they can profit off it. You may say, "progPOW is open source", but open-source is not a great argument. All previous algorithms for which ASICs were developed were also open source. If an algorithm change occurs on a popular coin, the secret sauce is in hardware, not software.

[AndreaLanfranchi]

@gpushack what you are missing, imho, is ProgPoW is not an algo. An algo, strictly talking, is a collection of finite operations which repeats itself over and over again. ProgPoW is more a process which creates a new algo for the next 50 (or 30 or 10) blocks. It's an automated way to implement what other "ASIC resitant" efforts try to do with scheduled algo changes every x months. The advantage of software over hardware is that is immensely faster to change while hardware needs to be re-engineered, industrialized and delivered.

Memory hardness is enforced in Ethash/ProgPoW on behalf of same DAG while it adds computational randomness (though deterministic) to the hash function so every component of a commodity GPU can be fully utilized.

On the other hand we already know there are ASIC manufacturers which have gone beyond the trouble of memory hardness and will optimize further in near future thus the "battle" of "who profits more" is already lost.

[ASICseer]

@AndreaLanfranchi please excuse my saying so, but the fact that you can't figure out how hardware designers may optimize hardware for progPOW speaks more to your lack of competence in this field than in those same designers' ability to do what you say they can't.

[AndreaLanfranchi]

@gpushack mind my words. No one, literally no one ever said it is absolutely impossible to develop an ProgPoW ASIC. It is possible but there are a few caveats: your hardware will end up being more and more like a GPU and (not irrelevant) the time to delivery of such hardware will completely void it's utility.

As @holiman already said ProgPoW won't be eternal as we all know PoS will be the final target.

Question is : do we want to spend the remaining time (till PoS will be alive) allowing the proliferation of specialized hardware thus cutting off all gpu miners (which are an important ethereum userbase) or do we prefer to try keep them as loyal supporters ? It's a simple answer to this question I am pushing for.

I'm fine with an acceptance or a denial ... but please let's stop this hanging around.

[MoneroCrusher]

@AndreaLanfranchi

@MoneroCrusher agree with all your plan

So you are not against a 3-phase deployment of ProgPoW, that gives all users time to adapt to changes, did I perceive that correctly? Let's go the path of least resistance. @IfDefElse @OhGodAGirl Would you support it? If yes, let's get ahead and get unified community consensus, if not, please describe - from a technical standpoint that everyone understands - why it wouldn't be possible.

[AndreaLanfranchi]

@MoneroCrusher I'll try to be as clear as possible. I totally do not understand (my limitation for sure) the point of "allowing users to adapt changes". If it is meant to a sort of "let's keep a Rx480 to be hashrate comparable to a 1070 (instead of a 1060 - which is actually the league those cards are in)" we're all (devs and implementers) trying to do our best to reduce the gap.

@ifdefelse already posted a proposal here for reducing compute to the minimum possible while ensuring that every mix[] destination gets written to (this is a constraint).

Also in my recent commit the problems about bogus periods on AMD/OpenCL has been solved and there is a further slight improvement on AMD hr.

This said ... a roadmap of 3 soft-forks which have to happen in the limited amount of time left before PoS is IMHO a total waste of time and resources.

Forgive my brutality but things are this way: either GPU users want and accept a single change (optimized at maximum possible extent in very short time for both major vandors) now or let's all stop any research and or development on this and stop wasting time on a thing that causes too much troubles and suspects. In my opinion it's up to GPU users to choose the lesser of evils.

If I was an AMD miner I'd choose to see improved revenues from the forkoff of ASICS instead of whining for Nvidia catching-up.

[MoneroCrusher]

Now you're doing exactly what you accused me of, comparing "whining" AMD owners to Nvidia, can you please stop this? Are you unpartisan in this, as you seem yourself wanting to appear?

My 3-step approach is vendor neutral. You do realize what 60% additional power implicates? You know that the Clinton Nuclear Power Plant took over $4.25 billion in funds to get realized? ProgPoW would represent exactly 50-60% of that, applied to the current Ethereum network. Do you believe 60% additional power will just appear out of thin air, "just plug it into the socket"? No, power is very expensive to install, and instantly doing a 60% power increase will not bring back mining to hobbyist miners and small farms, it will instantly centralize the majority of hashing power into 10+MW farms that have plenty of cheap electricity available and that were planned ahead to have much more power available than needed.

What do you say to a user that has installed the maximum amount of GPUs that they can run in their home (let's say 50 GPUs) and now suddendly power increases by 60% and they can't use a large chunk of their GPUs anymore, because they don't have enough electrons available?

@ifdefelse already posted a proposal here for reducing compute to the minimum possible while ensuring that every mix[] destination gets written to (this is a constraint).

This is for ProgPow_v3. What I am saying is reduce the math in here https://github.com/ifdefelse/ProgPOW/blob/9eec52772cf7b0da99aa08a94eda9c7b6451e730/libprogpow/ProgPow.cpp#L213 to +10-15% (compared to Ethash) in a fork ASAP tagged ProgPoW_V1, then in the Istanbul HF increase core operations to +25-35% of Ethash tagged as ProgPoW_V2 and in the HF after Istanbul implementent the final ProgPoW specification tagged as ProgPoW_V3/final.

This allows users to periodically upgrade their hardware to more efficient hardware that uses less energy (like 7nm litography enables them to) or increase the power output of their electrical installations over time. An instant ProgPoW_V3 implementation would instantly kick of many users off the net and centralize it into megafarms with cheap power.

This said ... a roadmap of 3 soft-forks which have to happen in the limited amount of time left before PoS is IMHO a total waste of time and resources.

Do you have another argument than this? Because it's false. Doing a 10-15% implementation and a 25-35% implementation is just taking out code that is already there and putting it back over a span of 3 HFs that are on the roadmap already, alternatively, if it makes it easier for you to imagine, you can view it like an increasing DAG.

How is my approach vendor neutral? Check this:
Currently we have ethash which is our baseline and is infested by ASICs and large megafarms
After ProgPoW_V1:
---all ASICs gone, profit increases linearly for every ASIC gone for all vendor devices
After ProgPoW_V2:
---all ASICs still gone, profit still being high for all vendor devices
After ProgPoW_V3
---all ASICs still gone, profit still being high for all vendor devices

Bonus: all participants get the chance to adapt to the ever increasing "difficulty" of this manually applied PoW "DAG" (if you want to imagine it like that).

Do you see any preference for AMD or Nvidia in here? If so, please point me to it, I can't see it.

[atlanticcrypto]

Or you could just sacrifice some hashrate and run at less power? Big farms aren't setup to draw up to TDP. This is never going to be perfect, and as said, if this doesn't happen now it will lose steam and be deemed worthless in the future.

[AndreaLanfranchi]

This whole point is beyond my comprehension

My 3-step approach is vendor neutral. You do realize what 60% additional power implicates? You know that the Clinton Nuclear Power Plant took over $4.25 billion in funds to get realized? ProgPoW would represent exactly 50-60% of that, applied to the current Ethereum network. Do you believe 60% additional power will just appear out of thin air, "just plug it into the socket"? No, power is very expensive to install, and instantly doing a 60% power increase will not bring back mining to hobbyist miners and small farms, it will instantly centralize the majority of hashing power into 10+MW farms that have plenty of cheap electricity available and that were planned ahead to have much more power available than needed.

What are we talking about ? Energy efficiency or mining distribution ? If the first ... let's go ASICS without further ado. Full Stop. If the latter then miners will adjust power consumption to their affordable caps.

Assuming the increase in power drain due to ProgPoW "allows" users to go blindly flat-out is, imho, a naive assumption: miners afaik do their maths to gain a profit over costs.

[AndreaLanfranchi]

All miners deal with limited resources. If electricity was free we'd have 1000x more hashpower than now. But it's not ! Power cost acts as a limiter exactly as difficulty.

[MoneroCrusher]

What are we talking about ? Energy efficiency or mining distribution ?

Both.

If the first ... let's go ASICS without further ado. Full Stop.

No, that would centralize the network even more.

If the latter then miners will adjust power consumption to their affordable caps.

Now you're exactly saying what I'm saying, hobbyist and smaller miners adjusting their power cap translates into reduced difficulty, reduced difficulty that would instantly get matched by a megafarm with dozens of Megawatts installed paying 2c per kW/h aka. ProgPoW_V3 would instantly make a shift to megafarms.

Or you could just sacrifice some hashrate and run at less power? Big farms aren't setup to draw up to TDP. This is never going to be perfect, and as said, if this doesn't happen now it will lose steam and be deemed worthless in the future.

That's exactly what I'm saying, large megafarms won't do this, small hobby miners will be forced to.

Why is everyone saying this has to happen now? Let's think this through and find a solution that gets majority support and will keep the Ethereum community unified.

IMO a 3-step implementation of ProgPoW would be the solution for that.

Any arguments besides "it has to happen now or everything is lost", which is a overdramatic expression of "I want increased mining profits NOW" because hey, who doesn't?

As I said many many many times, we need a solution that will make the maximum amount of people happy and that will help decentralization, anyone disagreeing?

[AndreaLanfranchi]

Why is everyone saying this has to happen now? Let's think this through and find a solution that gets majority support and will keep the Ethereum community unified.

Because in 5/6 months or more there is no point in enforcing any PoW change. It's not worth the effort. We're aiming to PoS remember.

Eventually this might be a future for ETC ... not for ETH.

[MoneroCrusher]

ProgPoW in a 3-step implementation isn't arriving any slower than ProgPow in a 1 step implementation if we all agree on it.

We can also just do it the easy way, I make an EIP that does my 3-step implementation of ProgPoW that is opposing EIP 1057 that wants to do a 60% power increase overnight.

Please try to guess which way the majority of the network would align with, given a choice?

Edit: I am not advocating for a contentious hardfork, all I'm saying is let's get all behind a solution that will get the most consensus.

[AndreaLanfranchi]

As I said many many many times, we need a solution that will make the maximum amount of people happy and that will help decentralization, anyone disagreeing?

You won't get it. You'll end up trying and trying to satisfy even the most tiny details: and remember oppositors always shout louder. (Look at what we're seeing here).

For me personally either it's a decided a final-go now or (for me) ProgPoW is tombstoned and will abandon it (really without any anger). And AFAIK also ifdefelse's team won't support any longer.

[MoneroCrusher]

You won't get it. You'll end up trying and trying to satisfy even the most tiny details: and remember oppositors always shout louder. (Look at what we're seeing here).

For me personally either it's a decided a final-go now or (for me) ProgPoW is tombstoned and will abandon it. And AFAIK also ifdefelse's team won't support any longer.

Again, I dont understand this "it has to happen now or everything is lost" binary attitude. Let me tell you, Ethereum will survive another 2 months without ProgPoW and if a solution is found in the meantime that will get majority consensus, then even the better.

[AndreaLanfranchi]

ProgPoW in a 3-step implementation isn't arriving any slower than ProgPow in a 1 step implementation if we all agree on it.

Do you realize the amount of time needed to adjust code of "every" software involved in the stack ? Miners, nodes, light clients, verificators in general. It's a one time shot we can afford. Otherwise there is no point.

[AndreaLanfranchi]

Again, I dont understand this "it has to happen now or everything is lost" binary attitude. Let me tell you, Ethereum will survive another 2 months without ProgPoW and if a solution is found in the meantime that will get majority consensus, then even the better.

Ethereum will survive anyway. It's to be seen if it will fall under control of a totally centralized mining activity (several authoritative figures say "mining is a service ... we don't care where it comes from") or if it will keep an eye on those who contributed to its success (miners).

What is important is to understand that, as in any enterprise, any decision taken when needed is way better than the right decision when it's not needed anymore.

[MoneroCrusher]

ProgPoW in a 3-step implementation isn't arriving any slower than ProgPow in a 1 step implementation if we all agree on it.

Do you realize the amount of time needed to adjust code of "every" software involved in the stack ? Miners, nodes, light clients, verificators in general. It's a one time shot we can afford. Otherwise there is no point.

Do you realize that the code is already fully there? It's literally (oversimplifying) snipping it out and putting it back in over a 3-step timeframe and would happen at the same time as the main HFs.

You could also do it in such a way that it's just uncommenting additional math in the random math loop function.

// Random math between two input values
std::string ProgPow::math(std::string d, std::string a, std::string b, uint32_t r)
{
    switch (r % 11)
    {
    case 0: return d + " = " + a + " + " + b + ";\n";
    case 1: return d + " = " + a + " * " + b + ";\n";
    case 2: return d + " = mul_hi(" + a + ", " + b + ");\n";
    case 3: return d + " = min(" + a + ", " + b + ");\n";
    case 4: return d + " = ROTL32(" + a + ", " + b + ");\n";
    case 5: return d + " = ROTR32(" + a + ", " + b + ");\n";
    case 6: return d + " = " + a + " & " + b + ";\n";
    case 7: return d + " = " + a + " | " + b + ";\n";
    case 8: return d + " = " + a + " ^ " + b + ";\n";
    case 9: return d + " = clz(" + a + ") + clz(" + b + ");\n";
    case 10: return d + " = popcount(" + a + ") + popcount(" + b + ");\n";
    }
    return "#error\n";
}

My proposal is to go for ProgPow implemented over a 3-step timeline and I would fully support that solution. That is my final word with regards to this matter (if further arguments are along the lines "we need it fast or everything is lost"). I need feedback from @IfDefElse / @OhGodAGirl on its technical feasibility, and if they don't agree with it politically, then I will propose an opposing EIP to EIP 1057.

I'd rather see us (and the majority of the network) behind one solution, it will happen much faster that way, which apparently is your goal.

[AndreaLanfranchi]

Commenting lines it's not a way to do things. That is the source which goes into a GPU. Validators (eg. ethash library) don't "compile on the fly" and need a deterministic code to adapt to future changes of the source compiled into gpus.

Anyway ... I understand your points and your proposals. I'm not in favour of them. There is nothing else to say.

[MoneroCrusher]

Commenting lines it's not a way to do things. That is the source which goes into a GPU. Validators (eg. ethash library) don't "compile on the fly" and need a deterministic code to adapt to future changes of the source compiled into gpus.

Anyway ... I understand your points and your proposals. I'm not in favour of them. There is nothing else to say.

Let me put it another way:

// Random math between two input values
//case-set x: ProgPoW_V1
//case-set y: ProgPoW_V2
//case-set z: ProgPoW_V3
//case-set original: see below
std::string ProgPow::math(std::string d, std::string a, std::string b, uint32_t r)
{
    switch (r % 11)
    {
    case 0: return d + " = " + a + " + " + b + ";\n";
    case 1: return d + " = " + a + " * " + b + ";\n";
    case 2: return d + " = mul_hi(" + a + ", " + b + ");\n";
    case 3: return d + " = min(" + a + ", " + b + ");\n";
    case 4: return d + " = ROTL32(" + a + ", " + b + ");\n";
    case 5: return d + " = ROTR32(" + a + ", " + b + ");\n";
    case 6: return d + " = " + a + " & " + b + ";\n";
    case 7: return d + " = " + a + " | " + b + ";\n";
    case 8: return d + " = " + a + " ^ " + b + ";\n";
    case 9: return d + " = clz(" + a + ") + clz(" + b + ");\n";
    case 10: return d + " = popcount(" + a + ") + popcount(" + b + ");\n";
    }
    return "#error\n";
}

"Case-set x" will get implemented now, that represents 10-15% additional core utilization + associated power utilization "Case-set y" will get implemented in Istanbul HF, that represents 25-35% additional core utilization + associated power utilization "Case-set z" will get implemented in HF after Istanbul, that represents ProgPoW_final core utilization + associated power utilization

A couple lines of changed random maths will generate barely any additional and hard work. A lot of code gets changed during the HFs anyway, a few small lines in ProgPow.cpp and its associated files is not big feat. If that's the way the majority of the network would support it, why block it?

[Sonia-Chen]

We are asicmakers and can confirm that @MoneroCrusher 's approach (progpow_v1 v2 v3) would probably make it uneconomic to make ProgPOW asics (i.e. would exclude Chinese chipmakers, that is essentially what it is if you say only Nvidia and AMD are welcome). I'm not sure this is a compliment to his idea, but it's a fact. It would be so messy that, most likely, there would be no customers coming to us for a chip. They would wait and see. We need about 4 million USD and 3-4 months to make a ProgPOW chip that is competitive (anything with ROI < 6 months sells easily).

That is if we decide such a chip is interesting and fits our own long-term ideas. Chipmakers are not idiots running around after random buckets of money. We are actually a decent sized engineering team with some smart folks, you can compare it to a nice-sized crypto software project. Every technical twist and turn that new chip customers come to us for, helps us build our platform for Proof-of-Contribution chips, that is chips that do more than just useless work. We are convinced that in the future there will be protocols that reward direct contribution to the scaling of the network. Rewards for verification, proving, signing, sorting, block speed, etc. Contributing to a network needs to be more economic than attacking the network.

@AndreaLanfranchi in our view, the biggest enemy for GPU miners are not Chinese asicmakers, although they are pretty bad too. The biggest enemy are secret optimizations and access to preferential chip deals that some GPU miners may have over other GPU miners. That is why, from what we see, quite a few independent GPU miners reject ProgPOW. If you want to do something good for them, try to exclude the Chinese (MoneroCrusher's proposal) AND increase the block reward.

The PoW algo decides who gets about 1.6 mio USD every day. Enabling a barely tested algo on a million machines will lead to the biggest chaos in crypto mining history. The original idea was to give that money to whoever can provide the most cryptographic security, not whoever has the best politics and lobbying.

[Daft-Wullie]

Just gonna leave this here: https://www.reddit.com/r/ethereum/comments/alqolj/why_eth_need_to_be_asic_resistant_and_adopt/

[AndreaLanfranchi]

If that's the way the majority of the network would support it, why block it?

I'm not blocking anything. I don't have the power to. I'm simply saying I won't participate to that path. That's it.

[W944]

1. Core devs already set a 'political change' precedent with the reward reduction. Therefore, the POW change decision rests squarely within their responsibilities. Devs, please don't hide and act swiftly.

2. ProgPow EIP 1057 has been introduced 9 months ago. The time for "studies" is overdue. By the time there is an agreement on what should be studied and by whom, another half a year will have passed at this rate, not counting the time for the study itself. Wasn't ProgPow green lit at the last dev call already? Who's going to be the impartial third party. If this panel decides ProgPow is bad and a no go, will there be accusations of them being in Bitmain/Lindzi/Asic's pocket? Just like the ProgPow devs are accused of being in nVidia's pocket? There is no solution that satisfies everyone. There will always be resistance by someone and it is inevitable when money is concerned. What then? Back to where we are now.

3. My worry with the proposed 3-part ProgPow change is that if it has taken us so much time and we didn't even do one Pow change, imagine going through this 3 times :) Maybe someone won't want the first step to be 10-15. Maybe they'd like 5%, or 50%. Maybe some other change? At this point we'd be designing an algo by committee. And as described in my second point, everyone wants something else. Might as well take ProgPow in it's current form and skip the extra grief. It's ready now, let's adopt it.

[MoneroCrusher]

I'm not blocking anything. I don't have the power to. I'm simply saying I won't participate to that path. That's it.

All good then.

3. My worry with the proposed 3-part ProgPow change is that if it has taken us so much time and we didn't even do one Pow change, imagine going through this 3 times :) Maybe someone won't want the first step to be 10-15. Maybe they'd like 5%, or 50%. Maybe some other change? At this point we'd be designing an algo by committee. And as described in my second point, everyone wants something else. Might as well take ProgPow in it's current form and skip the extra grief. It's ready now, let's adopt it.

It's not doing 3 of these, it's taking the current ProgPoW apart and implementing it in 3 steps. We could do a community vote on what core utilization would get chosen. I thought 15%, 30% and 100% would be a good approach.

[AndreaLanfranchi]

@MoneroCrusher Just a technical note though as apparently you've not studied the code so much. For every math operation you remove you have to increment the DAG accesses (via modulo) as only in this way you can touch all elements in mix[] or the crypto strength of the algo is messed up. So you're unbalancing the algo making it even more memory hard than it is now.

[MoneroCrusher]

@AndreaLanfranchi I'm not here to argument about technicalities. A 10-15% additional core implementation is possible. Period. A 25-35% core utilization is possible. Period.

[AndreaLanfranchi]

No problem. Go ahead and propose. In 5 months when you'll be around a table still discussing if it has to be 3 steps or 2 or 5 whith increments of 3% or 5% or 17% or 32% (but only on last saturday of the month) ... well I'll have my glass of wine and will gladly say ... "I told you." Good luck.

[MoneroCrusher]

When you can set up a Nuclear reactor in your backyard to use an additional 60% power or 600MW for your mining change, call me up, my GPUs will be ready to get plugged in.

I very clearly laid it out and it seems you are following your own agenda here.

I said 3 steps I said 15%, 30% and 100%

Anything unclear about this?

Good luck to you too.

[AndreaLanfranchi]

I said 3 steps I said 15%, 30% and 100%

Exactly ... you said ... but apparently you are convinced you'll be able to collect silent and blind consensus around this. You will have to face more than one variant proposal. Anyway ... everyone follow their path.

[AndreaLanfranchi]

@Sonia-Chen please ... your well-mannered effort to try be supportive is genuine and real like Unicorns.

[MoneroCrusher]

Let's plese refrain from personal attacks like that @AndreaLanfranchi. There is a lot of dirt to be thrown, let's not go down that path. Instead focus on what she has to say.

[W944]

Lindzhi is supporting division, to continue with the status quo. They have to recoup their 4 million dollars investment into their Ethash Asic. The longer the community bickers around what to do, and ultimately does nothing, the longer they can mine with their Asics.

[AndreaLanfranchi]

Problem is Linzhi says one thing in public. Totally different things on DM. So, unless you need to defend anyone only because is approving your path, don't enter this matter.

[salanki]

The problem @MoneroCrusher is that there isn’t enough bandwidth for the developers to argue and analyze everyone’s different implementation ideas. It is easy for you to say “if everyone just agreed with me all will be well”. Obviously, if everyone agreed with each other on every little detail there would be no problems in the world. If we want to get to full consensus on every detail, how the rollout should happen etc. we won’t get anywhere. I think your argument is interesting, and it would be worth discussing if we ie. were Monero that is committed to spend a lot of time continuously on PoW changes. However, that is not Ethereum.

We have to sober up and realize that the options we realistically can count on getting implemented is:

A) Nothing - possible end of GPU mining B) ProgPoW rollout as it has been worked on for the past 9 months.

[MoneroCrusher]

I am saying if you go down the path of throwing off people's opinions because of who they are and who they are associated with, it will get ugly real fast in here (hinting at potential IfDefElse relations with various entities), so let's not do that. Keep that on Reddit.

We're here to discuss a solution that will get majority consensus, if you don't agree with my proposal, tell me what's wrong with it, because I sure as hell am sure the ProgPoW implementation as it currently stands will cause sheer havoc amonst the community if it were to be implemented and would stand no chance against a 3 phase implementation if the current GPU network owners were to vote on it (hint hint, who wants a 60% power increase overnight?).

@salanki I think your argument is interesting, and it would be worth discussing if we ie. were Monero that is committed to spend a lot of time continuously on PoW changes. However, that is not Ethereum.

Doing a 3-phase implementation of ProgPoW and continually changing PoW are two completely different matters. It's like saying "I want PoS, but only if it gets implemented in one swift move". So why are we moving to a hybrid system first? This binary type of thinking helps no one.

[MoneroCrusher]

The argument of "but it has been worked on for 9 months" is terrible (and also wrong, it has actively been worked on by the Ethereum devs for 4.5 months, since mid September). If a solution is not good, it's not good. And more often than not, the very first idea is not always the best. https://en.wikipedia.org/wiki/Theory_of_the_second_best

[jean-m-cyr]

In any case, arguing about it here does nothing to advance the cause...

[Sonia-Chen]

@jean-m-cyr agreed, last message from me but since Andrea said something I believe is not right I have the chance to correct that:

@AndreaLanfranchi "Problem is Linzhi says one thing in public. Totally different things on DM." I take this as permission to repost the one unsatisfactory attempt of ours to reach out to you. Until you apologise, we are also not interested in further private messages with you, better keep everything 100% public. You are free to support ProgPOW, it will be an economic disaster for independent GPU miners, and windfall for insider GPU miners. We know that because we know the cost structure of mining, something you cannot see in open source...

..begin DM.. Linzhi: hi Andrea, you there? Do you know where Na Ikmeyong is?

Andrea: Hi. Have no idea ... only thing I know is he/she appears to be from somewhere in Asia (his words). And apparently is inactive since few days right now.

Linzhi: ok! thanks for the reply. I believe 100% you are genuine and not bought by anyone and interested in truth and healthy development of Ethereum etc. I understand you trust progpow and they talked about it for a long time so it's hard for anyone, like us, to come along and just say it's one big scam with really bad actual agenda etc. professional scammers actually. We have started to peel away a few layers of the onion, and I am willing to work with you one by one on these things, and hopefully we are going somewhere. The real story of progpow is that is was invented as a tool to exclude chinese miners, and in return secure access to inside information and special chip deals from nvidia. Proving that is super hard, especially once someone bought into the story. I don't know where you stand right now wrt porgpow, what you think should be done next, or whether you are interested in PoW at all (since PoS is looming on the horizon). I am here to work on PoW, we are a chipmaker and we see a few things that software people just cannot see. Hope Ethereum continues to grow well! if you have questions, please ask. we answer everything to the best of our knowledge, and WITHOUT hidden second agenda (but it is up to the critical investigative mind of anyone, including you, to come to this conclusion!)

Andrea: You have chosen the wrong interlocutor. Sorry but I won't continue this conversation. Regards

..end DM..

[MoneroCrusher]

@jean-m-cyr Why shouldn't we evaluate alternative, potentially better solutions in here?

[AndreaLanfranchi]

See what I mean ?

"Divide et impera"

[MoneroCrusher]

@AndreaLanfranchi There is nothing to be divided and reigned over. Your thinking implies there is a current "owner" of Ethereum. You don't own Ethereum, I don't own Ethereum, nobody does. Everyone can support the variant they like, this is decentralization after all. The majority consensus shall rule, nothing else.

[AndreaLanfranchi]

Re read above (linzhi). Carefully. Take a deep breath and think who's dividing.

[MoneroCrusher]

There is nothing to be divided, let the majority vote, everyone can make up their own opinion with their hashpower. Propose ProgPoW original & ProgPoW 3-phase roll out and let it clash, see who will win, the EF and Core devs can then continue developing on the majority chain.

With ProgPoW (be it ProgPoW original or ProgPoW 3-phase) implementation there is going to be a chainsplit anyway (do you think ASIC owners will just throw their devices into the dumpster?).

[AndreaLanfranchi]

I won't propose nothing else just because I see what you can't or don't want to see. Every time things get agitated around the matter ... lobby enters the game and shuffle cards. They need to take time. That's why I'm so fixed on it's now or never.

Also your statement about the split it's quite controversial. Which chain you think the Ef will follow ? Core devs will develop what ?

[AndreaLanfranchi]

Vote what ever you want. If you don't take action within end of February I can assure ethash will be the first and last algorithm Ethereum will ever see

[MoneroCrusher]

Let's say ProgPoW original gets 80% less hashpower than ProgPoW 3-phase deployment. Which chain should in your opinion the ETH devs build ontop of? I'll let the devs decide that.