[ANN] Iridium (IRD) - People are Power - Community build crypto

[sp_Darkman]

Windows Wallet not synchronizing

[lexphor]

The front-end of the mine77 pool is alive again (was stalled for 24 hours). Payouts have resumed as well. The pool itself was apparently running all the time, as previously suspected. Good thing is that hash power is now shared kind of 50/50 between mine77 and irdpool. I'd happily move some workers to the third pool (ird.uvac) as well once it allows fixed share diffculty setting. The other two pools have this feature, even though it is undocumented on their "getting started" pages.

Allow me to pick your brains a bit.
How exactly so you go about calculating the optimum fixed difficulty for your hash?
Thanks in advance.

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

https://i.imgur.com/VlAItl4.gif

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:

https://i.imgur.com/7djGO6v.gif

Thanks a lot for taking the time to give such a complete and clear explanation.

[Windozxpert]

where is dev?

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?

Some extra node?

The new nodes IP addresses have been uploaded to the github repository, posted on a reply in this forum, posted in the slack channel and listed on the discord. Do some research, join the community. The wallets are syncing. If it's configured correctly, there should be no problems.

[b95123]

The front-end of the mine77 pool is alive again (was stalled for 24 hours). Payouts have resumed as well. The pool itself was apparently running all the time, as previously suspected. Good thing is that hash power is now shared kind of 50/50 between mine77 and irdpool. I'd happily move some workers to the third pool (ird.uvac) as well once it allows fixed share diffculty setting. The other two pools have this feature, even though it is undocumented on their "getting started" pages.

How to set fixed share diff? I use ccminer-x64.

[pulljudge]

So, what's the purpose of having your token?

[papeiru]

The front-end of the mine77 pool is alive again (was stalled for 24 hours). Payouts have resumed as well. The pool itself was apparently running all the time, as previously suspected. Good thing is that hash power is now shared kind of 50/50 between mine77 and irdpool. I'd happily move some workers to the third pool (ird.uvac) as well once it allows fixed share diffculty setting. The other two pools have this feature, even though it is undocumented on their "getting started" pages.

Allow me to pick your brains a bit.
How exactly so you go about calculating the optimum fixed difficulty for your hash?
Thanks in advance.

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

https://i.imgur.com/VlAItl4.gif

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:

https://i.imgur.com/7djGO6v.gif

come on!!!! you rock! I finally understand some shit that never had idea.. thanks monster. regards.

[halker2010]

So, what's the purpose of having your token?

First of all this is a coin not a token and secondly when this hit the exchange miners can profit and others buy and sell and most important reason to get into this coin is a decent roadmap and GPU and CPU friendly algorithm.

[Mr.GottaGo]

So, what's the purpose of having your token?

Think that just from reading the specification of the coin u would get it...
If its a challenge to find them here..
- Specifications -
 - Ticker: IRD
- Low 25,000,000 total coin supply, differentiating from the other CryptoNight coins with over 100 billion coins in total supply.
- Block-by-block difficulty adjustments to ensure transactions are always confirmed within 3 minutes.
 - Difficulty target is exactly 175 seconds.
 - High emission rate, with 18,750,000 coins being rewarded in the first year. This is to encourage mining and coin growth.
 - Bounties will be used to promote decentralized development of the coin.
 - 20 Block Confirmation Maturity
- Community-driven development, many suggestions made by community members will be developed.

[SpecialistMiner]

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

[Windozxpert]

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

The original Dev is not here. He has given control of everything to the community. We currently have about 5 different developers working on IRD. I am still waiting to hear back from an exchange, but many of us don't believe IRD is ready for the exchange yet.

[stevebrush]

People who can use docker containers : here is the automated build for the daemon (node). I will help the network too. The trimmed image based on ubuntu 16.04 takes only 136MB. Running a node at this time need at least 2.2Go free on hard drive to store the blockchain but it will grow. For example, monero blockchain use today 33Go

Iridium node Docker Automated build : https://hub.docker.com/r/steevebrush/iridiumd-container

Please allow 1 or 2 hours for the image to be automatically build. The full description will be automatically filled when build is done

For the records, my pool https://ird.uvac.fr has been ddosed since 6 hours !!! LOL !!! (we lost 2 blocks - Orphaned) but we feel lucky now.

It's ok now.

[stevebrush]

People who can use docker containers : here is the automated build for the daemon (node). I will help the network too. The trimmed image based on ubuntu 16.04 takes only 136MB. Running a node at this time need at least 2.2Go free on hard drive to store the blockchain but it will grow. For example, monero blockchain use today 33Go

Seems i ask this with Windozxpert
Did you have any tutorials for CentOS OS? or this will be same cuz both linux based?
Did you know how many bandwidth used by node ? Should i connect node to other nodes or to "IRD network". How this works ?

