Click here for the latest news about cryptocurrencyParity Technologies proposed that it may stop pursuing changes to the ethereum blockchain's software as a way to recover inaccessible customer funds.
The news comes days after Parity listed four ethereum protocol changes that would reestablish access to the $275 million in ether frozen last month.
That frozen ether was reported caused by a vulnerability in the software.
The four options, which was discussed in a blog post, entailed varying changes to the ethereum's software.
Specifically, changes were to be made to the ethereum virtual machine (EVM) which translates smart contract commands in code.
At an ethereum developer gathering on the subject, Parity spokesperson Afri Schoedon said that its suggested paths for unlocking the funds were unsuccessful in realizing a critical mass needed for its ideas to be coded, proposed and accepted on the network.
Schoedon explained:
"Actually, I don’t want to talk about it, except that one point is that Parity doesn’t want to follow up on the proposals, because we see the feedback was clear and loud."
The comment came after Ethereum Foundation communications lead, Hudson Jameson, inquired about the proposals as part of the meeting's goal.
In a follow-up, Schoeden, who speaks on behalf of Parity at developer meetings and on public forums, said:
"We are not putting any more effort in improving these proposals."
Parity Technologies has yet to comment about its next steps.
Parity Criticized
However, shortly after the developer meeting, the company said on Twitter tweeted that it will be reviewing its options following the response to its blog post.
“We want to thank the community for their feedback on our last post. Your views have been taken into consideration and we will be reviewing further options and will keep you updated!
#Ethereum #Blockchain,” the tweet read.
The post received unforgiving comments not only from ethereum users, but also developers of the open-source network.
In a blog post, ethereum core developer Nick Johnson cautioned that the code changes could have dangerous and unpredictable results.
“Invariants are particularly important because people designing on top of a system often implicitly assume they are true, even when they’re not explicitly described anywhere.
“That means that any time we are considering breaking or modifying an invariant, we should look very carefully to see whether anything could be explicitly or implicitly depending on it,” Johnson explained.
He continued:
“Because of the risks and the level of uncertainty surrounding them, I personally can’t recommend any of the four variants of this proposal for adoption.
“I’m skeptical there is any variant of this proposal that would sufficiently alleviate the risks involved to be worthwhile, though I’m naturally willing to consider new variants with an open mind.”