Pages:
Author

Topic: [ANN] Iridium (IRD) - People are Power - Community build crypto - page 82. (Read 149779 times)

full member
Activity: 406
Merit: 105
Chosŏn Minjujuŭi Inmin Konghwaguk
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.
copper member
Activity: 110
Merit: 1
Is there any exchange available for IDR ?
member
Activity: 361
Merit: 11
Iridium (IRD) dev
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 Smiley
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 ?
member
Activity: 361
Merit: 11
Iridium (IRD) dev
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.
full member
Activity: 196
Merit: 100
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.

newbie
Activity: 103
Merit: 0
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
member
Activity: 74
Merit: 10
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.
sr. member
Activity: 532
Merit: 250
The harder your life is the more meaning it has.
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.
newbie
Activity: 22
Merit: 0
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.
newbie
Activity: 12
Merit: 0
So, what's the purpose of having your token?
member
Activity: 76
Merit: 10
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.
full member
Activity: 196
Merit: 100
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.
newbie
Activity: 22
Merit: 0
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.
newbie
Activity: 58
Merit: 0
Windows Wallet not synchronizing
full member
Activity: 307
Merit: 101
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.



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:


newbie
Activity: 90
Merit: 0
waiting for investing sector, please give a safety site for no tension.
full member
Activity: 307
Merit: 101
sad news .. the dad's fish in the aquarium died. And most likely they will leave the project. Huh
                             IRIDIUM DEV old = IRIDIUM DEV NEW

I have to admit you are even dumber than those recent bots if you believe anyone who fairly launches a coin without premine will then run away with $25 and claim a family member died only to have a cheap excuse.

The fact that you consider this realistic tells me much more about YOUR personality.

newbie
Activity: 33
Merit: 0
sad news .. the dad's fish in the aquarium died. And most likely they will leave the project. Huh
                             IRIDIUM DEV old = IRIDIUM DEV NEW
newbie
Activity: 6
Merit: 0
I read whitepaper and so on but can't understand - what in this project is better that in monero? Is there some new idea in it?
- Low 25,000,000 total coin supply, differentiating from the other CryptoNight coins with over 100 billion coins in total supply.
full member
Activity: 161
Merit: 100
I read whitepaper and so on but can't understand - what in this project is better that in monero? Is there some new idea in it?
Pages:
Jump to: