Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ECIP-1095: Change ETC PoW to "vanilla" Sha-3 Discussion #342

Closed
stevanlohja opened this issue Aug 20, 2020 · 40 comments · Fixed by #372
Closed

ECIP-1095: Change ETC PoW to "vanilla" Sha-3 Discussion #342

stevanlohja opened this issue Aug 20, 2020 · 40 comments · Fixed by #372
Labels
status:8 rejected ECIP has been rejected by the community. type: std-core ECIPs of the type "Core" - changing the Classic protocol.

Comments

@stevanlohja
Copy link
Contributor

stevanlohja commented Aug 20, 2020

This issue is the discussion for ECIP #341 which proposes to change the PoW to vanilla Sha-3

@stevanlohja
Copy link
Contributor Author

stevanlohja commented Aug 21, 2020

#341 (comment)
@developerkevin To my understanding I'm waiting for an ECIP editor to assign an ECIP number, then the document would be ECIP-#### (assigned number).

Vanilla is often used in programming and other computing systems to simply mean a "non-customized" version or "original". Another way to say "vanilla Sha-3" would be "Sha-3 standard". For example, Keccak-256 produces different hashes than the official Sha-3 algorithm so Keccak-256 would not be vanilla Sha-3 or standard Sha-3.

@developerkevin
Copy link
Member

Thank you for the information @stevanlohja. However we've never used that term to ECIPs, ever. I think this may add a degree of complexity for anyone reading. Just — why is the first ECIP, as it is today, one not okay?

@developerkevin
Copy link
Member

Thanks for the explanation @stevanlohja! It's just "vanilla" has such different connotations IRL. Like, "That person is so vanilla (boring) or square" - thought it was meant to be taken in a "non-serious" manner. Thanks for clearing that up.

@q9f
Copy link
Contributor

q9f commented Aug 24, 2020

However we've never used that term to ECIPs, ever.

We used to have a vanilla istanbul ;) #280

@q9f q9f added status:1 draft ECIP is in draft stage an can be assigned ECIP number and merged, but requires community consensus. type: std-core ECIPs of the type "Core" - changing the Classic protocol. labels Aug 24, 2020
@q9f
Copy link
Contributor

q9f commented Aug 28, 2020

Questions from the review:

  • Why SHA3 instead of Keccak256? Keccak256 is already part of the client and ECIP-1049 would be much simpler to execute. ECIP-1095 would require clients to implement both SHA3 and Keccak256 which might lead to confusion.
  • How would a transition to SHA3 look like? Having a hardfork block is not sufficient to securely swap out the consensus.

@q9f q9f changed the title Change ETC PoW to "vanilla" Sha-3 Discussion ECIP-1095: Change ETC PoW to "vanilla" Sha-3 Discussion Aug 28, 2020
@q9f q9f added status:0 wip ECIP is still work in progress and shall not be merged. status:1 draft ECIP is in draft stage an can be assigned ECIP number and merged, but requires community consensus. and removed status:1 draft ECIP is in draft stage an can be assigned ECIP number and merged, but requires community consensus. status:0 wip ECIP is still work in progress and shall not be merged. labels Aug 28, 2020
@q9f
Copy link
Contributor

q9f commented Aug 28, 2020

there will be a working group for SHA3 and Keccak256 formed asap, action items:

  • working group to merge these proposals (Stevan & Alex)
  • figure out and specify a proper transition from Ethash to the new algorithm

This is now in last call (6 weeks) as per #333 see also #355

@q9f q9f added status:5 last-call ECIP has been accepted and is waiting for last-call reviews. and removed status:1 draft ECIP is in draft stage an can be assigned ECIP number and merged, but requires community consensus. labels Aug 28, 2020
@slashbinslashnoname
Copy link

What is the asic resistance of this ? None ?

@ponchoetc
Copy link

No i dont ACCEPT Sha3 ALGO

Miners dont accept to bought new equipment only because theres software issues.
Miners dont accept to monopolize the asic manufacture...
I alredy see that in DASH with BITMAIN. Dont screw ETC With a easy Solution.

@gitr0n1n
Copy link
Contributor

there will be a working group for SHA3 and Keccak256 formed asap, action items:

  • working group to merge these proposals (Stevan & Alex)
  • figure out and specify a proper transition from Ethash to the new algorithm

This is now in last call (6 weeks) as per #333 see also #355

Where can we follow this working group? I assume it will be an open process. Correct me if I'm wrong.

