Topic: [ANN] ZERO - COMMUNITY TAKEOVER - page 32. (Read 68205 times)
Now the transactions end in an instant?!
I apologize to the miner in my pool, but I was mining a few hours before and there were more shares for me, but the next block starts from 0 both.
Is this a staking coin?
even i couldn't find your facebook page link. i am still interested of looking forward to your project for more development. goodluck dev/team, nice project, goodluck.
I apologize to the miner in my pool, but I was mining a few hours before and there were more shares for me, but the next block starts from 0 both.
Great project!
Optiminer is horrible right now, crashes every few minutes even without OC...
I was a miner at suprnova then I mined for 24h at forgetop because people here said it pay more but after 24h i had about 40% less.. now switched back to suprnova and after about 12h I already have about the same amount i was mining in 24 on forgetop..
Yep, same here. I was getting half on forgetop what I am making now on suprnova. I don't know if there is some setting problem on forgetop or they intentionally steal our coins.they probably do steal coins, I started noticing funny stuff with pools already
some want 500 coins before they pay out others dont pay out...
whats the best miner to use to mine for this coin?
If there are problems with the pool let me know, for me it is not important which pool you use, you have to find the best for you and together we should contribute to the growth of zero.
if you want to try: https://mining.prophetalgorithms.com
I was a miner at suprnova then I mined for 24h at forgetop because people here said it pay more but after 24h i had about 40% less.. now switched back to suprnova and after about 12h I already have about the same amount i was mining in 24 on forgetop..
Yep, same here. I was getting half on forgetop what I am making now on suprnova. I don't know if there is some setting problem on forgetop or they intentionally steal our coins.
hi i want set zerocoin worker diff in suprnova pool
but its dont change
can you help to how set higher diff for mining this coin?!
thanks
but its dont change
can you help to how set higher diff for mining this coin?!
thanks
Quote
Here is an example from log files
We thought a block was found but it was rejected by the daemon, share data: {"job":"d3a2","ip":"::ffff:x.x.x.x","port":2053,"worker":"t1xxxxxxxxxeL","height":236147,"difficulty":0.2,"shareDiff":"4596.03419805","blockDiff":1351.176112912,"blockDiffActual":1351.176112912,"blockHash":"0000007212f19755fb017650d29e3823cf44a2b5aca1cf90baa36f3152951c0f","error":{"unknown":"check coin daemon logs"}}
ERROR: CheckEquihashSolution(): invalid solution
ERROR: CheckBlockHeader(): Equihash solution invalid
We thought a block was found but it was rejected by the daemon, share data: {"job":"d3a2","ip":"::ffff:x.x.x.x","port":2053,"worker":"t1xxxxxxxxxeL","height":236147,"difficulty":0.2,"shareDiff":"4596.03419805","blockDiff":1351.176112912,"blockDiffActual":1351.176112912,"blockHash":"0000007212f19755fb017650d29e3823cf44a2b5aca1cf90baa36f3152951c0f","error":{"unknown":"check coin daemon logs"}}
ERROR: CheckEquihashSolution(): invalid solution
ERROR: CheckBlockHeader(): Equihash solution invalid
Have you considered that the user might just have used the wrong hash algorithm param when connecting to the pool?
If the protocol is different it goes right away as an error on the first submit.
I have tested all the pools listed on the first page. They all report shares mined with a wrong algorithm as correct back to the miner:
Quote
$ ./optiminer-equihash -a equihash200_9 -s zer-eu.forgetop.com:2053 -u <...> -p x
[2018-01-17 01:42:59.055] [default] [info] Optiminer/Equihash 2.1.2 (C) Optiminer 2017
[2018-01-17 01:42:59.055] [default] [info] Connecting to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.149] [default] [info] Using 2 verifier threads.
[2018-01-17 01:42:59.149] [default] [info] Using highly optimized kernel code for Fiji devices.
[2018-01-17 01:42:59.149] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Fiji.bin
[2018-01-17 01:42:59.150] [default] [info] Autodetected '--intensity 5' for device 0.
[2018-01-17 01:42:59.192] [default] [info] Extranonce is '60000043'.
[2018-01-17 01:42:59.233] [default] [info] Mining target is 0050000000000000000000000000000000000000000000000000000000000000
[2018-01-17 01:42:59.234] [default] [info] Got new work.
[2018-01-17 01:42:59.260] [default] [info] [GPU0] Device info: {"id": "0/0" "name": "Fiji" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.314] [default] [info] Connected to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.464] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.464] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.465] [default] [info] Autodetected '--intensity 5' for device 1.
[2018-01-17 01:42:59.570] [default] [info] [GPU1] Device info: {"id": "0/1" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.773] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.773] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.773] [default] [info] Autodetected '--intensity 5' for device 2.
[2018-01-17 01:42:59.879] [default] [info] [GPU2] Device info: {"id": "0/2" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:43:01.015] [default] [info] [GPU2] Share accepted! (1 / 1)
[2018-01-17 01:43:02.549] [default] [info] [GPU0] Share accepted! (2 / 2)
[2018-01-17 01:43:03.061] [default] [info] [GPU2] Share accepted! (3 / 3)
[2018-01-17 01:42:59.055] [default] [info] Optiminer/Equihash 2.1.2 (C) Optiminer 2017
[2018-01-17 01:42:59.055] [default] [info] Connecting to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.149] [default] [info] Using 2 verifier threads.
[2018-01-17 01:42:59.149] [default] [info] Using highly optimized kernel code for Fiji devices.
[2018-01-17 01:42:59.149] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Fiji.bin
[2018-01-17 01:42:59.150] [default] [info] Autodetected '--intensity 5' for device 0.
[2018-01-17 01:42:59.192] [default] [info] Extranonce is '60000043'.
[2018-01-17 01:42:59.233] [default] [info] Mining target is 0050000000000000000000000000000000000000000000000000000000000000
[2018-01-17 01:42:59.234] [default] [info] Got new work.
[2018-01-17 01:42:59.260] [default] [info] [GPU0] Device info: {"id": "0/0" "name": "Fiji" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.314] [default] [info] Connected to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.464] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.464] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.465] [default] [info] Autodetected '--intensity 5' for device 1.
[2018-01-17 01:42:59.570] [default] [info] [GPU1] Device info: {"id": "0/1" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.773] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.773] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.773] [default] [info] Autodetected '--intensity 5' for device 2.
[2018-01-17 01:42:59.879] [default] [info] [GPU2] Device info: {"id": "0/2" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:43:01.015] [default] [info] [GPU2] Share accepted! (1 / 1)
[2018-01-17 01:43:02.549] [default] [info] [GPU0] Share accepted! (2 / 2)
[2018-01-17 01:43:03.061] [default] [info] [GPU2] Share accepted! (3 / 3)
It seems the pools internally filter those incorrect shares which is good. But they should be reported back to the miner as invalid.
The pool always get warnings when zcash solution is submited:
Share rejected: {"job":"ccd0","ip":"::ffff:x.x.x.x","worker":"xxxxx.xxx","difficulty":0.01,"error":"incorrect size of solution"}
And also there is no hashrate.
Unfortunately this is not the case with the problem. Not a single warning is presented in the log files.
Those ppl have good steady hasrate, everything is OK, just when it comes to finding block it got rejected from zcashd.
Just checked, the solution verification has stayed the same in optiminer since version 2.0. You are chasing a red herring here.
The problem also does not seem to be new: https://github.com/zerocurrency/zero/issues/6
My best guess would be that there is NOMP and zerod validate the block difficulty.
OPTI - genuine curiosity has got the better of me, hope you can straighten me out.
Monitored all 1.1 traffic over the course of 90 minutes (on a crap - 1sol - GPU). A little confused by the traffic patterns! Miner fires up and connects to Devfee server (88.99.30.25 / Proxy.optiminer.pl / static.25.30.99.88.clients.your-server.de) blah blah blah - expected.
But over the course of 90 minutes:
Sent packets to forgetop pool = 136 (132978 bytes)
Sent packets to you = 5 (1052 bytes)
Received packets from forgetop pool = 221 (29891)
Received packets from you = 89 (23264)
Seems like a fairly large payload for a heartbeat - it is a heartbeat yes? Odd direction considering the client shuts down on port block. No, it is not is it? Firewall shows client sending out heartbeat at a reasonable size of 60, and you respond with a payload of 250-300. Those packets are work – and they account for 35-40%. I can watch the miner state 'Got New Work' and BOOOOOOM - in real time - a tic in received packet count. Sometimes from you, sometimes from Forge.
Best be time to lawyer up!
So according to your 90 minute, low share test run, the optimizer getwork from dev server is consuming 28% of the download bandwidth (89/(221+ 89)), but only 3.5% (5/ (136+5)) of the upload bandwidth. Wouldn't this suggest that the dev fee is close to what is advertised, since only 3.5% of the data submitted (as in shares) was going to the dev sever? Especially considering your very low sample size.
Maybe you should explain it again, I don't see a problem here.
Valid points although I think sample size is irrelevant - the client is consistent in its ping to the devfee server, that server is consistent in its reply. And each reply can be visually correlated with a Got New Work line item in the client. Without having access to the underlying src, it is more than plausible to assume that close to 1/3rd of hashing power is being diverted.
What is more telling since I blocked all comm with devfee - my chart has flattened out a bit while my avg HR has remained near consistent. This is what needs a bigger sample size - I'll report back in 24.
All rigs doing ZER work btw...
I
I don't see how it is plausible to assume that network download bandwidth correlates to diverted hashrate without corresponding upload bandwidth. All it really shows is that optiminer is downloading the data needed to do POW calculations, not that its actually doing them. If however you can prove that the program is uploading shares at a higher than expected rate then you have some evidence. When you blocked comm traffic with the dev server did your hashrate change at all, increase by 33%?
Quote
Here is an example from log files
We thought a block was found but it was rejected by the daemon, share data: {"job":"d3a2","ip":"::ffff:x.x.x.x","port":2053,"worker":"t1xxxxxxxxxeL","height":236147,"difficulty":0.2,"shareDiff":"4596.03419805","blockDiff":1351.176112912,"blockDiffActual":1351.176112912,"blockHash":"0000007212f19755fb017650d29e3823cf44a2b5aca1cf90baa36f3152951c0f","error":{"unknown":"check coin daemon logs"}}
ERROR: CheckEquihashSolution(): invalid solution
ERROR: CheckBlockHeader(): Equihash solution invalid
We thought a block was found but it was rejected by the daemon, share data: {"job":"d3a2","ip":"::ffff:x.x.x.x","port":2053,"worker":"t1xxxxxxxxxeL","height":236147,"difficulty":0.2,"shareDiff":"4596.03419805","blockDiff":1351.176112912,"blockDiffActual":1351.176112912,"blockHash":"0000007212f19755fb017650d29e3823cf44a2b5aca1cf90baa36f3152951c0f","error":{"unknown":"check coin daemon logs"}}
ERROR: CheckEquihashSolution(): invalid solution
ERROR: CheckBlockHeader(): Equihash solution invalid
Have you considered that the user might just have used the wrong hash algorithm param when connecting to the pool?
If the protocol is different it goes right away as an error on the first submit.
I have tested all the pools listed on the first page. They all report shares mined with a wrong algorithm as correct back to the miner:
Quote
$ ./optiminer-equihash -a equihash200_9 -s zer-eu.forgetop.com:2053 -u <...> -p x
[2018-01-17 01:42:59.055] [default] [info] Optiminer/Equihash 2.1.2 (C) Optiminer 2017
[2018-01-17 01:42:59.055] [default] [info] Connecting to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.149] [default] [info] Using 2 verifier threads.
[2018-01-17 01:42:59.149] [default] [info] Using highly optimized kernel code for Fiji devices.
[2018-01-17 01:42:59.149] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Fiji.bin
[2018-01-17 01:42:59.150] [default] [info] Autodetected '--intensity 5' for device 0.
[2018-01-17 01:42:59.192] [default] [info] Extranonce is '60000043'.
[2018-01-17 01:42:59.233] [default] [info] Mining target is 0050000000000000000000000000000000000000000000000000000000000000
[2018-01-17 01:42:59.234] [default] [info] Got new work.
[2018-01-17 01:42:59.260] [default] [info] [GPU0] Device info: {"id": "0/0" "name": "Fiji" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.314] [default] [info] Connected to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.464] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.464] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.465] [default] [info] Autodetected '--intensity 5' for device 1.
[2018-01-17 01:42:59.570] [default] [info] [GPU1] Device info: {"id": "0/1" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.773] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.773] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.773] [default] [info] Autodetected '--intensity 5' for device 2.
[2018-01-17 01:42:59.879] [default] [info] [GPU2] Device info: {"id": "0/2" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:43:01.015] [default] [info] [GPU2] Share accepted! (1 / 1)
[2018-01-17 01:43:02.549] [default] [info] [GPU0] Share accepted! (2 / 2)
[2018-01-17 01:43:03.061] [default] [info] [GPU2] Share accepted! (3 / 3)
[2018-01-17 01:42:59.055] [default] [info] Optiminer/Equihash 2.1.2 (C) Optiminer 2017
[2018-01-17 01:42:59.055] [default] [info] Connecting to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.149] [default] [info] Using 2 verifier threads.
[2018-01-17 01:42:59.149] [default] [info] Using highly optimized kernel code for Fiji devices.
[2018-01-17 01:42:59.149] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Fiji.bin
[2018-01-17 01:42:59.150] [default] [info] Autodetected '--intensity 5' for device 0.
[2018-01-17 01:42:59.192] [default] [info] Extranonce is '60000043'.
[2018-01-17 01:42:59.233] [default] [info] Mining target is 0050000000000000000000000000000000000000000000000000000000000000
[2018-01-17 01:42:59.234] [default] [info] Got new work.
[2018-01-17 01:42:59.260] [default] [info] [GPU0] Device info: {"id": "0/0" "name": "Fiji" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.314] [default] [info] Connected to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.464] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.464] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.465] [default] [info] Autodetected '--intensity 5' for device 1.
[2018-01-17 01:42:59.570] [default] [info] [GPU1] Device info: {"id": "0/1" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.773] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.773] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.773] [default] [info] Autodetected '--intensity 5' for device 2.
[2018-01-17 01:42:59.879] [default] [info] [GPU2] Device info: {"id": "0/2" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:43:01.015] [default] [info] [GPU2] Share accepted! (1 / 1)
[2018-01-17 01:43:02.549] [default] [info] [GPU0] Share accepted! (2 / 2)
[2018-01-17 01:43:03.061] [default] [info] [GPU2] Share accepted! (3 / 3)
It seems the pools internally filter those incorrect shares which is good. But they should be reported back to the miner as invalid.
The pool always get warnings when zcash solution is submited:
Share rejected: {"job":"ccd0","ip":"::ffff:x.x.x.x","worker":"xxxxx.xxx","difficulty":0.01,"error":"incorrect size of solution"}
And also there is no hashrate.
Unfortunately this is not the case with the problem. Not a single warning is presented in the log files.
Those ppl have good steady hasrate, everything is OK, just when it comes to finding block it got rejected from zcashd.
Just checked, the solution verification has stayed the same in optiminer since version 2.0. You are chasing a red herring here.
The problem also does not seem to be new: https://github.com/zerocurrency/zero/issues/6
My best guess would be that there is NOMP and zerod validate the block difficulty.
OPTI - genuine curiosity has got the better of me, hope you can straighten me out.
Monitored all 1.1 traffic over the course of 90 minutes (on a crap - 1sol - GPU). A little confused by the traffic patterns! Miner fires up and connects to Devfee server (88.99.30.25 / Proxy.optiminer.pl / static.25.30.99.88.clients.your-server.de) blah blah blah - expected.
But over the course of 90 minutes:
Sent packets to forgetop pool = 136 (132978 bytes)
Sent packets to you = 5 (1052 bytes)
Received packets from forgetop pool = 221 (29891)
Received packets from you = 89 (23264)
Seems like a fairly large payload for a heartbeat - it is a heartbeat yes? Odd direction considering the client shuts down on port block. No, it is not is it? Firewall shows client sending out heartbeat at a reasonable size of 60, and you respond with a payload of 250-300. Those packets are work – and they account for 35-40%. I can watch the miner state 'Got New Work' and BOOOOOOM - in real time - a tic in received packet count. Sometimes from you, sometimes from Forge.
Best be time to lawyer up!
So according to your 90 minute, low share test run, the optimizer getwork from dev server is consuming 28% of the download bandwidth (89/(221+ 89)), but only 3.5% (5/ (136+5)) of the upload bandwidth. Wouldn't this suggest that the dev fee is close to what is advertised, since only 3.5% of the data submitted (as in shares) was going to the dev sever? Especially considering your very low sample size.
Maybe you should explain it again, I don't see a problem here.
Valid points although I think sample size is irrelevant - the client is consistent in its ping to the devfee server, that server is consistent in its reply. And each reply can be visually correlated with a Got New Work line item in the client. Without having access to the underlying src, it is more than plausible to assume that close to 1/3rd of hashing power is being diverted.
What is more telling since I blocked all comm with devfee - my chart has flattened out a bit while my avg HR has remained near consistent. This is what needs a bigger sample size - I'll report back in 24.
All rigs doing ZER work btw...
I
Quote
Here is an example from log files
We thought a block was found but it was rejected by the daemon, share data: {"job":"d3a2","ip":"::ffff:x.x.x.x","port":2053,"worker":"t1xxxxxxxxxeL","height":236147,"difficulty":0.2,"shareDiff":"4596.03419805","blockDiff":1351.176112912,"blockDiffActual":1351.176112912,"blockHash":"0000007212f19755fb017650d29e3823cf44a2b5aca1cf90baa36f3152951c0f","error":{"unknown":"check coin daemon logs"}}
ERROR: CheckEquihashSolution(): invalid solution
ERROR: CheckBlockHeader(): Equihash solution invalid
We thought a block was found but it was rejected by the daemon, share data: {"job":"d3a2","ip":"::ffff:x.x.x.x","port":2053,"worker":"t1xxxxxxxxxeL","height":236147,"difficulty":0.2,"shareDiff":"4596.03419805","blockDiff":1351.176112912,"blockDiffActual":1351.176112912,"blockHash":"0000007212f19755fb017650d29e3823cf44a2b5aca1cf90baa36f3152951c0f","error":{"unknown":"check coin daemon logs"}}
ERROR: CheckEquihashSolution(): invalid solution
ERROR: CheckBlockHeader(): Equihash solution invalid
Have you considered that the user might just have used the wrong hash algorithm param when connecting to the pool?
If the protocol is different it goes right away as an error on the first submit.
I have tested all the pools listed on the first page. They all report shares mined with a wrong algorithm as correct back to the miner:
Quote
$ ./optiminer-equihash -a equihash200_9 -s zer-eu.forgetop.com:2053 -u <...> -p x
[2018-01-17 01:42:59.055] [default] [info] Optiminer/Equihash 2.1.2 (C) Optiminer 2017
[2018-01-17 01:42:59.055] [default] [info] Connecting to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.149] [default] [info] Using 2 verifier threads.
[2018-01-17 01:42:59.149] [default] [info] Using highly optimized kernel code for Fiji devices.
[2018-01-17 01:42:59.149] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Fiji.bin
[2018-01-17 01:42:59.150] [default] [info] Autodetected '--intensity 5' for device 0.
[2018-01-17 01:42:59.192] [default] [info] Extranonce is '60000043'.
[2018-01-17 01:42:59.233] [default] [info] Mining target is 0050000000000000000000000000000000000000000000000000000000000000
[2018-01-17 01:42:59.234] [default] [info] Got new work.
[2018-01-17 01:42:59.260] [default] [info] [GPU0] Device info: {"id": "0/0" "name": "Fiji" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.314] [default] [info] Connected to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.464] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.464] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.465] [default] [info] Autodetected '--intensity 5' for device 1.
[2018-01-17 01:42:59.570] [default] [info] [GPU1] Device info: {"id": "0/1" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.773] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.773] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.773] [default] [info] Autodetected '--intensity 5' for device 2.
[2018-01-17 01:42:59.879] [default] [info] [GPU2] Device info: {"id": "0/2" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:43:01.015] [default] [info] [GPU2] Share accepted! (1 / 1)
[2018-01-17 01:43:02.549] [default] [info] [GPU0] Share accepted! (2 / 2)
[2018-01-17 01:43:03.061] [default] [info] [GPU2] Share accepted! (3 / 3)
[2018-01-17 01:42:59.055] [default] [info] Optiminer/Equihash 2.1.2 (C) Optiminer 2017
[2018-01-17 01:42:59.055] [default] [info] Connecting to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.149] [default] [info] Using 2 verifier threads.
[2018-01-17 01:42:59.149] [default] [info] Using highly optimized kernel code for Fiji devices.
[2018-01-17 01:42:59.149] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Fiji.bin
[2018-01-17 01:42:59.150] [default] [info] Autodetected '--intensity 5' for device 0.
[2018-01-17 01:42:59.192] [default] [info] Extranonce is '60000043'.
[2018-01-17 01:42:59.233] [default] [info] Mining target is 0050000000000000000000000000000000000000000000000000000000000000
[2018-01-17 01:42:59.234] [default] [info] Got new work.
[2018-01-17 01:42:59.260] [default] [info] [GPU0] Device info: {"id": "0/0" "name": "Fiji" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.314] [default] [info] Connected to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.464] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.464] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.465] [default] [info] Autodetected '--intensity 5' for device 1.
[2018-01-17 01:42:59.570] [default] [info] [GPU1] Device info: {"id": "0/1" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.773] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.773] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.773] [default] [info] Autodetected '--intensity 5' for device 2.
[2018-01-17 01:42:59.879] [default] [info] [GPU2] Device info: {"id": "0/2" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:43:01.015] [default] [info] [GPU2] Share accepted! (1 / 1)
[2018-01-17 01:43:02.549] [default] [info] [GPU0] Share accepted! (2 / 2)
[2018-01-17 01:43:03.061] [default] [info] [GPU2] Share accepted! (3 / 3)
It seems the pools internally filter those incorrect shares which is good. But they should be reported back to the miner as invalid.
The pool always get warnings when zcash solution is submited:
Share rejected: {"job":"ccd0","ip":"::ffff:x.x.x.x","worker":"xxxxx.xxx","difficulty":0.01,"error":"incorrect size of solution"}
And also there is no hashrate.
Unfortunately this is not the case with the problem. Not a single warning is presented in the log files.
Those ppl have good steady hasrate, everything is OK, just when it comes to finding block it got rejected from zcashd.
Just checked, the solution verification has stayed the same in optiminer since version 2.0. You are chasing a red herring here.
The problem also does not seem to be new: https://github.com/zerocurrency/zero/issues/6
My best guess would be that there is NOMP and zerod validate the block difficulty.
OPTI - genuine curiosity has got the better of me, hope you can straighten me out.
Monitored all 1.1 traffic over the course of 90 minutes (on a crap - 1sol - GPU). A little confused by the traffic patterns! Miner fires up and connects to Devfee server (88.99.30.25 / Proxy.optiminer.pl / static.25.30.99.88.clients.your-server.de) blah blah blah - expected.
But over the course of 90 minutes:
Sent packets to forgetop pool = 136 (132978 bytes)
Sent packets to you = 5 (1052 bytes)
Received packets from forgetop pool = 221 (29891)
Received packets from you = 89 (23264)
Seems like a fairly large payload for a heartbeat - it is a heartbeat yes? Odd direction considering the client shuts down on port block. No, it is not is it? Firewall shows client sending out heartbeat at a reasonable size of 60, and you respond with a payload of 250-300. Those packets are work – and they account for 35-40%. I can watch the miner state 'Got New Work' and BOOOOOOM - in real time - a tic in received packet count. Sometimes from you, sometimes from Forge.
Best be time to lawyer up!
So according to your 90 minute, low share test run, the optimizer getwork from dev server is consuming 28% of the download bandwidth (89/(221+ 89)), but only 3.5% (5/ (136+5)) of the upload bandwidth. Wouldn't this suggest that the dev fee is close to what is advertised, since only 3.5% of the data submitted (as in shares) was going to the dev sever? Especially considering your very low sample size.
Maybe you should explain it again, I don't see a problem here.
dammm weak hands here.
Quote
Here is an example from log files
We thought a block was found but it was rejected by the daemon, share data: {"job":"d3a2","ip":"::ffff:x.x.x.x","port":2053,"worker":"t1xxxxxxxxxeL","height":236147,"difficulty":0.2,"shareDiff":"4596.03419805","blockDiff":1351.176112912,"blockDiffActual":1351.176112912,"blockHash":"0000007212f19755fb017650d29e3823cf44a2b5aca1cf90baa36f3152951c0f","error":{"unknown":"check coin daemon logs"}}
ERROR: CheckEquihashSolution(): invalid solution
ERROR: CheckBlockHeader(): Equihash solution invalid
We thought a block was found but it was rejected by the daemon, share data: {"job":"d3a2","ip":"::ffff:x.x.x.x","port":2053,"worker":"t1xxxxxxxxxeL","height":236147,"difficulty":0.2,"shareDiff":"4596.03419805","blockDiff":1351.176112912,"blockDiffActual":1351.176112912,"blockHash":"0000007212f19755fb017650d29e3823cf44a2b5aca1cf90baa36f3152951c0f","error":{"unknown":"check coin daemon logs"}}
ERROR: CheckEquihashSolution(): invalid solution
ERROR: CheckBlockHeader(): Equihash solution invalid
Have you considered that the user might just have used the wrong hash algorithm param when connecting to the pool?
If the protocol is different it goes right away as an error on the first submit.
I have tested all the pools listed on the first page. They all report shares mined with a wrong algorithm as correct back to the miner:
Quote
$ ./optiminer-equihash -a equihash200_9 -s zer-eu.forgetop.com:2053 -u <...> -p x
[2018-01-17 01:42:59.055] [default] [info] Optiminer/Equihash 2.1.2 (C) Optiminer 2017
[2018-01-17 01:42:59.055] [default] [info] Connecting to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.149] [default] [info] Using 2 verifier threads.
[2018-01-17 01:42:59.149] [default] [info] Using highly optimized kernel code for Fiji devices.
[2018-01-17 01:42:59.149] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Fiji.bin
[2018-01-17 01:42:59.150] [default] [info] Autodetected '--intensity 5' for device 0.
[2018-01-17 01:42:59.192] [default] [info] Extranonce is '60000043'.
[2018-01-17 01:42:59.233] [default] [info] Mining target is 0050000000000000000000000000000000000000000000000000000000000000
[2018-01-17 01:42:59.234] [default] [info] Got new work.
[2018-01-17 01:42:59.260] [default] [info] [GPU0] Device info: {"id": "0/0" "name": "Fiji" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.314] [default] [info] Connected to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.464] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.464] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.465] [default] [info] Autodetected '--intensity 5' for device 1.
[2018-01-17 01:42:59.570] [default] [info] [GPU1] Device info: {"id": "0/1" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.773] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.773] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.773] [default] [info] Autodetected '--intensity 5' for device 2.
[2018-01-17 01:42:59.879] [default] [info] [GPU2] Device info: {"id": "0/2" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:43:01.015] [default] [info] [GPU2] Share accepted! (1 / 1)
[2018-01-17 01:43:02.549] [default] [info] [GPU0] Share accepted! (2 / 2)
[2018-01-17 01:43:03.061] [default] [info] [GPU2] Share accepted! (3 / 3)
[2018-01-17 01:42:59.055] [default] [info] Optiminer/Equihash 2.1.2 (C) Optiminer 2017
[2018-01-17 01:42:59.055] [default] [info] Connecting to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.149] [default] [info] Using 2 verifier threads.
[2018-01-17 01:42:59.149] [default] [info] Using highly optimized kernel code for Fiji devices.
[2018-01-17 01:42:59.149] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Fiji.bin
[2018-01-17 01:42:59.150] [default] [info] Autodetected '--intensity 5' for device 0.
[2018-01-17 01:42:59.192] [default] [info] Extranonce is '60000043'.
[2018-01-17 01:42:59.233] [default] [info] Mining target is 0050000000000000000000000000000000000000000000000000000000000000
[2018-01-17 01:42:59.234] [default] [info] Got new work.
[2018-01-17 01:42:59.260] [default] [info] [GPU0] Device info: {"id": "0/0" "name": "Fiji" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.314] [default] [info] Connected to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.464] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.464] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.465] [default] [info] Autodetected '--intensity 5' for device 1.
[2018-01-17 01:42:59.570] [default] [info] [GPU1] Device info: {"id": "0/1" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.773] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.773] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.773] [default] [info] Autodetected '--intensity 5' for device 2.
[2018-01-17 01:42:59.879] [default] [info] [GPU2] Device info: {"id": "0/2" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:43:01.015] [default] [info] [GPU2] Share accepted! (1 / 1)
[2018-01-17 01:43:02.549] [default] [info] [GPU0] Share accepted! (2 / 2)
[2018-01-17 01:43:03.061] [default] [info] [GPU2] Share accepted! (3 / 3)
It seems the pools internally filter those incorrect shares which is good. But they should be reported back to the miner as invalid.
The pool always get warnings when zcash solution is submited:
Share rejected: {"job":"ccd0","ip":"::ffff:x.x.x.x","worker":"xxxxx.xxx","difficulty":0.01,"error":"incorrect size of solution"}
And also there is no hashrate.
Unfortunately this is not the case with the problem. Not a single warning is presented in the log files.
Those ppl have good steady hasrate, everything is OK, just when it comes to finding block it got rejected from zcashd.
Just checked, the solution verification has stayed the same in optiminer since version 2.0. You are chasing a red herring here.
The problem also does not seem to be new: https://github.com/zerocurrency/zero/issues/6
My best guess would be that there is NOMP and zerod validate the block difficulty.
OPTI - genuine curiosity has got the better of me, hope you can straighten me out.
Monitored all 1.1 traffic over the course of 90 minutes (on a crap - 1sol - GPU). A little confused by the traffic patterns! Miner fires up and connects to Devfee server (88.99.30.25 / Proxy.optiminer.pl / static.25.30.99.88.clients.your-server.de) blah blah blah - expected.
But over the course of 90 minutes:
Sent packets to forgetop pool = 136 (132978 bytes)
Sent packets to you = 5 (1052 bytes)
Received packets from forgetop pool = 221 (29891)
Received packets from you = 89 (23264)
Seems like a fairly large payload for a heartbeat - it is a heartbeat yes? Odd direction considering the client shuts down on port block. No, it is not is it? Firewall shows client sending out heartbeat at a reasonable size of 60, and you respond with a payload of 250-300. Those packets are work – and they account for 35-40%. I can watch the miner state 'Got New Work' and BOOOOOOM - in real time - a tic in received packet count. Sometimes from you, sometimes from Forge.
Best be time to lawyer up!
I was a miner at suprnova then I mined for 24h at forgetop because people here said it pay more but after 24h i had about 40% less.. now switched back to suprnova and after about 12h I already have about the same amount i was mining in 24 on forgetop..
After some constructive chat in the telegram group with sailor32, here is the update:
The average suprova hashrate for the last 12h is around 70K.
If you enter this number in whattomine, you get around 3500 coins.
If on the other hand you multiply the 10 coins you get with a 100S/s hashrate by 700, you get 7000 coins.
These two calculations contradict directly.
It looks like when you add a hashrate into whattomine, their algo/formula adds this hash to the global net hash, this way increasing difficulty and decreasing the estimated rewards.
I cannot verify this assumption regarding the wtm estimation algorithm, but if it is true, then this would give a plausible answer to my question.
If anyone has a different point of view or happen to know more regarding wtm algorithm, now would the the time to speak up.
As for pool stability, I agree that suprnova is very stable and I am also aware that forgetop has been suffering from server crashes, which are attributed to DDOS attacks and other malicious attempts.
The average suprova hashrate for the last 12h is around 70K.
If you enter this number in whattomine, you get around 3500 coins.
If on the other hand you multiply the 10 coins you get with a 100S/s hashrate by 700, you get 7000 coins.
These two calculations contradict directly.
It looks like when you add a hashrate into whattomine, their algo/formula adds this hash to the global net hash, this way increasing difficulty and decreasing the estimated rewards.
I cannot verify this assumption regarding the wtm estimation algorithm, but if it is true, then this would give a plausible answer to my question.
If anyone has a different point of view or happen to know more regarding wtm algorithm, now would the the time to speak up.
As for pool stability, I agree that suprnova is very stable and I am also aware that forgetop has been suffering from server crashes, which are attributed to DDOS attacks and other malicious attempts.
Why keep open other pools ?
Can I ask you something? I would like you to tell me what you honestly think, since you have quite some experience.
Users mining on suprnova report that they get rewarded according to whattomine predictions.
So, according to whattomine right now, a 100S/s hashrate rewards a miner with 10.5 coins per day.
This means that a 65,000 hashrate would give 3505 coins per day.
65,000 S/s is suprnova's total hashrate.
3505 coins equal 350 blocks.
Suprnova (as yourself also noticed) mined 620 blocks in 24h.
This is a difference of 270 blocks in 24h.
Question:
If WTM is correct and miners report they get whatever WTM predicts, then where do these 270 blocks=2700 zer per day go?
If WTM is incorrect and suprnova indeed mines 620 blocks, how can miners report that they get what WTM predicts?
Am I wrong somewhere? I could. I am asking everybody to verify my calculations and to give feedback.
I think your math has an error.
If 100 Sols/s = 10.5 zer/day then 65,000 Sols/s would be 6,825 zer/day or 682.5 blocks. 62.5 more than suprnova mined, but only 9% off from the prediction.
On the matter of other pools, I think it is unhealthy for the network as a whole to be so heavy into one pool but even our second largest pool seems to have reliability issues that suprnova does not. I mined to suprnova for months and in all the time i've mined to it, it was only down once for a few hours. I started mining to forgetop when it came online, but I've lost count how many times it has gone down and have decided to go back to suprnova for a while. Hopefully when the community pool comes online it will prove more reliable.
Jump to: