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
Create 9 - Change mining algorithm to RandomX #20
Conversation
…gorithm to RandomX.md
Since mainnet launch (approximately 1 year 8 months ago) mining has become concentrated in the hands of a small number of miners with exotic hardware and the network node count has gradually dwindled. A switch to randomX should (initially) promote more distributed mining and encourage community members to run a mining node. As such I personally support this QIP. |
It is very clear by looking to the nicehash Cryptonightv7 rent cost, that some kind of unknown device exists that can mine Cryptonightv7 at much lower cost, which is not known to public. Due to this low cost mining, miners are selling the QRL at any price above their cost, which could be the major reason why QRL price fell at this level. Thus change of the mining algorithm in the upcoming hardfork is not just necessary but very much critical. RandomX algorithm suites very much to this purpose as its more tilted towards CPU rather than GPU. A CPU with higher memory can outnumber the hash rate compared to GPU. Moreover, it will not be easy for anyone to run botnet mining without being noticed, as this algorithm itself consumes heavy amount of CPU Memory. I totally support this QIP. |
Curefrankosflue from the discord qrl chat was early on suspecting the effect of ASICS on the qrl environment, and I am totally on board with his reasoning. I support this QIP |
Sounds like a good plan. Better sooner than later. I support this QIP |
This change seems to be better than the last one https://github.com/theQRL/theqrl.org/blob/master/_qips/migrate_to_cryptonote_v8.md. As Cyber said " its more tilted towards CPU rather than GPU." Also like the fact its been audited. I support this QIP. However keep in mind that a loss of total hashrate can be interpeted by the market to be negative i regards to imutabillity of the Chain. So i think its important to motivate the community to support the price, run full nodes, mine and hold Quanta. |
I support this QIP. If QRL was previously following Monero, the mining algo would need to be changed every 6 months with questionable benefit. With RandomX, there is supposed to be 3+ years until specialized hardware catches up, which would hopefully give more than enough time for POS to be developed and implemented. |
I support this QIP, as I understand it helps holders to mine with our modest GPU/ CPU |
Great reasons have already been left. I won't create any more noise. After a review of the RandomX protocol, and PoC building a miner, I support this QIP. |
Switching to random X protocol could make QRL mining more competitive. As mentioned by others, I also believe the change can have a positive impact on QRL market cap. The heart of a successful coin is the mining community. Creating a fair and competitive space for miners can create exposure and growth. I support this QIP. |
I support this QIP. But i think, that the change of algo should be done before the upcoming harfork, that planned on Jan or Feb. We don't have so much time to allow FPGAs to dominate. |
I support an idea of urgently changing mining algorithm and I like RandomX. But if QRL adopts it attack surface appears. Huge Monero hashrate can be used by pool operators for double spending. What do you think guys on that? What about adopting more GPU oriented but unique ProgPow which has been created, but not being used yet? |
A 51% attack may be mitigated by setting a 'reorg limit' below what exchanges track for deposit confirmation. Reducing the limit is a planned part of the next core client hard fork upgrade. |
That does not add security for the chain |
I support this qip, particularly in combination with emission reduction to 2 qrl. |
I do no longer support this QIP. I think a move to PoS should take priority. See reasons by discord user II here: «QRL needs to get off the PoW nothing-at-stake weakness & vulnerability. PoS has never had the alleged Noting-at-Stake Vulnerability, it's a PoW PoW was never needed in QRL, and it has only damaged the community PoS would give immediate benefits to ALL participants, and while avoiding There would not be any need to seek investments that spend on mining PoS networks aren't less secure than PoW, and QRL has been distributed Adoption is also happening by including as many as possible in the network PoW inflates costs, attaches unnecessary real-world expenses & dependencies, PoW is what kills QRL. What's better, subsidising a few dozen PoW miners with no commitment QRL doesn't need RandomX nor RandomY mining algorithm switches, Furthermore, PoS has also other advantages in regards to And my last comment on the Quanta emission rate QIP: |
In regard to PoS this talk also some interesting viewpoints https://coinhub.news/cs/article/ethereumfoundation-the-case-for-proof-of-stake-by-emin-gun-sirer-devcon4 |
I prefer RandomX even over long waited POS. As basically mining on the cpu is seems very cool |
RandomX has parameters that can be configured to make it incompatible with Monero.
ProgPoW has much weaker ASIC resistance than RandomX. |
I support this QIP due to the my assumption that most hashrate now is generated through hardware (FPGAs/Asics) for CNv1 that it not publicly accessible. I think POS will not be around for another year at least. and as it has been quoted many times, the wheel doesn't have to be reinvented. QRL could just shadow Monero until POS is properly developed. |
I now vote we fork as soon as is safe to RandomX. |
totally on board with a soon as possible/safe fork to RandomX... we need a safer algo until POS |
\i agree with this pathway. QRL needs to establish a more intimate connection with average miners and GPU users. This will broaden our mining audience, thus QRL public recognition and usability. Network will also be strengthen by this new algo, because if QRL has the ability to change thier algo to stay up to date with techonological advances in crypto mining this is only a plus point for our community and the tech behind it. How can you really think to be "afraid" and against mining algo change if needed (as it is right now) and still pretend to be an avantguarde technology? |
I agree with this QIP. We need to remove all highly specialized hardware from the hashrate and put mining back into the hands of our community and maintain better focus on decentralization. This is the best PoW option available before moving to PoS. |
I agree with this QIP. The fall in node counts to 11 is an all-time low and not indicative of a healthy mining landscape. Pleased to see it has @cyyber's support. |
I do agree that we have to switch ASAP |
I fully support this qip as well. A lot of people have a CPU and by switching to RandomX, anyone that has a CPU can mine QRL which makes the network healthy. |
Guys! Lets discuss, what we can do to roll out RandomX sooner. I can offer 10k quantas as a bounty for either implementation or security check |
@xhipster we have RandomX on devnet already. Public testnet will be rolled out imminently. Team expects a Feb hard fork date. Exchanges need 2-4 weeks to upgrade prior being most of delay now going forward. |
Cool news. The reason I am rising the question is because I can not find new algo in the scope here. Although I can see it in the last update. (strange enough but I am pretty sure I was not able to find this in the first version of update, It was changed?). Amazing that the scope has been updated |
Scope needs a minor amendment to explain the two upcoming forks instead of one. Well spotted we'll get this fixed today. Updated: theQRL/theqrl.org#148 |
I think the status (awaiting hard fork) should be updated.. same with the status of multi-sig :) |
A mining algo change would go a long way towards re-vitalizing the mining community. Many people built rigs or pointed rigs at QRL initially but have been crushed by ASICs / FPGAs and no longer participate.