@gitr0n1n
Copy link
Contributor

What is the asic resistance of this ? None ?

There are alternative proposals, ECIP-1093 is a CPU ASIC resistant option.

There are also GPU favorable options like ECIP-1043 which related to manipulating the DAG to ecure ETC majoirty Ethash equipment.

@Dexaran
Copy link
Contributor

Dexaran commented Sep 2, 2020

I am totally against this proposal.

This proposal is counter-productive. It only proposes to change things but there are no benefits in doing so.

This will bring no improvement to the network and thus it is just an unnecessary stress for the ecosystem and a waste of development resources. This will also discourage significant part of the community and potentially lead to the ideological split that ECIP process suggests to avoid at all costs.

There are two reasons why this proposal must be rejected:

  1. It is unnecessary because it does not propose to improve any aspect of the Ethereum CLassic project. It only proposes to change things without actually improving anything.

  2. It goes directly against the principle of decentralization and neutrality.

This proposal goes stright against the principles of the network because SHA-3 is an ASIC-friendly algorithm. ASICs will lead to centralization of mining power. This goes against the Crypto Decentralists Manifesto.

It’s impossible to achieve these blockchain characteristics without the system being truly decentralized. If any aspect of the blockchain system becomes subject to centralized control, this introduces an attack vector enabling the violation of one or more of the key blockchain characteristics.

Without neutrality, the system is skewed towards one set of participants at the expense of others. In that case, it’s less likely to gain universal acceptance and maximize network value for everyone.

In case of adopting the SHA-3 mining algorithm the system will be definitely skewed to the benefit of ASIC owners. GPU mining is more decentralized than ASIC mining.

The "Rationale" of this proposal is completely improper

Enhanced security: Sha-3 is the latest member of the Secure Hash Algorithm family of standards and certified by the Federal Information Processing Standards (FIPS) [2].

Yes it is true. However it has nothing to do with the Ethereum CLassic, the network and the mining algo. This phrase is just a fact. It is not a proper rationale to change things. It is not a description of any benefit that the network will get from adopting this ECIP.

Reduced risk of non-compliance: Software agreements can have complex compliance criteria and compliance audits can be time consuming or simply a deal-breaker. Having a standardized cryptographic hash function would reduce the risk of non-compliance as vanilla Sha-3 is certified by trusted organizations and has been thoroughly vetted to obtain its place in the Sha family [3].

This is fact as well. Not a rationale for changing the mining algo.

Enhanced productivity: Sha-3 is a solidified cryptographic function with certification and documentation. This reduces research and maintenance costs for engineers especially since Sha-3 ASIC chip designs are available.

ASIC-friendly mining algorithms are not what a decentralized network must adopt.

Less PoW Competition: There are no major public blockchains whom use Sha-3 for PoW. Ethereum Classic's current market status to adopt Sha-3 would make it the majority chain for its respective PoW without having to compete in existing PoW ecosystems for miners.

It is a double edged sword. Not only ETC will gain a status of "unique" mining chain but also it will become incompatible with ETH mining hardware which represents a significant part of the hashpower market.

@gitr0n1n
Copy link
Contributor

gitr0n1n commented Sep 2, 2020

As stated in more detail in the original ECIP-1049 proposal, I am against these moves to SHA3 or whatever varition of it. Please review the original ECIP-1049 for justification, as this proposal is more of an appendex to that far more detailed discussion.
#13 (comment)

My personal recommendation will be to move ECIP-1049 and ECIP-1095 back to Draft status as there are far too many unknowns related to the proposal. If the authors of these proposal don't believe they can accomplish this change in a decentralized manner. I recommend they mark these proposals as Withdrawn.

Outside of the unknown concerns. I also agree with @Dexaran's opinions above and do not think this move to ASIC is in the spirit of the Ethereum Classic network. This is a RADICAL change and DOES NOT improve the network security when looking at the proposals impact as a whole. Huge centralization risks on one of the most foundational elements of the network. For these reasons I would push that ANY centralized ASIC proposal be pushed to Rejected status.

@XoxoPH
Copy link

XoxoPH commented Sep 2, 2020

When ETC algo change to SHA3 it will be the end. Crypto miners will not buy another equipment for this coin if its moved to SHA3 its a waste of money they will just moved to other coin instead of buying asics just to mine ETC besides moving to SHA3 doesn't mean your already safe from attacks 💁‍♂️

@prestwich
Copy link

it will become incompatible with ETH mining hardware which represents a significant part of the hashpower market.

Yes. This is the goal. As a minority chain in a large compatible hashrate market, ETC is experiencing regular 51% attacks. Removing hardware compatibility with other chains is the only solution

@gitr0n1n
Copy link
Contributor

gitr0n1n commented Sep 2, 2020

it will become incompatible with ETH mining hardware which represents a significant part of the hashpower market.

Yes. This is the goal. As a minority chain in a large compatible hashrate market, ETC is experiencing regular 51% attacks. Removing hardware compatibility with other chains is the only solution

At the risk of centralizing the entire mining ecosystem (all future inflation and network security) on a small, unknown supply chain? Can anyone from the pro-SHA3 side address this concern of extreme centralization?

@ponchoetc
Copy link

Centralization of hashrate is the worst thing ETC need to do, its needed software improvements.. not only changing algo en pray god all the issues gone, if you change ethash algo you willl kill the potential grown of ETC With all ETH Miners that will migrate into ETC When eth 2.0 arrives

I dont know why ETC Dev are forced to trying in every way kill ethereum classic
they want to split community into these words we as a important part of ethereum classic we don't accept sha3 we don't accept centralization of ETC
that does not represent what ETC Is

and if you ETC DEV you continue with this ridiculous statment about sha3 you can see... that any miner will head with you..
and you will lose the strongest part of a Proof of work ecosystem
please regreet this actions and Improve into real solutions dont make ETC Centralized.

@prestwich
Copy link

it will become incompatible with ETH mining hardware which represents a significant part of the hashpower market.

Yes. This is the goal. As a minority chain in a large compatible hashrate market, ETC is experiencing regular 51% attacks. Removing hardware compatibility with other chains is the only solution

At the risk of centralizing the entire mining ecosystem (all future inflation and network security) on a small, unknown supply chain? Can anyone from the pro-SHA3 side address this concern of extreme centralization?

How could it be more centralized than repeated 51% attacks?

@creepas
Copy link

creepas commented Sep 2, 2020

I would ask who is creating the asics. As from our miners experience there is "asic" mafia and even big miners have problems to recive asics in time. Specially if it will be limited. We also need to consider if by removing main component of networks (GPU miners) it will have good impact and what other changes it might bring. We also did study and i dont opose fact that if you are majority chain on that algo its much better than to be minority on Ethash, but .... who can say that you for sure will be biggest? Maybe you will be biggest on start and than in 1 year same stuff will repeat? It doesnt solve the problems we have now and it seems super complicated solution for problem that seems is possible to solve by eicp 1092 and 1097, 1043.

@prestwich
Copy link

There is very little practical difference between a 51% attack and a 100% attack. Both allow arbitrary depth reorgs and theft from other users. The only effective defense against 51% attacks is to be the majority chain for a specific hardware compatibility group. Bitcoin is the majority sha256d ASIC. Ethereum is the majority GPU chain. Your choice is to continue being 51% attacked every few weeks until ETC is dropped by exchanges and other services, or to switch the algorithm to try to become the majority chain in a new ASIC

@Dexaran
Copy link
Contributor

Dexaran commented Sep 2, 2020

@prestwich

The only effective defense against 51% attacks is to be the majority chain for a specific hardware compatibility group.

You are completely wrong. See ECIP 1092.

51% attack is just a flaw of the consensus model and it can be easily addressed at protocol level with minimal efforts. There is no need to switch the mining algo or appeal to arbitrary market forces.

Callisto Network is a live proof of the GPU minority chain that can definitely exist in a harsh competitive environment without getting 51% attacked.

@Dexaran
Copy link
Contributor

Dexaran commented Sep 2, 2020

A bit more info regarding the Nakamoto consensus and the detail that enables "stealth mining" attacks: https://gist.github.com/Dexaran/b7c23ec264019665cffd35d35bc26ee9

@ponchoetc
Copy link

I can read that any Actual Miner of ETC Support this.. so why you change that? better improve software solution to fix those 51% attacks instead of kill the only who support etc... the miners, etc dev don't fall apart the miners we are important for ETC Ecosystem

STAY ETC DECENTRALIZED Don't make it a China coin.

@Dexaran
Copy link
Contributor

Dexaran commented Sep 2, 2020

Unlike ECIP 1092 or ECIP 1097 which actually propose to SOLVE 51% attacks this ECIP does not represent a solution.

