|
Both of those last 2 blocks were barely more than the diff required to solve a block - had they happened after the impending diff change shortly they would not have been blocks. Gonna need more lube after the next diff change...
|
|
|
|
|
Someone is still trying to mine with this address which is not a valid bitcoin address:
1MH1vCtVEmN5Vjqj2Mq3Gxxhh6fabn8x7
Please check your miner configuration.
|
|
|
|
nhando1977 3,324.17THs What the hell??  I would prefer a Solopool with this (rent)hashrate It's more fun to be part of the party then to dance solo. GO TEAM KANO!!! P.S I've been rooting for Kano pool to hit 40PH+ since day 1. We need diversity.... on some days kano does just as good the 40Ph pool Twice as good... it finds as many blocks but ends up paying out twice as much as a result  |
|
|
|
|
Buy, mine, sell before halving.
|
|
|
|
Thanks Willi. Good luck with any further lottos you run. |
|
|
|
[2016-02-06 02:35:15.481] Possible block solve diff 408910813208.166382 !
[2016-02-06 02:35:15.589] BLOCK ACCEPTED!
[2016-02-06 02:35:15.590] Solved and confirmed block 396990 by 1BY56HUVrmr5k6GLeuDYo98NdvgxjxxZcc.AntMiner5
[2016-02-06 02:35:15.590] User 1BY56HUVrmr5k6GLeuDYo98NdvgxjxxZcc:{"hashrate1m": "15.8T", "hashrate5m": "14.7T", "hashrate1hr": "14.4T", "hashrate1d": "5.27T", "hashrate7d": "907G"}
[2016-02-06 02:35:15.590] Worker 1BY56HUVrmr5k6GLeuDYo98NdvgxjxxZcc.AntMiner5:{"hashrate1m": "5T", "hashrate5m": "4.89T", "hashrate1hr": "4.74T", "hashrate1d": "4.71T", "hashrate7d": "3.8T"}
[2016-02-06 02:35:15.590] Block solved after 15376037314 shares at 12.8% diff
15TH miner! |
|
|
|
[2016-02-06 02:30:34.631] Possible block solve diff 655117758757.222900 !
[2016-02-06 02:30:34.894] BLOCK ACCEPTED!
[2016-02-06 02:30:34.896] Solved and confirmed block 396941 by 1Q8VghUJkNeFnaKy553b9buUWKxFYL579G_megalotto
[2016-02-06 02:30:34.896] User 1Q8VghUJkNeFnaKy553b9buUWKxFYL579G:{"hashrate1m": "923T", "hashrate5m": "905T", "hashrate1hr": "959T", "hashrate1d": "185T", "hashrate7d": "28.9T"}
[2016-02-06 02:30:34.896] Worker 1Q8VghUJkNeFnaKy553b9buUWKxFYL579G_megalotto:{"hashrate1m": "923T", "hashrate5m": "905T", "hashrate1hr": "967T", "hashrate1d": "1.06P", "hashrate7d": "478T"}
[2016-02-05 20:30:36.818] Block solved after 323903866863 shares at 269.8% diff
|
|
|
|
...
Restarts complete. This should fix the issue where people find their username gets block as unauthorised.
By the way, just deployed two instances of ckproxy to interface to ckpool, and found a lot of warnings about "high" hashrate of the proxy not working with standard pools, how high is "high" and should i worry with 26 THs? That's odd, you shouldn't be getting that with this pool. Which server/port are you pointing them to and what version of ckproxy? You should be using the latest git master. EDIT: I'm guessing you have other pools in your configuration and they're the ones it's complaining about. |
|
|
|
I was going to wait till the next block was found before restarting the pools since the updates are only very small low level fixes, but there don't seem to be an awful lot of blocks being found so I'll be restarting them shortly. As always downtime should be negligible with most miners not even failing over.
Restarts complete. This should fix the issue where people find their username gets block as unauthorised. Thanks for clarifying that! Being new to the whole experience I would have thought total pool hash rate would have influenced speed in finding the next block. So, basically the total pool hash rate just shows the amount that's being produced as a whole, but it's the individual's hashing power that matters in their luck in finding a block?
Yes that's correct. The pool's total hashrate is only useful to me. Your chance of finding a block is completely independent of the pool's hashrate, time since last block found, etc. |
|
|
|
|
I was going to wait till the next block was found before restarting the pools since the updates are only very small low level fixes, but there don't seem to be an awful lot of blocks being found so I'll be restarting them shortly. As always downtime should be negligible with most miners not even failing over.
|
|
|
|
No need to point out each and every one of them. It's a regular occurrence. |
|
|
|
Thanks guys. Much appreciated. This is the addy CK has on his profile, thats where I sent mine. Hope it correct!
148KkS2vgVi4VzUi4JcKzM2PMaMVPi3nnq
Yes that's correct. The one in my profile is fine. |
|
|
|
.
CK, slightly off-topic; but is your recently added 'Node' mode in CKPool partway to a new implementation of the P2Pool sharechain ? Exactly the opposite. It makes a centralised pool work across many different locations. Sorry, I don't do any p2pool development. |
|
|
|
Why is it that some blocks we get much smaller rewards? Some examples below. Is it the difference in the transmission fees??
Block Block UTC Miner Reward
396558 3/Feb 22:51 24.80513300
393929 18/Jan 22:31 24.79041611
ive wondered this also There's this amazing technology called bitcoin. You should read about it. Apparently it allows an entire economy to be run through a peer 2 peer network making it possible to transmit currency to anywhere in the world for a tiny transaction fee. That transaction fee only ever gets large when there is a lot of money being exchanged on the peer 2 peer network. See how different peoples' understanding of bitcoin would be if they focused on and understood the economy first instead of thinking about it as a way to make money out of thin air through mining? |
|
|
|
No luck, oh well, inching closer to that first block little by little.
It's a shame, but mining doesn't work that way. |
|
|
|
Yes, it just sucks if it takes you a long time to submit an accepted share and then your work falls off the chain and you never receive anything.
 do the maths : receive nothing ... and big on P2Pool. receive a little every days ... on others pools. result = same reward after 3 months. many mining owners ... don't wait and want money now. When diff is rising... this is wrong. If you have a bad luck period on a small pool and diff is rising, you will never make it back. On the other hand the opposite is also true, if you have a good luck period when diff is rising, you will be ahead forever. And no, it does NOT work out in the end as luck is never guaranteed to average you out with changing diff. The part is italicked is true except the "forever" part - if difficulty drops *after* it rises (or vice versa) you could end up closer to expected. True enough, though diff drops have a history of happening only extremely rarely and never to fully drop to pre-rise levels... Next one due will be after the next halving, and it has so far still on average kept going up. So unless the value of btc crashes, I can only see the overall trend being upwards. |
|
|
|
Yes, it just sucks if it takes you a long time to submit an accepted share and then your work falls off the chain and you never receive anything.
do the maths : receive nothing ... and big on P2Pool. receive a little every days ... on others pools. result = same reward after 3 months. many mining owners ... don't wait and want money now. When diff is rising... this is wrong. If you have a bad luck period on a small pool and diff is rising, you will never make it back. On the other hand the opposite is also true, if you have a good luck period when diff is rising, you will be ahead forever. And no, it does NOT work out in the end as luck is never guaranteed to average you out with changing diff. |
|
|
|
Hmm that reminds me I've had this problem before. If you authed first on the DE pool you cannot auth on the main pool later on. I thought I'd fixed this bug but it seems to have returned. That would explain it. I'll look into it.
Is this related to a bug I posted about a couple weeks ago? Well, I guess I don't know if it's a bug or a flaw in the way the miner operates, but just wondering. The IP address of solo.ckpool.org changes after a DDoS and perhaps these devices almost never look up the IP address using a cached result for ages. In which case a restart might be required, either of cgminer or the whole device.
I have restarted the whole device 3 times (one of those was power off for 20+ minutes) and it still is in failover, I'll see if I can't flush its dns cache or something, thanks. I had the same bug a couple of weeks back, all I had to do was change the address I was mining to.
I could not locate any sort of dns reset in the S3 interface so I tried changing addresses and the pool was ALIVE again. I changed back to the old address thinking maybe I had cleared up the issue, but the old address reports the pool as DEAD. A new solo address for the US node it is then! Problem solved, thanks. Yep, probably the same pool bug. |
|
|
|
re: pool problems... it says "Failed authorization  " but I literally haven't changed a thing. Still [address].[worker] yes? I get same result on 3334 and 3333 Sure you haven't added a space or something in your username in your miner's config during copy/paste? Also once you fail to authorise you get throttled for attempted auths for the next 10 minutes (this has always been the case though). yeah 100% sure all i did was turn off my miners for like a day. oh and i had them pointed to kano.is for a while as well. That is most unusual indeed. Last time this happened to someone on this forum they restarted their machine and re-entered their credentials and everything worked after that. Perhaps in failover you never noticed it had never mined on solo and was always running on a backup? i'll reboot tomorrow sometime. happily mining on DE server right now. I have had same problem for a while, not being able to authenticate on the main server, but DE server is authenticating and working fine.. Have not reported it before since DE server is closer to me and did not want to bother thinking it was just me, but I can confirm I have copy pasted same address.worker name and can mine on DE but main SOLO is rejecting my authentication even if I put it as a backup.. Hmm that reminds me I've had this problem before. If you authed first on the DE pool you cannot auth on the main pool later on. I thought I'd fixed this bug but it seems to have returned. That would explain it. I'll look into it. |
|
|
|
|
Show Posts
