QIP1: Migration to Cryptonote v8 #2
Conversation
|
I support this request. |
|
We can easily set this decision to the coin holders to vote upon. My coinvote repo can easily track user signed In this way an objective decentralised decision regarding implementing certain specific new features such as cnv8 may be undertaken with true consensus. |
|
This is an important issue. Long term commoditisation of mining hardware, and stability of code is better for security of the network IMO (see Bitcoin). If as indicated QRL development goes for regular hard forks (like monero), and frequent upgrades to the consensus mechanism, i am afraid in the long run it will be "to easy to change" to ever get the trust needed to succeed. So before we change please consider the chosen path carefully. |
|
I support this. |
|
On a personal note, I would agree with forking to cnv8. |
|
In my opinion, we should better spend more time to get PoS as soon as possible, instead of forking for CNv8. Otherwise we will keep forking to make it ASIC resistant. Although there is no solid proof of any ASIC devices exist for CNv7. Moreover, coins like Ethereum not much concerned about ASIC, rather they are focusing more on further development of PoS. Lets say even if we fork for CNv8. What if there will be another ASIC miner for CNv8. We will fork further for CNv9. This adds the overhead in the development and also may effect network stability. We should focus on PoS. |
|
@cyyber implementing CNv2 takes a day or less, its mostly just merging the code from Monero (done by Lethean on short notice and today by Graft). Personally I think ETH will implement it early 2019. |
|
Agreed the overhead is minor @MoneroCrusher, but it isn't the only item potentially planned for the upcoming fork. IMHO we should be forking no more often than twice per year and only when completely necessary as it deprecates old nodes and adds potential risk to the network. @cyyber it is unlikely POS will be ready imminently as this requires further in house research and is a non-trivial undertaking. |
|
@MoneroCrusher Well if we have a concern regarding ASIC, then forking for CNv8 is not a permanent solution. @surg0r Last time Monero had a fork on the month of March or April. And now its again within 6 months. ASIC with time will become more efficient to produce such miners more quickly than before, which may need in future quarterly forks. Moreover, I think if ETH would like to counter ASIC, they will rather go for PoS then keep forking PoW algo. |
|
I don't think swapping consensus algorithms every 6 months is the best use of limited dev time.
There will always be an arms race for efficient hashpower, and various coins swapping PoW algorithms. If anything, using an "xmr-deprecated" cnv7 algorithm might actually cause a more stable hashrate, vs switching consensus algorithms every 6 months to keep up with XMR. I agree that PoS or a PoW/PoS hybrid like Decred and like ETH appears to be leaning towards, is desirable. cheers. |
|
YES to CNv8. Let the ASIC vs GPU fight rage on, as it may, on two fronts: (1) those that call ASIC mining "centralization" and believe that's bad mostly b/c of tech inequities and distaste of arbitrage---there is flat-out better equipment coming out of China but it's secret and that makes us angry; and (2) the camp that believes it makes no difference in security or makes a huge difference or whatever and both have good objective rationale, so it's a tie. Ultimately, I suggest that neither of the above criteria are relevant. Instead, we should ask what kind of a community QRL would like to have as a matter of its governance. The miners constitute the core of the coin's governance. In this, the GPU community is, by far, the group to rally behind, even if the clunky old GPU rigs are less efficient than ASICs. It's the GPU community that's going to feel buy in and (by all measurable statistics: e.g., membership, posting, engagement, voluntary github commits) all are far greater in the GPU community than the ASIC community. Even though QRL may be switching over to PoS at some point, now is not the time to abandon the GPU miners or hope that we'll stick around just because we love the coin. Many of us will stick around, probably many will pledge their allegiance, but as has consistently been the case with these coins that let ASICs go --- you also let the community go. Don't do that. Switch. Quick. Thank you for considering my thoughts. |
Hey sorry to ask a silly question but is there a guide on how to use this? I'd love to cast a vote with my coins, if that's what's being proposed. Thank you. |
|
I think remaining on Cnv7 poses a much greater risk of a 51% attack than moving to Cnv8. https://bitcoinist.com/zencash-target-51-attack-loses-500k-double-spend-transactions/ That spooked one of the big names that had previously recommended the project, that then recommended selling. The price never recovered, and reputation was damaged. The fact there are no exchanges listing mainnet quanta is not an excuse, as we want the network to be safe for when we do have listings. In summary, implementing Cnv8 is a low risk change, and lowers the immediate risk of concentrated attack on the network. I think this should be implemented while the team works on getting the PoS implementation developed and tested. |
|
g0barry I agree with you,
And I'd like to address that in the context of another valid concern, this from jmxdbx above,
I believe that all these things are right: it's a low-risk change, high value in security, but it's also a significant tax on dev time and resources. I believe we need to be pro-active, take a more Monero-like approach. Build an EXPECTATION that we will need to migrate and flip it every six months or so. Plan for it, it won't be a surprise. Releases for software frequently has timeframes when they're presumed to deprecate. If we assume that whatever chain we're mining on today is good for 180 days max, we could invest time in planning for that than lamenting the reality of the landscape and investing overhead in reacting to it (or deciding not to). I think Adam said it best --- you want to apply your waterproofing to the hull before you put the boat in the water. That's the QRL way. Well, the way to do that in mining is to plan for change, and in knowing that change is coming then just plan for it. Maybe we take that vote now rather than just thinking of this as a one-time thing? |
The cost of a 51 attack is relatively trivial with Cnv7 or Cnv8. I don't think switching to Cnv8 would prevent 51% attacks- but I do think the devs should look into remedies that other coins have reportedly taken. One possible approach: https://www.horizen.global/assets/files/A-Penalty-System-for-Delayed-Block-Submission-by-Horizen.pdf |
|
@jmxdbx I also vote for setting a Monero sample and fork every 6 months until QRL implementa PoS. |
|
@MoneroCrusher @papacabeza @jmxdbx And to your point @papacabeza , it would get QRL planning for this ahead of time, so users and pool operators would be preparing for the change when Monero is as well. @jmxdbx All of this is still an improvement on the current PoW implementation, as long as it is understood that the intention is buying time for a PoS implementation. Another improvement that could be added to help mitigate the 51% attack is to implement the update to the Satoshi consensus. https://www.horizen.global/assets/files/A-Penalty-System-for-Delayed-Block-Submission-by-Horizen.pdf |
|
@MoneroCrusher there are no current CNv1 ASICs. CNv2 does decrease the potential performance advantage of ASICs if they were to be built (and decreases the performance advantage of FPGAs), but there's no reason to rush a change like this. |
Yes and in fact, if QRL were to adopt as a governance measure a plan to move with the tide and avoid ASICs, doing that together with Monero is a valiant strategy and if done openly, could benefit both coins. QRL could dedicate dev resources to the fork team to contribute to Monero's work, potentially (or a "fork committee" of coin devs could work on this sort of thing periodically together. The beauty of open source. |
|
As @hotaru2k3 and @cyyber said, there's currently no ASIC for CNV7 and moving from V7 to V8 is not a permanent solution for ASICs. Moreover I think the schedule and resources are kinda tight as there're many things mentioned yet not developed. Thus I don't think V8 is a must. Devs shall focus on developing PoS, Silicon and so on. |
|
Regarding no CNV7 ASICs, check out the video @jackalyst posted in #mining in discord. Also, the high amount of CNV7 hashrate is suspicious, as if they were GPU miners, they could update to v8 and make almost 2x mining Monero currently than mining QRL. |
|
@hotaru2k3 @Wyc0 just compare CNv1 vs. CNv2 hashrate prices on nicehash and it should be clear that the CNv1 hashrate is not comprised of commodity hardware since it would not make any sense to not use it for CNv2. |
|
@g0barry, the video doesn't seem to work, all I'm seeing is a screenshot that doesn't show anything relevant to CNv1. the amount of CNv1+CNv2 hashrate hasn't changed much from what v1 was before Monero forked to v2. a lot of the v1 hashrate now is probably botnets pointed to nicehash. |
|
@hotaru2k3
The video is about 2min, shows a user demonstrating a baikal miner web interface, its pool connection et running cnv7 at approx 12kh. The user even reboots and films it coming back online and starting to hash again. It looks pretty legit. |
|
It doesn't seem like forking would improve security against a 51% attack all that much. According to Crypto51, such an attack with v7 is about $60 per hour using NiceHash (If Jack's video is right, ASICS alone wouldn't be enough unless someone owned over 200 of them). Under v8, where prices are 3x more expensive, that would increase to $200 per hour. That number does not, however, take into account the network hash power that would be lost from the switch (more expensive prices means less people mining with NiceHash), which would bring the price down. If security is a concern, it seems most important that dev time goes to preventing 51% attacks (e.g. POS, Horizen's solution, etc.). The real question behind the proposal then becomes whether or not it is worth the dev time to placate GPU miners. |
|
@IMac318 as said again and again, even by dev himself. This change does not consume significant time. It's actually very insignificant. Basically a copy paste from Monero master (testing excluded, but it's tested for months on Monero, no need to redo that...) |
$200 vs $60/hr is trivial. And if you read the rest of his post, he says:
The price of 51% of the hashpower would not be much different on v7 vs v8 because the hashrate would come back down on v8, and thus it would be less expensive to procure half. And @IMac318 is correct about this:
|
|
nicehashable coins have seen double spend attacks in recent weeks. consider a unique pow. |
|
Ask your self this: Who has the most cpu and gpu power in the world today? cpu power - Big corporations and governments, gpu power- gamers and corporations. Who has the most cryptocurrency asic hardware? cryptocurrency companies and miners. Who do you want to secure your network? |
|
@atoma01 The biggest data centers belong to government contracted institutions, scientific communities & universities, military etc. Those are government sponsored. Most process weather data, crunch molecules and run other scientific models, rendering, communications, IoT etc. They are used and are a critical part of those institutions every day business, corporations have customers to serve and governments have people to serve. All this computation isn't just set up to be doing nothing and waiting for the next 51% attack opportunity. They are highly secured and any misuse of them would result in criminal penalty and likely lost government funds for institutions owning them + big public outrage and scrutiny if misused. By the way, the whole blockchain space already consists of more than 10m RX 570 GPUs (equivalent hashing power). The most powerful institutional GPU farm in Europe consists of 20'000 Nvidia Tesla GPUs (don't know which model exactly, looking for the article). |
Bitmain has about 80% of the market share for SHA-256 ASICs. that's not real competition. for other algorithms, it's even worse.
companies with a long history of attacking the cryptocurrencies they make ASICs for. |
|
Hello @atoma01 , on this point,
You are correct -- on a technical and on an economic front, as to mining equipment, technology, efficiency, and access. However, the much more important point that I think is important and that I believe that @MoneroCrusher is also suggesting is that there is a social and innovation component that must be considered that comes from the miners and their contribution. The hacker-dev-builders in this world are the GPU miners. ASIC communities atrophy. If that's what we want, QRL will still have the best technology, and for people like me, it may not matter because I'm not mining, I feel like I've made my investment. Still, for the longer-term interest of the project, I believe that the hacker/miner/contributor devs should have a piece, and even if it requires crippling the natural Darwinian flow of tech, it makes sense to hamper that just to keep these core group of devs engaged. |
|
@papacabeza @MoneroCrusher Ok, thanks for elucidating your stance on this subject. I now see more clear where you are coming from. However i still think its best to move slow, avoid hard forks if possible, work on POS and research new consensus algos like for example https://docs.maidsafe.net/Whitepapers/pdf/PARSEC.pdf with the aim to give the general users more power over the security of the network. It's still early days, and i think QRL have a few more years to further develop and harden the code base before it's to hard to change direction because of vested interests of the dev/mining community. I dont see any big harm in changing to v8 now when it's still early, but it's the pace of change, precedence set and direction of the project i am worried about. Hence my opposition to this QIP. Hope this clarify my stance on this subject. |
He makes some cogent points.
A unique 'tweaked' non-NH-mineable algo might look attractive, but that is only a temporary solution, because anyone with a decently sized GPU farm (or botnet) could attack even more cheaply than were QRL to use a nicehashable algo, and nobody else would be able to jump in and purchase hashpower to reduce an attackers' portion to under 50%. A QR-resistant chain with a tiny hashrate because it uses its own unique algo could be even less secure. |
This is wrong. A tweak will only prevent nicehash. It won't cause a smaller hashrate (check Stellite). There will always be an equilibrium between GPU mineable cryptonight coins. |
And then an attacker with a sufficient GPU farm or botnet can take 51% of the hashrate, and nobody can stop them, because nobody can purchase hashpower quickly to stop them. Everyone's hands would be tied. Cnv8 would be more secure than a unique non-cloud-mineable algo. Let's call a spade a spade, certain GPU miners want a monopoly on mining profits, even if it makes the chain less secure. Case in point, this thread seems to be dominated by someone who, with all due respect, admits he found about QRL only a few weeks ago. |
|
@jmxdbx IMO nicehash is bad for small coins, just check out like 30 minute ago some guy single handedly bought the entire QRL network on nicehash, he can do whatever he wants. |
Actually, a few people have done just that, keeping that individual address under 50%. PoS or a PoS/PoW or the delayed block could help prevent 51- in addition to hashrate monitoring and increased confirmation times during suspicious activity. A GPU or botnet 51 attack could still occur with cnv8 or some unique algo. Also, being Nicehashable effectively ensures that you will have parties actively monitoring the hashrate 24/7 because they are putting a significant amt of BTC through every day, and will notice and complain if someone is hogging the network at a loss. |
|
@jmxdbx There's also nicehash for CNv8 from GPUs. |
|
Right, and a unique QRL only algo is easier for someone to take over 50%, nobody can arbitrage it so the hashrate will stay artificially low, and nobody can counter an attacker by purchasing additional hashpower. And all mining inflation goes exclusively to people with direct access to cheap electricity. We are just repeating the same points we've already made, this is getting pointless, I respectfully agree to disagree. Good day ;) |
|
Just throwing in my two-cents. I tried using Nicehash a couple of months ago to see whether it would be worth buying a rig. The conclusion I came to was that it may never be profitable to mine QRL. The difficulty level jumps up so fast that it quickly becomes unprofitable. Here is an example: this mining rig costs $3890 on eBay. It has 4 1070Ti cards. Go to whattomine.com and enter 4 1070Ti's and get the hash rate. It's 3 kH/s. Go to any mining pool and get your estimated QRL/day for that hash rate. It's about 3 QRL/day right now. I realize these are all estimates, and yes you would save money building your own rig, but this is not out of the ballpark. 3 QRL/day * 365 = 1095 QRL/year * $0.30 = $328.50. QRL would have to go above $3 to break even at the current hash rate, and that's not counting electricity. My estimate is that difficulty level would rise quickly enough that a rig like the above would never be profitable. So here's my point. Whatever algorithm you choose, examine the economics for the miners/stakers carefully. Yes, I know all coins are down, but Tezos, for example, has a PoS algorithm deployed and it seems to be working well so far. QTUM also has one, although it relies on the Bitcoin UTXO model. If I were a big exchange, I would hesitate to list a coin with the current hash rate that QRL has (~13MH/s at the moment). I think it could be worthwhile examining whether getting to PoS (or some other replacement) is higher priority for the short term. Someone will say this is moot because XMR has 500MH/s and is around $100. True, but it's also traded on many major exchanges. So QRL needs to get over that hump somehow, and it seems to me that the current algorithm and parameters to it may be unintentionally preventing enough of a hashrate increase to get listed. This is all just my two-cents. Take it for what it's worth. :-) Don't count on any labor of love from the miners. Make it worthwhile and they will come. |
|
One last comment to end my thoughts on a positive note, what QRL represents remains almost priceless- ensuring the revolution of decentralized payments and store of value (and more) extends into the post Quantum Computing era. Whatever we can do to leapfrog to the point of more robustness and greater presence in the space, I applaud. Cheers. |
|
@jph108 your post would be an argument against including Nicehash, considering that most of the network hash power is currently coming from there. Without NH, the network rate would be much lower, making it much more profitable for GPU miners. In defense of using an algorithm available on NiceHash: it may actually make the network more secure in the short and long term. Currently, it might be easier to perform a 51% attack with NH, but it would also seem to be much easier to detect such an attack and either warn exchanges or defend against it (by buying chunks of hash power to increase the amount needed for 51%), though not sure if the team is committed to doing the latter. In contrast, if there is a relatively small hash rate from GPU miners only, a botnet could easily come in and 51% attack with little to no possibility of defense. This will become a more realistic possibility as QRL gains attention. In the long run, arbitraging on NiceHash, while hurting GPU profits, could make the network more secure. For example, say QRL hits a major exchange and goes X10. People with no ability to GPU mine would realize NH arbitraging ability and increase the hashrate until the profit margin is slim to none (as is currently happening), which could be 30 MH/s or more. At that point, the hash rate would probably be high enough where a 51% attack through NH would be impossible (or at least not worth it financially). We see this happening currently, where cheap NH prices have boosted the network to 15 MH/s+. Buying that much on NH would actually be very expensive (and become more expensive as others up their order prices to try to get that hash power back). Obviously being on a major exchange would increase GPU miners, but probably not by the same factor, which, again, would leave QRL vulnerable to botnets, who would have even more incentive to attack. And if GPU mining did boost the network by the same factor, then NH would not be a threat for the above reason (or profitable if the rate gets high enough). In regards to long-term security, it's really a win/not-lose scenario to have an algorithm that can be mined on NH. Edit: The above is an expansion of the points from the recent post by @jmxdbx |
|
Instead of following monero with every fork, how about originality of a cryptonight variant for qrl the same way haven and bittube and masari has theirs. Besides moneros v8 fork raised power consumption while decreasing rewards. Also the whole plan of forking every couple of months is ridiculous and makes POW look juvenile. Surely there has to be a better solution |
|
KEEP V7 For a while, pls keep at v7, v8 is bad idea and why always following monero? |
|
I vote keep at V7, v8 is bad idea, why always follow "monero" ? Or you can make cryptonight variant algorithm, better than follow monero |
|
"V8 is bad idea" saying 2 times with an account made on today's date doesn't exactly solidify your "argument". Can you tell us why you think "V8 is bad"? |
|
I joined at 1 February 2018 and he say "New Account" |
|
Was refering to the post basically saying 1:1 the same 2 minutes later obviously written by the same person, that account was registered today. |
|
I don't know who is he. Just ask yourself. |
|
Anyways I agree with you that a custom algo should be used "CNv2-QRL". |
|
No ASIC/FPGA at V1 (v7) custom algorithm, because you make a new algorithm |
|
That's also a possibility. Don't know if the same tweak as above could be applied to CNv1 to make a "CNv1-QRL". |
|
There have been several comments along the lines of: (a) don't fork b/c you always have to keep forking; From my experience in Silicon Valley, all software implementations have a deprecation date. The difference is whether the deprecation is controlled by fate (we stop developing and just let others do it); by force (change in code, license, or compatibility) or by life cycle (it's too old to run). If the PoW algo for QRL is integral to it's operation, it should have a development and deprecation cycle that matches the aggressiveness of the product. In this case, I think Bitcoin can rest. QRL should build a cycle and rest plan into the development program. I just don't see the narrative, essentially, of not forking, which would be something like this: "we're continuing to update our core code and develop new features, but we've made a decision: we're just going to wait-and-see on the PoW algo, we may not do any further development there. We launched CN v7 in June and we're just going to stick with it." I'm not saying change because change is good, but I am saying that there's a lot of weakness in the arguments that we shouldn't change because (a) it's work; (b) it's hard; or (c) let's just not be like Monero. These don't fit with my concept of constant innovation and especially the point where QRL is in the life cycle. |
|
+1 to FORK. We need to. There is no absolute proof that I have seen that the hashrate is being driven by ASICs, but the circumstantial evidence appears to be clear from my perspective. From what I am hearing, the cost of forking is relatively low to the ROI, which would be to almost certainly put the hashrate back into the power of the people, rather than the select few who have access to non-public hardware. After we fork, let's immediately start a longer discussion on what the long term strategy should be. Follow Monero, custom algo, etc... I am not an expert on these topics, but I have followed this project closely for a year now, spoken up a few times on Discord, and my instinct tells me that this is ASIC manipulation, which goes against the spirit of a distributed ledger. |
|
Forking to a unique non-nicehashable algo will do nothing but lower the hashrate. We do not want an artificially low hashrate. We want use, coin price, and hashrate all to increase. As for decentralization- Both ASIC and GPU/CPU mining algorithms can be and are scaled by large mining operations. Consolidation of mining occurs especially in a bear market, with large well-funded operations able to locate where their power and cooling costs are the absolute lowest and survive even when coin prices plummet. Further- there have always been points of centralization in crypto- core devs, large holders and miners, exchanges, etc. At the end of the day, the perfect cannot be the enemy of the good- there is no 'perfect' decentralization, but cryptocurrencies are still comparatively decentralized and still provide vastly more autonomy and personal power to individuals than does the legacy banking system. addendum, NH Cnv7 hashpower for sale has dropped from a high of 100 MH/s in June to 75 MH/s before XMR forked, to currently just 16 MH/s. Clearly their matching engine is dynamically adapting to demand, indicating that the hashrate has not been Cnv7 ASICS. If the 16 MH left is in fact one single proprietary asic farm that for some reason sells its hash on NH, after the Bittrex migration they would clearly just withdraw from NH and mine Quanta direct. We will soon see whether or not that occurs, but it seems implausible that an entity sophisticated enough to manufacture proprietary Cnv7 asics would be selling its hash on Nicehash in the first place. |
|
Test from QRL signer |
No description provided.