Changing the mining algo is not a solution at all. This does not solve the problem per se but instead is just delaying it in hope that things will go fine in a new environment while it is far from guaranteed.

  1. It is far from guaranteed that ETC will become the majority chain on a new mining algo. It is possible that there will be another "newer and more overhyped project" that will attract more miners and we will get exactly the same situation. But with new mining algo.

  2. "The effect of Chandler Guo" must be taken into account. There is a historical evidence that some influential party may coordinate a 51%-attack for some (possibly political or even personal) reason. So did Chandler Guo and his 51pool at the very start of Ethereum CLassic project before we convinced him to join our ecosystem instead. It is possible that some other party will do the same. Due to the lack of a technical solution at the protocol level, this would make ETC similarly vulnerable to 51% attacks.

  3. Since another solution at protocol level is still a necessity (as highlighted in previous two points) - changing mining algo is completely unnecessary and likely harmful for the ecosystem.

@ponchoetc
Copy link

Hope this ECIP Teach ETC Dev that Community does not Support a Algo change. we support the ETC Network But a algo change is Useless and eventually will give you the same result. we need solutions for 51% attacks like checkpoints or any system Not changing ALGO

@q9f q9f pinned this issue Sep 4, 2020
@vikpat11
Copy link

vikpat11 commented Sep 4, 2020

