Here we go !
(private joke) 
Topic: [ANN] Iridium (IRD) - People are Power - Community build crypto - page 40. (Read 149821 times)
January 27, 2018, 06:43:28 PM
January 27, 2018, 05:35:27 PM
Exchange??? Come on guys... 
Cryptopia? Yobit? HitBTC?
Come on it's Saturday, can't we just appreciate the calm after this hard fork and savoure champagne and caviar ? Next week is a new week Cryptopia? Yobit? HitBTC? 
January 27, 2018, 05:30:40 PM
Exchange??? Come on guys... Cryptopia? Yobit? HitBTC?
Cryptopia? Yobit? HitBTC? January 27, 2018, 05:22:06 PM
Thanks for letting me know you implemented the LWHM difficulty algorithm. I developed it in November based on Tom Harding's wt-144 to try to provide the most protection to small coins by trying to discourage big miners from coming in and getting blocks, then leaving your dedicated miners stuck with a high difficulty. Masari is the only other coin using it. They've done a pull request on Monero (or Cryptonote?) to let others know about it. But I think your code is more correct. I designed and tested about 15 different algorithms in the past 18 months before settling on this one. It's better than any other algorithm I know of.
Since you began it yesterday, your delays and hash attacks have less than all but 7% of the previous days, and most of those "good days" were the result of issuing blocks a little too quickly (none of the solvetimes were this accurate).
In running the simulations again, I can see the adjustment factor I gave you is a little bit too high, which is why your average solvetime the past 24 hours was 176 seconds instead of 175 seconds, so I've adjusted the algorithm to be a little more precise for future coins. Your long-term average will be 175.5 seconds.
Thank you Zawy and one more time many thanks for this fantastic algorithm.Since you began it yesterday, your delays and hash attacks have less than all but 7% of the previous days, and most of those "good days" were the result of issuing blocks a little too quickly (none of the solvetimes were this accurate).
In running the simulations again, I can see the adjustment factor I gave you is a little bit too high, which is why your average solvetime the past 24 hours was 176 seconds instead of 175 seconds, so I've adjusted the algorithm to be a little more precise for future coins. Your long-term average will be 175.5 seconds.
I think community can live with a 175.5 long-term average, this is only 1,4065934066 block per day which means less than 25h per year
and this is much more accurate than the older algo...
If someone in the community does not agree, I can of course schedule a new hard fork
January 27, 2018, 05:04:23 PM
When will it be a change? It's always a joke ..
When we will be ready... oh! now we are ! January 27, 2018, 01:15:42 PM
When will it be a change? It's always a joke ..
January 27, 2018, 12:32:08 PM
Thanks for letting me know you implemented the LWHM difficulty algorithm. I developed it in November based on Tom Harding's wt-144 to try to provide the most protection to small coins by trying to discourage big miners from coming in and getting blocks, then leaving your dedicated miners stuck with a high difficulty. Masari is the only other coin using it. They've done a pull request on Monero (or Cryptonote?) to let others know about it. But I think your code is more correct. I designed and tested about 15 different algorithms in the past 18 months before settling on this one. It's better than any other algorithm I know of.
Since you began it yesterday, your delays and hash attacks have less than all but 7% of the previous days, and most of those "good days" were the result of issuing blocks a little too quickly (none of the solvetimes were this accurate).
In running the simulations again, I can see the adjustment factor I gave you is a little bit too high, which is why your average solvetime the past 24 hours was 176 seconds instead of 175 seconds, so I've adjusted the algorithm to be a little more precise for future coins. Your long-term average will be 175.5 seconds.
Since you began it yesterday, your delays and hash attacks have less than all but 7% of the previous days, and most of those "good days" were the result of issuing blocks a little too quickly (none of the solvetimes were this accurate).
In running the simulations again, I can see the adjustment factor I gave you is a little bit too high, which is why your average solvetime the past 24 hours was 176 seconds instead of 175 seconds, so I've adjusted the algorithm to be a little more precise for future coins. Your long-term average will be 175.5 seconds.
January 27, 2018, 11:50:59 AM
Just started a new Iridium pool: https://irdpool.eu
Join us and help us find those Iridium blocks! 0% fee till the end of next week.
just now i shifted my hashpower to your pool.Join us and help us find those Iridium blocks! 0% fee till the end of next week.
I want you to donate 1% from your pool to the Dev team of IRD.
You can add your commission later in some weeks
January 27, 2018, 11:15:36 AM
what do you think will be the price of Iridium?
January 27, 2018, 07:15:13 AM
Yes, this is the next step !
I just made the average mean time for finding a block for almost 24h and this is a huge success :
176s for a target of 175s. Just after the HF where hashrate has moved a lot : it's very nice.
this algorithm rocks ! Thanks to Zawy for his research.
summary is here : http://ird.cash/hard-fork-success
January 27, 2018, 06:52:07 AM
yes please, i'm mining this since september!
January 27, 2018, 05:01:55 AM
January 27, 2018, 04:55:40 AM
There is the last step!
January 27, 2018, 03:48:30 AM
Wow! Net hashrate is more than 400 
January 27, 2018, 02:11:15 AM
Thank you for your careful attention.
Iridium wishes you a big hit.
Hello parkysik, I did a search directly in the core : Iridium wishes you a big hit.
Code:
print_tx 97569b72298123b1c59fd0d26e59f6cfc1ffccae92ab17f499eea16358870679
transaction wasn't found: <97569b72298123b1c59fd0d26e59f6cfc1ffccae92ab17f499eea16358870679>
print_tx 45473dfc1cf99a7beadcc468f27f729dee6dbe79f80effca47cc21865f9c38b6
transaction wasn't found: <45473dfc1cf99a7beadcc468f27f729dee6dbe79f80effca47cc21865f9c38b6>
print_tx 47268ec3a7e546c2cb15cbffe630af4175881ffd83c866c39e3774976f6c2cc5
transaction wasn't found: <47268ec3a7e546c2cb15cbffe630af4175881ffd83c866c39e3774976f6c2cc5>
print_tx e862c1efdcdc488822b189f49a47f9ce29dbf601d1d3168a333fbd54a2022b77
transaction wasn't found:
print_tx 436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc
transaction wasn't found: <436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc>
and nothing found.transaction wasn't found: <97569b72298123b1c59fd0d26e59f6cfc1ffccae92ab17f499eea16358870679>
print_tx 45473dfc1cf99a7beadcc468f27f729dee6dbe79f80effca47cc21865f9c38b6
transaction wasn't found: <45473dfc1cf99a7beadcc468f27f729dee6dbe79f80effca47cc21865f9c38b6>
print_tx 47268ec3a7e546c2cb15cbffe630af4175881ffd83c866c39e3774976f6c2cc5
transaction wasn't found: <47268ec3a7e546c2cb15cbffe630af4175881ffd83c866c39e3774976f6c2cc5>
print_tx e862c1efdcdc488822b189f49a47f9ce29dbf601d1d3168a333fbd54a2022b77
transaction wasn't found:
print_tx 436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc
transaction wasn't found: <436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc>
When (or since when) did you see this?
did you reset the wallet ?
are you expected those transactions ?
Thank you for caring me.
I do not remember exactly.
I am okay.
With your kindness, my hash has returned 100 times.
Once again, I wish the iridium to be a big hit.
January 26, 2018, 07:09:35 PM
@IRD-PoolOperator: Your pool still shows the wrong global hashrate (calculated from the correct difficulty) because you have a wrong block time (240s) specified (or just forgot to change a default value). Should be 175s.
Mentioned two months ago: https://bitcointalksearch.org/topic/m.25586036
Reading that I see that your pool used 120s back then. Now 240s. So I guess you simply kept the default from github both times.
I see other pools too have the global hashrate in error, but only slightly. It seems they use 180s instead of the correct 175s for the estimate.
To all pool operators: Use 175s as block time to get correct global hashrate estimates.
It's fixed now, that change didn't make it over when I was vimdiffing the configs during testing.Mentioned two months ago: https://bitcointalksearch.org/topic/m.25586036
Reading that I see that your pool used 120s back then. Now 240s. So I guess you simply kept the default from github both times.
I see other pools too have the global hashrate in error, but only slightly. It seems they use 180s instead of the correct 175s for the estimate.
To all pool operators: Use 175s as block time to get correct global hashrate estimates.
@IRD-PoolOperator: Your pool still shows the wrong global hashrate (calculated from the correct difficulty) because you have a wrong block time (240s) specified (or just forgot to change a default value). Should be 175s.
Mentioned two months ago: https://bitcointalksearch.org/topic/m.25586036
Reading that I see that your pool used 120s back then. Now 240s. So I guess you simply kept the default from github both times.
I see other pools too have the global hashrate in error, but only slightly. It seems they use 180s instead of the correct 175s for the estimate.
To all pool operators: Use 175s as block time to get correct global hashrate estimates.
Yes! Already did it since weeks. For quick copy/pasters (no offense, no conspiracy) search for 175 in the source of the main page of my pool.Mentioned two months ago: https://bitcointalksearch.org/topic/m.25586036
Reading that I see that your pool used 120s back then. Now 240s. So I guess you simply kept the default from github both times.
I see other pools too have the global hashrate in error, but only slightly. It seems they use 180s instead of the correct 175s for the estimate.
To all pool operators: Use 175s as block time to get correct global hashrate estimates.
https://cdn.discordapp.com/attachments/369381308583116800/406566963037339648/Sans_titre.jpeg
And global hashrate is in the top of the wallet too.
January 26, 2018, 06:45:25 PM
#######################################################################
Hard fork summary
Now, we are at block 69743, and it's 12 hours after the hard fork,
every pools are running fine and networks is smooth.
The blocked transactions in mempool for month are now released except a big one.
Average time to discover a block during this 12 last hour :
69743 - 69500 = 243 blocks were mined.
Average block discover time is : 12 hours * 3600 secondes / 243 blocks
The result is an average of 178 secondes per block during this period
Iridium target is set at 175 secondes.
So we can now say the hard fork is a big success !!!
http://www.ird.cash/hard-fork-success/
Thank you very much !
#######################################################################
Hard fork summary
Now, we are at block 69743, and it's 12 hours after the hard fork,
every pools are running fine and networks is smooth.
The blocked transactions in mempool for month are now released except a big one.
Average time to discover a block during this 12 last hour :
69743 - 69500 = 243 blocks were mined.
Average block discover time is : 12 hours * 3600 secondes / 243 blocks
The result is an average of 178 secondes per block during this period
Iridium target is set at 175 secondes.
So we can now say the hard fork is a big success !!!
http://www.ird.cash/hard-fork-success/
Thank you very much !
#######################################################################
January 26, 2018, 05:12:05 PM
Thank you for your careful attention.
Iridium wishes you a big hit.
Hello parkysik, I did a search directly in the core : Iridium wishes you a big hit.
Code:
print_tx 97569b72298123b1c59fd0d26e59f6cfc1ffccae92ab17f499eea16358870679
transaction wasn't found: <97569b72298123b1c59fd0d26e59f6cfc1ffccae92ab17f499eea16358870679>
print_tx 45473dfc1cf99a7beadcc468f27f729dee6dbe79f80effca47cc21865f9c38b6
transaction wasn't found: <45473dfc1cf99a7beadcc468f27f729dee6dbe79f80effca47cc21865f9c38b6>
print_tx 47268ec3a7e546c2cb15cbffe630af4175881ffd83c866c39e3774976f6c2cc5
transaction wasn't found: <47268ec3a7e546c2cb15cbffe630af4175881ffd83c866c39e3774976f6c2cc5>
print_tx e862c1efdcdc488822b189f49a47f9ce29dbf601d1d3168a333fbd54a2022b77
transaction wasn't found:
print_tx 436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc
transaction wasn't found: <436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc>
and nothing found.transaction wasn't found: <97569b72298123b1c59fd0d26e59f6cfc1ffccae92ab17f499eea16358870679>
print_tx 45473dfc1cf99a7beadcc468f27f729dee6dbe79f80effca47cc21865f9c38b6
transaction wasn't found: <45473dfc1cf99a7beadcc468f27f729dee6dbe79f80effca47cc21865f9c38b6>
print_tx 47268ec3a7e546c2cb15cbffe630af4175881ffd83c866c39e3774976f6c2cc5
transaction wasn't found: <47268ec3a7e546c2cb15cbffe630af4175881ffd83c866c39e3774976f6c2cc5>
print_tx e862c1efdcdc488822b189f49a47f9ce29dbf601d1d3168a333fbd54a2022b77
transaction wasn't found:
print_tx 436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc
transaction wasn't found: <436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc>
When (or since when) did you see this?
did you reset the wallet ?
are you expected those transactions ?
January 26, 2018, 04:53:31 PM
@IRD-PoolOperator: Your pool still shows the wrong global hashrate (calculated from the correct difficulty) because you have a wrong block time (240s) specified (or just forgot to change a default value). Should be 175s.
Mentioned two months ago: https://bitcointalksearch.org/topic/m.25586036
Reading that I see that your pool used 120s back then. Now 240s. So I guess you simply kept the default from github both times.
I see other pools too have the global hashrate in error, but only slightly. It seems they use 180s instead of the correct 175s for the estimate.
To all pool operators: Use 175s as block time to get correct global hashrate estimates.
Yes! Already did it since weeks. For quick copy/pasters (no offense, no conspiracy) search for 175 in the source of the main page of my pool.Mentioned two months ago: https://bitcointalksearch.org/topic/m.25586036
Reading that I see that your pool used 120s back then. Now 240s. So I guess you simply kept the default from github both times.
I see other pools too have the global hashrate in error, but only slightly. It seems they use 180s instead of the correct 175s for the estimate.
To all pool operators: Use 175s as block time to get correct global hashrate estimates.
And global hashrate is in the top of the wallet too.
January 26, 2018, 02:52:40 PM
@IRD-PoolOperator: Your pool still shows the wrong global hashrate (calculated from the correct difficulty) because you have a wrong block time (240s) specified (or just forgot to change a default value). Should be 175s.
Mentioned two months ago: https://bitcointalksearch.org/topic/m.25586036
Reading that I see that your pool used 120s back then. Now 240s. So I guess you simply kept the default from github both times.
I see other pools too have the global hashrate in error, but only slightly. It seems they use 180s instead of the correct 175s for the estimate.
To all pool operators: Use 175s as block time to get correct global hashrate estimates.
Mentioned two months ago: https://bitcointalksearch.org/topic/m.25586036
Reading that I see that your pool used 120s back then. Now 240s. So I guess you simply kept the default from github both times.
I see other pools too have the global hashrate in error, but only slightly. It seems they use 180s instead of the correct 175s for the estimate.
To all pool operators: Use 175s as block time to get correct global hashrate estimates.
Jump to: