System specs:
6x EVGA 1080ti SC Black
2x 1000w EVGA G3
ASUS z270-P
4GB RAM
G440
SSD-120GB

Power is free (don't mind running them pretty good)
Mining ZCASH using DSTM miner

1. I am trying to find the optimal OC settings for these cards, while stable. I've heard to try and OC each card individually. How can I do this in afterburner and save the profile, so that on a reboot all of the cards use those individual settings? It seems like in afterburner, when you individually OC the cards, the profile does not save for all cards, only one.

2. Does anyone have any OC settings for these cards so I can baseline off of?

3. The 3 GPUS at the end of my rig are a lot hotter than the others. (these cards just spit the hot exhaust above and get sucked into the ones after it) What is the best way to Exhaust some heat away? Put a fan above the rig and exhaust the hot air upwards? Or blow cool air towards the front of the rig(the front of the cards).

Thanks!!

Hardcoded seed nodes is ok, no masternodes to the people, it is not fair. Wr just need a diff. adjustment corrrectly with by ZEW algo

thanks.

so you mean, pools should close nicehash port until the problem is solved?

The network suffered an instamining attack for the past two hours (10:50-12:40 GMT) done over the mine77 pool. I think I saw something like 350kH/s at work. 50kH/s of which are the genuine permanent miners in that pool, so the attacker used appr. 300kH/s. During these hours we saw blocks 30208 to 30406 which was 198 blocks in 110min or 1.8 blocks/min or an average block time of 33 seconds. The normal rate would have been 36 blocks during that time, therefore 162 blocks (nearly 14,000 IRD) were mined in excess due to the not fast enough difficulty re-target on this blockchain.

I suggest the dev team starts to implement a more up to date diffculty re-target function. In the past Sumokoin (SUMO) and Masari (MSR) suffered the same fate of getting raped by nicehash idiots, i.e. centralized hashrate for hire. Masari then adopted the retargeting from SUMO which stopped these attacks. I consider these attacks equivalent to someone going into a restaurant, eating and then running away while telling the waitress that the invoice will be paid by the next customer.

This is exactly what will happen now since the difficulty is slowly (and delayed) adjusting upwards long after the attack has stopped, which means the genuine 24/7 miners which actually secure the network will mine against a high difficulty (which comes too late), will waste lots of electricity and get very few blocks, i.e. coins. They basically subsidize the coins stolen by the nicehash idiot. Yes, I consider it theft because the nicehash attacker is not willing to mine at the difficulty his hashrate generates. That's why he ran away after a short time and doesn't mine 24/7, knowing exactly that the invoice (difficulty) is presented only after the fact and he can leave it to the other miners.

The difficulty re-target will always be a trailing indicator because it works based on the block times found previously. But it must be such that it can react very quickly on such hashrate attacks and drive difficulty up immediately when the blocks start flying. Once it stops, it must equally quickly adjust difficulty down of course. Other coins have solved this very well and this coin should upgrade as well on a coming HF. After all the block time is the heartbeat of the network and it must be predictable and constant. It is additionally controlling the issuance of the coins (inflation) and this must be fully under control and resilient to such nicehash attacks. Hence why I always recommend that pools do not accept nicehash workers. Nicehash is the exact opposite of a decentralized ledger and currency mined by decentralized miners. It's a centralized service which should be blocked wherever possible.

HI
I have two questions.
Is the IridumDev back here after he told that his father died and then he disappear? If not who is the dev now?
When IRD hit an exchange? Someone interested to buy IRD? I have some for sale, PM offer

Dev i am sure will come soon don't forget just started the weekend , many people are with family! I got a problem to synchronize my wallet where could i get some extra node please?

If you are using Claymore, this is what you want to see.



You want that your worker submits shares every few seconds. This is only possible if the pool allocates you a proper share difficulty.

Many pools which use auto-diff do not. They give you some ridiculous diff of say 100k, which means your worker will often not find and submit a single share before the round is over, which means you get ZERO rewards for that round.

A worker consisting of a single CPU and a worker consisting of 6 GPUs obviously need highly different diffs. When a pools is using a constant diff on a certain port, that diff fits basically nobody. It will be too high for the single CPU worker and much too low for the multiple GPU rig. Which means the single CPU worker will just heat the room by not finding a single share before a round is over, while the multiple GPU worker will bombard the pool server with shares multiple times every second putting an unnecessary load on the server.

This is why pools are using auto-diff. They have different start diffs on certain ports but then each new round after you connect they adjust the diff. What many of them however don't do, is to adjust it properly. They just increase it until max diff is reached, rendering the connected workers very inefficient with much too high diff.

Therefore a pools needs the option that a user can set a diff of his choice which works best for his rigs. Simply to overcome the badly implemented auto-diff.

Let's assume your worker has a total hashrate of 1000H/s. Try to set a diff of 3000 and see how frequently shares are found and submitted (the green lines saying "share found, share accepted"). If it is every few seconds, that's fine. If it takes longer, set a lower diff. If it is too frequent, set a higher diff. Once you have figured it out, use that diff forever for that particular algo.

However for coins where the block time is much shorter, say 15s, you want to have shares found and submitted much more frequently than 2-3s. Otherwise you will miss out all short rounds.

About the above screenshot: Claymore shows those yellow status lines with the temperatures every 30s. As you can see the diff I have configured is such that shares are found every 2-3s. Works fine for me. If you use a too high diff (manually set too high or the pool setting it for you) you will also notice that the hashrate shown in the pool is much lower than your actual hashrate (no, this isn't because Claymore is mining covertly with your rigs and such nonsense!). That's because your worker will produce many stale shares when the round is already over and he is still chewing on the old outdated work, wasting electricity for nothing. Therefore the right diff setting is essential for efficient mining.

EDIT: Here is what you don't want to see:

in miami

gonna get listed on  exchange soon wallet code will get update and bounties are gonna get started I really dont see how this project is dead ? 

hey is there anyone? Is the project alive?

We can add some fee to the Dev group from the pools for example or from block reward. And get a new dev maybe for a part time job to fix the bugs. Pay him with IRD.
Then we can start from any exchange.

Not yet we have people working on that issue.

I have updated the config file on github to include the new nodes we have running. I have not yet compiled it, so if anyone could compile it for Windows and the other OS, please do and post a link. We are also looking at the Tx issues. We believe the original code didn't provide a high enough Tx fee for them to complete.

 


people..
if we are already deceived that we are digging this coin, take care if you donate. I think the purpose of this coin is solely a donation.
                                                                                   
                                                                                 old dev = new dev