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

[nanona]

I found the secret patch, and to quote the developer of the pool you feature in your signature: https://github.com/zone117x/node-cryptonote-pool/issues/14

That's a discussion from 2014 and stevebrush isn't even involved there. So again, how did he "withhold the secret fix" when it is something that is out in the wild since years and not even related to him?!

It looks like you used a different fork of the pool software than anyone else did and therefore you ran into problems others didn't run into.

I used your pool in the past probably more than anyone else did and I did recommend it many times. But with all this noise and ad hominem now I am sure I won't use it ever again (assuming you will eventually find a few minutes to fix your problem instead of posting anti-dev diatribes).

[1715513670]

1715513670

[nanona]

oxлaдитe тpaxaньe, yглeплacтик

i translate for you from russian:

"chill out, dudes"

Damn, I thought it means: "My mama says it's just a phase when I fill my days with mayonez". Anyway, I think we have a "western spy" here.   

[IRD-PoolOperator]

I found the secret patch, and to quote the developer of the pool you feature in your signature: https://github.com/zone117x/node-cryptonote-pool/issues/14

That's a discussion from 2014 and stevebrush isn't even involved there. So again, how did he "withhold the secret fix" when it is something that is out in the wild since years and not even related to him?!

It looks like you used a different fork of the pool software than anyone else did and therefore you ran into problems others didn't run into.

I used your pool in the past probably more than anyone else did and I did recommend it many times. But with all this noise and ad hominem now I am sure I won't use it ever again (assuming you will eventually find a few minutes to fix your problem instead of posting anti-dev diatribes).

I did use the exact pool software as used by others, it does not work. Not on any of the available branches either. I have no reason to believe stevebrush was not aware of these pool breaking changes, as per the previous issue, which he explicitly quoted the fix to me after I already fixed it.

I apologize for being aggressive, waking up at 3am to find a broken pool is not fun. Knowing that it could have been avoided with a basic level of communication, but didn't happen, as per stevebrush's PMs, because I don't donate.

[stevebrush]

"western spy" lol.
so now : a little rest with my children (is it really rest ?) and let's see how this algo react in a real world

[nanona]

I did use the exact pool software as used by others, it does not work. Not on any of the available branches either. I have no reason to believe stevebrush was not aware of these pool breaking changes, as per the previous issue, which he explicitly quoted the fix to me after I already fixed it.

You very likely did not use the "exact" same "pool software". The reason I used your pool and recommended it was because your pool allowed a fixed share diff setting, while others didn't have that feature.
When I investigated this something like four months ago I noticed that you ran a different fork of the pool software than all others, which was obvious already by the different source reference and versioning in the footer of your pool page.

I don't know how many forks of that "cryptonote-universal-pool" exist but there must be quite a few and very likely you ran a different one than the other pools. Which as I mentioned previously wasn't a bad thing at all.

[IRD-PoolOperator]

I did use the exact pool software as used by others, it does not work. Not on any of the available branches either. I have no reason to believe stevebrush was not aware of these pool breaking changes, as per the previous issue, which he explicitly quoted the fix to me after I already fixed it.

You very likely did not use the "exact" same "pool software". The reason I used your pool and recommended it was because your pool allowed a fixed diff share setting, while others didn't have that feature.
When I investigated this something like four months ago I noticed that you ran a different fork of the pool software than all others, which was obvious already by the different source reference and versioning in the footer of your pool page.

I don't know how many forks of that "cryptonote-universal-pool" exist but there must be quite a few and very likely you ran a different one than the other pools. Which as I mentioned previously wasn't a bad thing at all.

To make it clear exactly what I did, here are the following versions I tried.
clintar/cryptonote-xmr-pool
clintar/cryptonote-universal-pool
zone117x/node-cryptonote-pool <--used by others, broken by default
fancoder/cryptonote-universal-pool <--works

in combination with the following node-cryptonote-util
clintar/node-cryptonote-util
clintar/node-cryptonote-util#Nan-2.0
clintar/node-cryptonote-util#xdn-Nan-2.0
clintar/node-cryptonote-util#xmr-Nan-2.0
zone117x/node-cryptonote-util
Snipa22/node-cryptonote-util <--used by others, broken by default
fancoder/node-cryptonote-util <--works

I have dug into the fork history of all of this during my troubleshooting, read every issue involving messages, modified and recompiled node-cryptonote-util. Out of all available combinations and options, only one thing worked and that was fancoder's fork. It's working now and I'm not going to dig any deeper.

In my mind there may be one last difference. I compile my node, and last night there was a new commit, during my troubleshooting I did recompile the node. The possibility exists that the binary released days ago was compiled from code that was not available on the git at time of release. I don't believe this is the case, though.

[parkysik]

transaction :  97569b72298123b1c59fd0d26e59f6cfc1ffccae92ab17f499eea16358870679 : 25.6 Iridium
transaction :  45473dfc1cf99a7beadcc468f27f729dee6dbe79f80effca47cc21865f9c38b6 : 27.41 Iridium
transaction :  47268ec3a7e546c2cb15cbffe630af4175881ffd83c866c39e3774976f6c2cc5 : 11.73 Iridium
transaction :  e862c1efdcdc488822b189f49a47f9ce29dbf601d1d3168a333fbd54a2022b77 : 20.76 Iridium
transaction :  436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc : 16.73 Iridium

https://imgur.com/a/9Jbnv


Why can not I confirm?

[stevebrush]

transaction :  97569b72298123b1c59fd0d26e59f6cfc1ffccae92ab17f499eea16358870679 : 25.6 Iridium
transaction :  45473dfc1cf99a7beadcc468f27f729dee6dbe79f80effca47cc21865f9c38b6 : 27.41 Iridium
transaction :  47268ec3a7e546c2cb15cbffe630af4175881ffd83c866c39e3774976f6c2cc5 : 11.73 Iridium
transaction :  e862c1efdcdc488822b189f49a47f9ce29dbf601d1d3168a333fbd54a2022b77 : 20.76 Iridium
transaction :  436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc : 16.73 Iridium
Why can not I confirm?

Hello ! welcome ! What is exactly you problem, we can maybe find a solution or at least try...
Transactions validations are not up to you to be confirmed but take 20 blocks.

[parkysik]

transaction :  97569b72298123b1c59fd0d26e59f6cfc1ffccae92ab17f499eea16358870679 : 25.6 Iridium
transaction :  45473dfc1cf99a7beadcc468f27f729dee6dbe79f80effca47cc21865f9c38b6 : 27.41 Iridium
transaction :  47268ec3a7e546c2cb15cbffe630af4175881ffd83c866c39e3774976f6c2cc5 : 11.73 Iridium
transaction :  e862c1efdcdc488822b189f49a47f9ce29dbf601d1d3168a333fbd54a2022b77 : 20.76 Iridium
transaction :  436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc : 16.73 Iridium

https://imgur.com/a/9Jbnv

Why can not I confirm?

Hello ! welcome ! What is exactly you problem, we can maybe find a solution or at least try...
Transactions validations are not up to you to be confirmed but take 20 blocks.

This transaction has not been confirmed for several months.

[stevebrush]

This transaction has not been confirmed for several months.

Thoses transactions are not in mempool : the only one stucked since a while is the big one, all other have been released and the too first are the current waiting.


where did you see them ?

[parkysik]

This transaction has not been confirmed for several months.

Thoses transactions are not in mempool : the only one stucked since a while is the big one, all other have been released and the too first are the current waiting.


where did you see them ?

It is in the transaction menu of my wallet.

[stevebrush]

It is in the transaction menu of my wallet.

Reset you wallet,
those transactions doesn't exist or are already in a block, unfortunately, actual online block explorer is broken and the wallet doesn't allow a tx search. I will search for them.

[parkysik]

It is in the transaction menu of my wallet.

Reset you wallet,
those transactions doesn't exist or are already in a block, unfortunately, actual online block explorer is broken and the wallet doesn't allow a tx search. I will search for them.

Thank you for your careful attention.
Iridium wishes you a big hit.

[iridiumking]

It is in the transaction menu of my wallet.

Reset you wallet,
those transactions doesn't exist or are already in a block, unfortunately, actual online block explorer is broken and the wallet doesn't allow a tx search. I will search for them.

Block explorer will be online tonight and pushed to GitHub.

[nanona]

@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://bitcointalk.org/index.php?topic=2150442.msg25586036#msg25586036

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.

[stevebrush]

@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://bitcointalk.org/index.php?topic=2150442.msg25586036#msg25586036
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.


And global hashrate is in the top of the wallet too.

[stevebrush]

Thank you for your careful attention.
Iridium wishes you a big hit.

Hello parkysik, I did a search directly in the core  :

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: <e862c1efdcdc488822b189f49a47f9ce29dbf601d1d3168a333fbd54a2022b77>
print_tx 436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc
transaction wasn't found: <436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc>

and nothing found.
When (or since when) did you see this?
did you reset the wallet ?
are you expected those transactions ?

[stevebrush]

#######################################################################

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 !

#######################################################################

[IRD-PoolOperator]

@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://bitcointalk.org/index.php?topic=2150442.msg25586036#msg25586036

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.

@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://bitcointalk.org/index.php?topic=2150442.msg25586036#msg25586036
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.
https://cdn.discordapp.com/attachments/369381308583116800/406566963037339648/Sans_titre.jpeg

And global hashrate is in the top of the wallet too.

Modifying the website would have done nothing, this is a pool configuration issue.

[parkysik]

Thank you for your careful attention.
Iridium wishes you a big hit.

Hello parkysik, I did a search directly in the core  :

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: <e862c1efdcdc488822b189f49a47f9ce29dbf601d1d3168a333fbd54a2022b77>
print_tx 436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc
transaction wasn't found: <436008b7e95f547280e2f2905e9047578608a71d9c831be97eb56b061c106bcc>

and nothing found.
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.