docker should be available on centOS (https://docs.docker.com/engine/installation/linux/docker-ce/centos), in that case, just run with your right ports.

Code:

docker run -e "TIMEZONE"="Europe/Paris" -p my_local_p2p_port:12007 --p my_local_rpc_port:13007 -e "P2P_BIND_IP"="1.2.3.4 -e "P2P_BIND_PORT"="my_local_p2p_port" -e "P2P_EXTERNAL_PORT"="12007" -e "RPC_BIND_IP"="5.6.7.8 -e "RPC_BIND_PORT"="my_local_rpc_port" -e "LOG_LEVEL"="4" -e "LOG_FILE"="/data/iridium.log" steevebrush/iridiumd-container

look there, it's written : https://hub.docker.com/r/steevebrush/iridiumd-container

about bandwidth : after the download of the blockchain (2,5Go), bandwidth is very low ! a block is discover every 5 minutes at this time. the node connect automatically to others node. the version compiled is the latest with new seeds.

How this works ? simple : the daemon stock the blockchain, share and confirm (or infirme) the validity of a block.
so more nodes = faster validation and safer transactions.

may be a reward can be imagined for people running nodes, it's a community, so why not asking ?

[KevinMiles]

Is there any exchange available for IDR ?

[garytheasshole]

The front-end of the mine77 pool is alive again (was stalled for 24 hours). Payouts have resumed as well. The pool itself was apparently running all the time, as previously suspected. Good thing is that hash power is now shared kind of 50/50 between mine77 and irdpool. I'd happily move some workers to the third pool (ird.uvac) as well once it allows fixed share diffculty setting. The other two pools have this feature, even though it is undocumented on their "getting started" pages.

How to set fixed share diff? I use ccminer-x64.

I would like to know this too. Anyone?

If pool doesn't support user specified diff or a fixed diff on a given port you're shit out of luck.

[stevebrush]

for those how doesn't know how docker works; it's quiet simple :
first, you have to install docker for your platform, it's available on all platforms (really all platforms) : https://www.docker.com
there is a gui available for Mac and wnidows too : https://kitematic.com but I don't use it.

then, here is the full options commande line. you have to replace the values with yours.

Code:

docker run -it -e "TIMEZONE"="Europe/Paris" -p my_local_p2p_port:12007 --p my_local_rpc_port:13007 -e "P2P_BIND_IP"="1.2.3.4 -e "P2P_BIND_PORT"="my_local_p2p_port" -e "P2P_EXTERNAL_PORT"="12007" -e "RPC_BIND_IP"="5.6.7.8 -e "RPC_BIND_PORT"="my_local_rpc_port" -e "LOG_LEVEL"="4" -e "LOG_FILE"="/data/iridium.log" steevebrush/iridiumd-container

all the variable have default values, so you can omit them but you have to expose the external p2p port (default is 12007) and it you don't want to download the entire blockchain everytime you relaunch you have to "mount" a directory inside the container, this is the -v option at start run. Everything is written here :https://hub.docker.com/r/steevebrush/iridiumd-container

So a basically a quick start with data saved into a directory named ird_data and default outside port 12007 exposed will look like this

Code:

$ mkdir ~/ird_data
$ docker run -it -p 12007:12007 -v ~/ird_data:/data -e "LOG_LEVEL"="4" -e "LOG_FILE"="/data/iridium.log" steevebrush/iridiumd-container

to run as daemon (I named the container, so it's easier to talk to it):

Code:

$ docker run -d -p 12007:12007 -v ~/ird_data:/data -e "LOG_LEVEL"="4" -e "LOG_FILE"="/data/iridium.log" --name iridiumd steevebrush/iridiumd-container
$ docker stop iridiumd # stops the container
$ docker start iridiumd # starts the container
$ docker exec -it iridiumd bash # enter the container with a prompt to inspect it
$ docker rm iridiumd # delete the container (but not the ~/ird_data directory)

[nanona]

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.

[BobTrade]

Is there any exchange available for IDR ?

not yet, it's too early. The project started on september, we need a solid base.

[Acime]

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.

I think you should go to Discord (https://discord.gg/6y2p6Qj) and talk to devs directly.

[Windozxpert]

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.

This is a very valid and important point. It has been happening with all CPU friendly coins, botnets like nicehash screwing up the diff. I don't believe the original dev cared enough to actually consider this, but we do! We will get on this upgrade immediately and begin the transformations. It may not be done quickly, but we will get it done. Thank you for pointing this out.

[nanona]

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 network difficulty has slowly ramped up to 20M now, despite the attack being over since more than 8 hours and the global hashrate back down to 50kH/s ever since. This is two times the 10M it had when the attack started. Blocks come in very slow therefore. The last 20 blocks took over 3 hours to mine (almost 3.5 hours), which means the miners are now earning less than one third of the coins they should earn for a couple of days to come until the difficulty will be back down to 10M. They are paying for the nicehash freeloader. If they are unlucky the freeloader will return just when the difficulty is again back to nominal. Rinse repeat.

The pools are certainly not earning more fees due to such incidents. Because the long period of slow blocks and less fees (per hour) now will make up for the short period of more fees (per hour) during the attack. I am therefore puzzled why they would actively invite nicehash attacks by providing a dedicated port just for this centralized service.