[∞ YH] solo.ckpool.org 2% fee solo mining USA/DE 255 blocks solved!

[-ck]

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?

[1715013631]

1715013631

[1715013631]

1715013631

[1715013631]

1715013631

[WBF1]

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.

[zahzin]

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..

[-ck]

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.

[Mikestang]

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.

[-ck]

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.

[welshy82]

gonna try my luck with 3 antminer s1 mayaswell have a bash for a while

[buckeyez]

gonna try my luck with 3 antminer s1 mayaswell have a bash for a while

good luck

[Denizs66]

Update:
We are still hashing with 1PH yesteday we tryed 5PH for 4Hours but the Bestshare dont change.
http://solo.ckpool.org/workers/1Q8VghUJkNeFnaKy553b9buUWKxFYL579G_megalotto

"bestshare": 99850230440.55542

Wish us Luck for today guys

[tutorialevideo]

Update:
We are still hashing with 1PH yesteday we tryed 5PH for 4Hours but the Bestshare dont change.
http://solo.ckpool.org/workers/1Q8VghUJkNeFnaKy553b9buUWKxFYL579G_megalotto

"bestshare": 99850230440.55542

Wish us Luck for today guys

Bestshare will change only when is a new block found

[os2sam]

Update:
We are still hashing with 1PH yesteday we tryed 5PH for 4Hours but the Bestshare dont change.
http://solo.ckpool.org/workers/1Q8VghUJkNeFnaKy553b9buUWKxFYL579G_megalotto

"bestshare": 99850230440.55542

Wish us Luck for today guys

Bestshare will change only when is a new block found

Best share will change when a higher diff share is found.  It is reset on block find.  Best ever is sticky through blocks.

[WBF1]

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.

Changed mining to a new address and all seems to be well. Note that it had to be an entire new address, not just worker name. (so now I have different addresses for DE and main, but I suppose that's OK)

[-ck]

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.

[CuriousJoe]

Your last sentence is correct.  It was a lucky gamble.  800TH/s expects to take about 7.5 days to find a block at current difficulty.  Congrats on the hit, though!

  thanks, that being said though i was ~1/3 the pools power so combing pool hash power plus the time since the last block solved by the pool, the odds were a little more to my favor. but still lucky as hell..

No, sorry that's wrong. The total pool's hashrate and the duration since the last block have precisely zero effect on your chance of finding a block. Only your hashrate matters. I will keep saying this over and over. If you have a "system" in your head for how to gamble based on current pool hashrate, time since last block, predicting when and where the next block will be etc., that's your business, but please don't try to tell people that it's fact or scientific.

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?

[-ck]

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.

[madmartyk]

Your last sentence is correct.  It was a lucky gamble.  800TH/s expects to take about 7.5 days to find a block at current difficulty.  Congrats on the hit, though!

  thanks, that being said though i was ~1/3 the pools power so combing pool hash power plus the time since the last block solved by the pool, the odds were a little more to my favor. but still lucky as hell..

No, sorry that's wrong. The total pool's hashrate and the duration since the last block have precisely zero effect on your chance of finding a block. Only your hashrate matters. I will keep saying this over and over. If you have a "system" in your head for how to gamble based on current pool hashrate, time since last block, predicting when and where the next block will be etc., that's your business, but please don't try to tell people that it's fact or scientific.

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, if you have a bunch of miners at home, you would solo mine to the BTC wallet if you wanted.

[CuriousJoe]

Yes, if you have a bunch of miners at home, you would solo mine to the BTC wallet if you wanted.

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.

Much appreciated!

[chiguireitor]

...

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?

[-ck]

...

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.

[chiguireitor]

...

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.

No, there's no warning right now, just the warnings i read on the README and such that piqued my curiosity.