de.ckpool.org is up.... but solo.ckpool.org for me is down  and for rent on miningringrentals sha256 I have problem whit my rent don't connect No sign that there is anything wrong with the pool at the moment. It appears there may have been a connectivity issue for half an hour there. On the other hand, as the solo website says, for incompatible rental services that don't support redirection, use port 3334. |
|
|
|
So what exactly would happen with everyones current 1xxxx wallets that hold funds?
Absolutely nothing. The existing 1x transactions work the way they always did, using the standard blockchain space and mechanism for transactions, signing, and verification. |
|
|
|
|
Are you signalling for segwit with the new pool? Your last block on the old pool did not.
|
|
|
|
GL to me and everyone here! Friday lottery time has come again! Actually Saturday already))) And congrats to the recent block finders!
As far as I understand, there's no more such thing as the test pool and everybody is voting for segwit and I can come back to .de node as before, right?
Yes that's right. Both pools are now signalling segwit and there is no test pool, though I left the 13333 port open so that people don't need to change their mining settings if they had changed it. All the pool code updates have gone smoothly and they're purring nicely. The changes were to decrease overhead in the code even further and make the two pools give each other more information, mainly to be able to submit blocks at both locations faster than ever for more rapid block propagation. People interested can observe all the code changes in the ckpool git. While the solo code is unique compared to what's in the public git, the recent improvements are common to both. All the planned improvements are complete and there are no more pending updates in the near future. All there is now is to go back to finding blocks. |
|
|
|
Whats up with the reported workers? My stats show I have 38, I only actually have 2 miners. Pool stats show over 86 thousand.
That's what we in the industry call a "bug" that needs fixing. It's only cosmetic luckily but I don't have a proper fix for it yet and it will require another restart. I've been trying to do restarts only if there is a real world improvement. I'll be restarting again in the next hour to fix this and other minor issues still annoying me. Downtime as always should be minimal to unnoticeable. Restarts complete. All seems fine. Come on block... |
|
|
|
Whats up with the reported workers? My stats show I have 38, I only actually have 2 miners. Pool stats show over 86 thousand.
That's what we in the industry call a "bug" that needs fixing. It's only cosmetic luckily but I don't have a proper fix for it yet and it will require another restart. I've been trying to do restarts only if there is a real world improvement. |
|
|
|
This pool has been reported as a sick pool at least in Europe
Pool's purring along fine. Only thing is I've blocked a few IP addresses for having bad usernames and trying to log in hundreds of times per minute. |
|
|
|
Posting a graph that has nothing to do with poisson distributions and CDF values shows you don't know what you are posting - that's why I deleted that last one - and will continue to delete the stats you keep posting coz it is all either misinformed, outright wrong or unrelated.
Well, I could post the whole 596 page teaching guide (that literally shows that you can't pass 5th grade).... but I'll start small... ...
Ratios are almost always fractions, but initially, one usually contrives to
make the ratio come out to be a whole number....
Percents first appear around grade 5. Students should recognize that
percents are special ratios, where the denominator (
or b in the ratio of
a to b
)
is 100... Statistics textbooks usually describe "sample size" on maybe the first page. |
|
|
|
Right. But the A6 did not find the block all by it self. It got there because of the work done by all. Right?
Nope, independent events. Each share is found on its own as I'm sure -ck will point out with more elegance than I.
There is no such thing as "progress towards a block". Every single hash has a chance of finding a block and is completely independent of every other hash on the same hardware even, let alone a whole pool. |
|
|
|
I guess I am just missing something here. How can you compare expected blocks of different miners when different miners are on this pool. The work sent from kano to the miners is random right? So if a A6 hits a block. It is most likely because s9's did a lot of the work. Or A7's,s5's,s3's,or whatever else miners are out there. The only way you could truly compare the expected blocks is if they were each in their own pool.
We can identify most mining hardware from the mining protocol information so we can associate shares with the mining hardware it came from and derive statistical data from that. That's done in addition to checking the mining data on a per-user and per-worker basis. |
|
|
|
While you and Kano might not be, in order to apply that statement broadly, it seems you've only been skimming every 3rd post or so.  Me? I hate how much time I spend on this forum: https://bitcointalk.org/index.php?action=profile;u=19971;sa=statPanelI'd love to avoid coming here as much as I do since I have a sense of obligation now that I am a moderator, but all the other moderators have gone idle  I do read far too many threads so don't assume I've been skimming (it's not exactly all enjoyable reading, nor the friendliest forum on earth.) Giving the recommendation I did did not come lightly. Even kano has avoided explicitly spelling it out the way I did and he's very conscious of the potential loss of significant hashrate if people just point their hashes elsewhere. I did not tell people to point their hashes elsewhere, but I'm recommending people upgrade IF they can AND it suits. You're right that I did not explicitly say so in the earlier post though. |
|
|
|
...The S9 batch 1 across all miners as you see above by now should have found 110 blocks based on the total hashes they've submitted to this pool but have so far only found 82. This is by far worse than any other device that we can positively identify....
Yeah, no. As I posted before...... ... Name CDF[Erl]
S9v1 0.994766 103.6 BDR 79 Blocks
...
A7v1 0.772224 6.5 BDR 5 Blocks
...
... When extrapolated, 6.5:5 is virtually* the same as 103.6:79! If you absolutely can not upgrade to the new autotune firmware (my case until April) You can pull from this pool and point to Antpool or f2pool
Just point auto tune s9's here or in my case avalon 7's. At the moment I have all my avalon 7's here and all my s9 old firmware at f2pool.
I am hoping to get some bitfury and point here.
The goal is to get all old firmware s9's off this pool
or updated to auto firmware if you can.
See above and see why you should be making the exact same appeal to A7 owners! *< 1 block difference in 103 total blocks No. Sample size is too small to draw the same conclusion with only 6.5 total BDR. Plus we're not saying CONCLUSIVELY that it is a problem, but upgrading firmware, where you can, is desirable since it MAY be a problem. |
|
|
|
Don't get me wrong, I'm not saying that S9s aren't a steaming pile of bovine dung; I'm saying that, dung or not, they pay the bills better than the current alternatives.
Not if they're not finding blocks... I am not sure how to interpret this from a practical point of view. do other pools have the same phenomenon? What about slush's or other non-bitmain associated pools? If they do-I will subscribe to this argument of "poison" S9 v1 If they don't-? Are you saying the bad luck this pool is having is not really bad luck, just S9 not finding blocks on this pool?
Meanwhile the latest S9v1 statistics on the pool since the S9 existed:
They've found 82 Blocks, but expected to have found (BDR) 110.666 ...
Kano does a luck report regularly to find block withholders - they show up as making no blocks at all over an extended period when they should have made some (it's random so you can't detect it until they've been hashing many blocks' worth). He reports it here regularly though I'm not sure everyone understands the implications of the report. The S9 batch 1 across all miners as you see above by now should have found 110 blocks based on the total hashes they've submitted to this pool but have so far only found 82. This is by far worse than any other device that we can positively identify. We can only speculate why this is, but the batch 1 firmware also had some other stratum extension that was never working on any pools so it was removed in later firmware. It is possible there is some kind of bug in the original firmware. This is why he was urging everyone with S9s that was still on v1 firmware to upgrade. I'm aware that you lose some kind of frequency control or fan control or something by upgrading but that's nowhere near as bad as (potentially) losing blocks. As for whether other pools are affected, we can only report accurately what happens here, and only speculate what is happening on other pools based on people grumbling about bad luck on almost every other pool thread. It certainly looks like global luck has been down across all pools since the S9 came out, but I can't say anything for certain. |
|
|
|
|
Anything over 990kb is effectively full for the current network block size limits. The algorithm to fill the last few bytes of a 1MB block is designed to not waste heaps of time sorting through thousands of transactions just to find the last few bytes to fill the block. However none of this matters because the size of the block ultimately is up to the miner's configuration. Some miners haven't even bothered changing the default which is set to 750kb in bitcoind, while others (like p2pool miners) have lowered it to work around terrible speed issues in their mining pool design with more transactions. Furthermore the network may have 1 million transactions pending but the miner is free to mine their next block with absolutely zero transactions beyond their generation transaction, and many large pools still do such an optimisation as a workaround for slow block changes in the rest of their tool chain. Basing block size on some dynamic mechanism based on the last block sizes is silly since it means it will depend on miners' whims as to how big the block is, and not really represent how many pending transactions are on the network. Alternatively basing it on the number of pending transactions is also silly because one man's high priority transaction is another's spam, and vice versa. Dynamic sounds good in theory but fails to address the issue that not all miners are altruistic and choose defaults that are best for the network.
|
|
|
|
I did split my ths equal to antpool and ckpool. I will leave it for 3 days to see how it goes.
60ths is enough to have my own pool or what should be enough. I'm planing to extend soon even more.
Thanks for your time.
That's kind of pointless since it takes 5 days to start getting maximum rewards on kano.is ckpool. |
|
|
|
Don't get me wrong, I'm not saying that S9s aren't a steaming pile of bovine dung; I'm saying that, dung or not, they pay the bills better than the current alternatives.
Not if they're not finding blocks... |
|
|
|
Updating both bitcoinds to 0.13.2 based versions shortly.
Completed. Note that there are still 4 users who have been trying to log in repeatedly with invalid usernames. I have since blocked your IP addresses so if you cannot connect at all you may be one of them. For those with low hashrate hardware that are having trouble staying on the pool now, it is probably related to the increase in starting diff to 4000, so you can work around this by adding --suggest-diff and a suitable diff to your mining device. Note that there is hardly any reason to use suggest diff otherwise on this pool. |
|
|
|
|
Just looks like a canned polite response to me. Alas, nothing to see here, move along.
|
|
|
|
|
Show Posts