I have a few questions for those who say changing ETC algo to SHA3 is the only or the best solution to prevent a 51% attack on the ETC network.

  1. Is SHA3 algo ETC planning to implement, same as the one used by the Smartcash and Max coin (Keccak)? if so,

  2. Will it be possible to dual mine it with Ethash using Claymore miner?

  3. If dual mine is possible, ETC will be the free cake for all ETH miner and All ETH miners will get the ETC almost for free. That will give negative implications on ETC's economic development (price growth) [It's human nature, we do not care for the things which we get for free]. What is the guarantee that those Ethash dual miners will not dump dual mined ETC right away?

  4. The question-3 also arises the further question about what if those Ethash dual miners will make extra hash power available on renting services. Sorry but Miningrigrentals already has +15 THs power available for rent (https://www.miningrigrentals.com/rigs/sha3).

  5. Few here mentioned that by implementing SHA3 we will be majority chain, How can you guarantee that? Maybe we will remain the majority chain for some time. What if some other popular project will implement SHA3! We all know Monero did think about switching to SHA3, though it did not go forward with that. What is the guarantee that they will not think again about switching to SHA3?

@ghost
Copy link

ghost commented Sep 5, 2020

ECIP-1043 only leaves ETC still vulnerable to attacks, the whole point of the hard fork is to change that.

Hard forks are a security hole in themselves, you can't go hard forking as if it were a walk in the park. To solve the fundamental problem of ETC's 51% vulnerability the only option is to move to sha3 (ECIP-1049 + 1095) ASAP.

Whether miners come or not is dependent on the payment per block and the certainty they assess that they will actually get that payment as opposed to being reorg'd all the time as it's happening now.

A change to sha3 is not a "reset of the ecosystem", it's only a legitimate mining algorithm change given the obvious vulnerability and real life attacks ETC is suffering.

[the above is an opinion I wrote on discord so I post it here for the record]

@Dexaran
Copy link
Contributor

Dexaran commented Sep 5, 2020

@tokenhash

To solve the fundamental problem of ETC's 51% vulnerability the only option is to move to sha3 (ECIP-1049 + 1095) ASAP.

Again, you are completely wrong.
First, changing the mining algo is not a solution to 51% attacks at all. It is just a delayment of the problem and a "theoretical hope that in a new environment things will be different" without any actual difference on tech level.

Second, this is in no way "the only solution" because ECIP 1092 and ECIP 1095 propose another options that can effectively solve the problem at protocol level. There is the live evidence that ECIP 1092 can definitely solve the problem of 51% attacks for Ethash chains.

Whether miners come or not is dependent on the payment per block and the certainty they assess that they will actually get that payment as opposed to being reorg'd all the time as it's happening now.

Miners are dependant on hardware. In case there is no suitable hardware ready for deployment the "establishment phase" right after the algo switch is even more dangerous than being a minority chain. It renders the chain vulnerable so that a malicious actor can invest a relatively small quantity of funds to disrupt and destroy the network completely.

A change to sha3 is not a "reset of the ecosystem", it's only a legitimate mining algorithm change given the obvious vulnerability and real life attacks ETC is suffering.

I completely disagree. Changing the mining algo from GPU-friendly to ASIC-friendly is not a legitimate change of the mining algorithm.

Sha3 is an ASIC-friendly algorithm and ASIC mining is more centralized than GPU mining. This goes directly against the core principles of the network.

https://medium.com/@bit_novosti/a-crypto-decentralist-manifesto-6ba1fa0b9ede

@gitr0n1n
Copy link
Contributor

gitr0n1n commented Sep 5, 2020

ECIP-1043 only leaves ETC still vulnerable to attacks, the whole point of the hard fork is to change that.

Hard forks are a security hole in themselves, you can't go hard forking as if it were a walk in the park. To solve the fundamental problem of ETC's 51% vulnerability the only option is to move to sha3 (ECIP-1049 + 1095) ASAP.

Whether miners come or not is dependent on the payment per block and the certainty they assess that they will actually get that payment as opposed to being reorg'd all the time as it's happening now.

A change to sha3 is not a "reset of the ecosystem", it's only a legitimate mining algorithm change given the obvious vulnerability and real life attacks ETC is suffering.

[the above is an opinion I wrote on discord so I post it here for the record]

I don't know how you can look at Hard Forks as an attack vector, but completely overlook the centralization of the entire mining ecosystem to one small company (EPIC Blockchain). @tokenhash I believe you're blinded by your love for the ETC Coop guys personalities.

This proposal solves none of ETC's immediate problems today. The rollout will be well over a year and you will land in the hands of one little centralized group. If that is the path you'd like to take, by all means pursue it. That will be a NEW PROJECT with NEW CORE PRINCIPLES. ETC will continue to move on with its current algorithm and current core principles; without your forked chain and its disruptive participants during a chaotic time in the network's history.

@slashbinslashnoname
Copy link

Totally against this proposal as it is asic friendly and as it doesn't protect from 30% attacks

@TheEnthusiasticAs
Copy link
Member

TheEnthusiasticAs commented Sep 6, 2020

  1. The objection argument "the centralization by one ASIC manufacturer":
    If there will be a demand for such devices, other companies will start to manufacture these, too. It is how a market work. Supply and demand. As it is easy to produce, based on the argument of the original championer of the SHA3/Keccak for the Ethereum Classic, the prices would also be relatively affordable.

  2. "The IoT-goal of this project":
    The aim of this project is to be IoT suitable. For it should have the highest avaible security standard. The security standard of the Ethash is not enough based on the recent news provided by the original championer of the SHA3/Keccak for the Ethereum Classic. This means, that this project would remain as a hobby project and people invested in this project with their time and money will be down the drain.

  3. The objection "it does not protect against the relatively large reorganizations in the network":
    Nobody said, that it will. What was said, is, that it will give a chance to be a major blockchain with this algorithm. This project is popular. Higher the algo standard, more attractive it will get, more (serious) people would be interested to do on/with this project, value would go higher, more miners would join, more secure the network would be, fewer the chance the network would have relatively large reorganizations.

@Dan-UVC
Copy link

Dan-UVC commented Sep 6, 2020

1. The objection argument "the centralization by one ASIC manufacturer":
   If there will be a demand for such devices, other companies will start to manufacture these, too. It is how a market work. Supply and demand. As it is easy to produce, based on the argument of the championer, the prices would also be relatively affordable.

2. "The IoT-goal of this project":
   The aim of this project is to be IoT suitable. For it should have the highest avaible security standard. The security standard of the Ethash is not enough based on the recent news provided by the championer. This means, that this project would remain as a hobby project and people invested in this project with their time and money will be down the drain.

3. The objection "it does not protect against the relatively large reorganizations in the network":
   Nobody said, that **it will**. What was said, is, that it will give a chance to be a major blockchain with this algorithm. This project is popular. Higher the algo standard, more attractive it will get, more (serious) people would be interested to do on/with this project, value would go higher, more miners would join, more secure the network would be, fewer the chance the network would have relatively large reorganizations.

All of this. Well articulated and aligned with my views. I'm enthusiastically in favour of heading down the route of this ECIP - yes the 51% vulnerability needs sorting soon - but this should be the goal for the chain as soon as feasible (i.e. within the next year).

We need to move beyond Ethash to be our own giant. Yes - there are concerns that miners have over the equipment they have invested in - 100% get that - but just because you have GPU rigs doesn't mean the overall future of the project should be limited to only use those.

I firmly believe that the ASIC = centralisation argument doesn't fly. Where there is money to be made - entities and people will invest. Supply and demand as said above.

I wanted to add this - not to add anything new to the argument - but to show support.

@JMc-GH
Copy link

JMc-GH commented Sep 6, 2020

We need to move beyond Ethash to be our own giant. Yes - there are concerns that miners have over the equipment they have invested in - 100% get that - but just because you have GPU rigs doesn't mean the overall future of the project should be limited to only use those.

I get this, but why not take advantage of all that GPU hashpower that will soon(ish) no longer be mining ETH?

If the objection to retaining Ethash is that it is not secure enough, now or in the near future, to reduce the risk of a 51% attack to an acceptable level then that is a strong arguement for change. Is this the case though? If not and the argument for change is something other than attack prevention then I remain to be convinced.

@Dan-UVC
Copy link

Dan-UVC commented Sep 6, 2020

Who knows when ETH 2.0 will happen. But I wouldn't like to stake everything on the assumption that ETH 1.0 disappears. I've got a strong feeling that their PoW chain will continue.

@TheEnthusiasticAs
Copy link
Member

We need to move beyond Ethash to be our own giant. Yes - there are concerns that miners have over the equipment they have invested in - 100% get that - but just because you have GPU rigs doesn't mean the overall future of the project should be limited to only use those.

I get this, but why not take advantage of all that GPU hashpower that will soon(ish) no longer be mining ETH?

If the objection to retaining Ethash is that it is not secure enough, now or in the near future, to reduce the risk of a 51% attack to an acceptable level then that is a strong arguement for change. Is this the case though? If not and the argument for change is something other than attack prevention then I remain to be convinced.

For the short term there is the ECIP-1043 #11, which had no objection till now, is in the last call and would satisfy all the participating groups of the network.

@q9f
Copy link
Contributor

q9f commented Sep 6, 2020

Closing as duplicate of #13 - please redirect all discussion to #13.

@q9f q9f closed this as completed Sep 6, 2020
@gitr0n1n
Copy link
Contributor

gitr0n1n commented Sep 6, 2020

  1. The objection argument "the centralization by one ASIC manufacturer":
    If there will be a demand for such devices, other companies will start to manufacture these, too. It is how a market work. Supply and demand. As it is easy to produce, based on the argument of the original championer of the SHA3/Keccak for the Ethereum Classic, the prices would also be relatively affordable.

My issue with your logic is that you give a 100% monopoly to Epic Blockchain on the entire network of Ethereum Classic and all of its inflation until the supply chain for SHA3 ASIC matures to a point of being decantralized. Surely, you can see the risks in this are far greater than a 24 hour reorg.

So ECIP-1049 and ECIP-1095 reaction to the 51% attacks is to accept a huge centralization of the ETC network, then HOPE the tech developed on the network via a treasury stimulates market forces to decentralize that massive centralized supply chain hole in the SHA3 path.

This is a $1B network, we can not be leaving the network centralized in this manner until a supply chain matures. ALL of your ideas are great on a NEW PROJECT where the market is trying to find its valuation. ETC is simply too mature of a network and the supply chain you're attempting to pivot to is too immature, that is what makes this change so irresponsible.

  1. The objection "it does not protect against the relatively large reorganizations in the network":
    Nobody said, that it will. What was said, is, that it will give a chance to be a major blockchain with this algorithm. This project is popular. Higher the algo standard, more attractive it will get, more (serious) people would be interested to do on/with this project, value would go higher, more miners would join, more secure the network would be, fewer the chance the network would have relatively large reorganizations.

Yes, this was being sold as a 51% attack solution. And it is being prioritized AHEAD of legitimate 51% attack solutions. I'm glad the pro-SHA3 side is at least now re-messaging that this is NOT a solution to 51% attacks. But do not mistakes, this was sold as a 51% solution in 2019. And it was sold as a 51% solution until about one week ago when the messaging changed.

@q9f q9f unpinned this issue Sep 10, 2020
@q9f q9f added status:8 rejected ECIP has been rejected by the community. and removed status:5 last-call ECIP has been accepted and is waiting for last-call reviews. labels Sep 11, 2020
@q9f
Copy link
Contributor

q9f commented Sep 11, 2020

rejected in favor of keccak in #372

as per decision at call #362 (13)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:8 rejected ECIP has been rejected by the community. type: std-core ECIPs of the type "Core" - changing the Classic protocol.
Projects
None yet
Development

Successfully merging a pull request may close this issue.