Right on.. Sorry i bothered Edit .. im sure i know why you dont like the rentals. and its not block withholding.. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) People are gaining the system with all this good luck.. pay ..0045 and get back double in return.. But that just takes from us loyal miners. Let me know if im wrong You can't tell if and when a rental decides to block withhold and the rentals themselves still get the same profit regardless of whether they hold or submit blocks. That they haven't so far is a good sign, so I'd run with rentals that have a reputation, but there's nothing stopping them doing it at any time in the future. If it weren't for rentals, solo wouldn't be anywhere near as successful as it is - I'm just saying there is a huge element of trust involved and renters should be aware of that.
|
|
|
Well...your question itself is the reason I don't rent hash. There's no BTCPD gonna look out for us. Our security is our own responsibility. That said, I'm sure the renters are, on the whole, honest...but I don't see much of a way to independently (as a user) verify that, and so my basically paranoid personality tends to rely on my own gear, and on a pool that essentially has the Bernie Sanders outlook...keep it honest, keep it efficient, and keep on truckin'... ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) Specifically, the hypothesis is that dishonest miners are contributing hashes but stealing blocks from various pools. If pools don't have a way of detecting such behavior, then what you would see is some longer-established pools starting to see consistent lower luck. New small pools such as kano would see relatively higher luck until the dishonest miners start infiltrating them as well. In other words, the anecdotal data on "luck" of different pools is consistent with there being dishonest miners out there. So what is or can be done to detect and/or block such miners? Certainly over time you can run statistical tests that would identify miners with below-average luck. At some point that becomes statistically significant, but a smart dishonest player could keep changing accounts to make this hard to detect. Or more realtime tricks could be done by the pool to detect and kill bad players up front. now where's the script for that ? ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) I'd have to go mine over at antpool or f2pool with that though huehuehue I thought i read somewhere that there was a proposal and it went something like this.. The pool operator is able to send your miner a "fake" share that would result in the miner returning a valid block to that fake share. then you could tell if the miners are witholding blocks.. Let me do some digging and ill come up with the article.. Best regards d57heinz Not possible to do reliably. Don't bother digging it up again. There's no safe way to trust rentals is the final conclusion.
|
|
|
and as you are in the UK I would move to the German servers Miners closer to Europe please use one of: de.ckpool.org:3333 de.ckpool.org:443 Just out of curiost what is the :443 port for, ddos protection backup server ? It's not a different server - it's the same pool just with multiple ports listening for connections. Some people mine through proxies that can only connect to http server ports. Then there's the GFW of China which is more suspicious of non http ports and blocks and filters them more aggressively.
|
|
|
Hi all, can anyone help me out?
0: BXM 0 : |3.879G / 3.647Gh/s WU:52.6/m 1: BXM 0 : |3.357G / 4.124Gh/s WU:61.4/m
[2016-01-14 20:22:54] Pool 0 difficulty changed to 1000
You have less than 10GH and are mining at diff 1000. Shares will come very very infrequently. Eventually the pool will adjust your diff down to something suitable for your hardware when it sees a few shares from you. Alternatively you can choose your diff with the --suggest-diff command. Given your total hashrate a diff of about 5 will do so you can add to your config.
|
|
|
Opening poster hasn't posted in a month. No need to keep bumping this thread. If he comes back he can get the thread unlocked or discuss it elsewhere. /locked.
|
|
|
Since there's not much blockage action happening at the moment I thought I'd give you an update about the pools.
Main solo is purring along fine with its extra DDoS protection and is grossly overpowered for the current load but looks set to stay in its current guise.
DE has gained popularity a lot and is about half as popular as the main solo pool. It also is grossly overpowered for any load it sees.
SG is still new and has only a tiny trickle of miners at the moment.
Main solo and De are popular enough and here to stay and are equipped to cope with any amount of mining that anyone decides to throw at them. I can't justify opening any more nodes at this hashrate and relative popularity and it's early stages to know what to make of the SG node so I'll wait a couple of weeks before assessing how popular it is before deciding what to do with it.
|
|
|
Modern mining hardware exhausts the entire 2^32 nonce range in under 1 milisecond, so there will be no clustering of nonces at the bottom any more. What's left up to the miner these days (as opposed to the fixed component chosen by the pool) is a combination of an extranonce of up to 8 more bytes and the regular nonce giving a hell of a lot more room for variability depending on how the mining hardware/software approaches it. Nonce was of historical relevance only in days where it was the only thing altered to look for a block solve or share.
|
|
|
thanks, that sounds good advice. I thought i may add, the rig in question is for mining only, i have another laptop that i use for email, forums, banking, watching you tube etc. So the old Dell will be on for mining and node 24/7 thus leaving my slightly newer machine for everything else. Maybe i can get a raspberry to run the U3. Failing that, i sell the U3 and put the money towards another S3 which has no demands on my old Dell. If anyone has any old hardware they want to donate to my node project, it would be appreciated. I will pay postage.
Take your discussion elsewhere please. This is the thread for solo.ckpool.org
|
|
|
Please stop posting multiple threads asking for opinions on your pool in various places. Or at least close one thread before opening another and post in the correct places.
|
|
|
Can a new thread be opened for the cheerleader squad and just keep this one pool related? Trying to blow through 20 pages of voodoo and chicken wings to find out pool related info gets more and more difficult. I try to keep up and my usual disclaimer, not trying to offend anyone. A good alternative for cheerleading type posts is Twitter. What is was designed for. Maybe use that for the chicken food and celebration tweets and leftovers will be all detailed pool related. Remember, some of us can't get on the forums daily and I would like to keep up to date on things but sometimes I can't because of 20 pages of "we will get this block" or "have some chicken". While it is crazy funny wacky stuff us old guys read slower and can't keep up so fast. If I'm the only one that thinks this way, then stuff me right back down the hole from which I came. Thank you.
How about no? Here's a simple solution for you: Start->Control Panel->Mouse->Wheel->Roll the wheel one notch to scroll: The following number of lines at a time. You don't have to read every post, you know. I think there are way more people who enjoy the fun posts because, well, that's one of the things that makes this pool so fun. How about neither - there is no place for those posts on this forum, but there may be another medium for them While it's been fun for a while, unfortunately posts like "woohoo" and "eat more chicken" don't abide by the forum rules, being low value posts. Even though I'm part of this pool myself, as a moderator I now have complaints about this thread and I have to treat them accordingly. This means that what's considered low value posts will be deleted from now on. Some flexibility will be allowed, but paid sig owners will get no leeway.
|
|
|
Only the redirector was affected by that attack so anyone already mining was unaffected. It should be back online now.
|
|
|
I'd like to point out that the SG node was responsible for the second last block. In addition to it being found there, with the latest node code added to ckpool it was submitted to the local bitcoind on the SG node before the main pool did, further decreasing the chance of a block being orphaned. [2016-01-12 15:44:08.413] Possible block solve diff 170121647413.087646 ! [2016-01-12 15:44:08.603] BLOCK ACCEPTED! [2016-01-12 15:44:08.604] Solved and confirmed block 393021 by bery89.82s3
This is the code kano was waiting on (me writing) before deploying these remote nodes to make it worthwhile to create remote mining locations. We may deploy one more remote location soon. There may also be more updates at the main pool to improve how remote nodes behave.
|
|
|
a few more hours on the rental to chase that elusive 25 shiny coins..... no luck yet - going to grab a chicken sandwich now... Btw, noticed that "sg.ckpool.org" is lagging about x10 compared to the benchmark "sg.kano.is" -- is this normal? Are hosted in the same ISP? PING sg.ckpool.org (139.162.63.5): 56 data bytes 64 bytes from 139.162.63.5: icmp_seq=0 ttl=53 time=41.536 ms 64 bytes from 139.162.63.5: icmp_seq=1 ttl=53 time=34.934 ms 64 bytes from 139.162.63.5: icmp_seq=2 ttl=53 time=37.409 ms 64 bytes from 139.162.63.5: icmp_seq=3 ttl=53 time=37.706 ms 64 bytes from 139.162.63.5: icmp_seq=4 ttl=53 time=36.726 ms 64 bytes from 139.162.63.5: icmp_seq=5 ttl=53 time=35.551 ms 64 bytes from 139.162.63.5: icmp_seq=6 ttl=53 time=36.649 ms 64 bytes from 139.162.63.5: icmp_seq=7 ttl=53 time=37.621 ms ^C --- sg.ckpool.org ping statistics --- 8 packets transmitted, 8 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 34.934/37.266/41.536/1.858 ms
PING sg.kano.is (139.162.5.112): 56 data bytes 64 bytes from 139.162.5.112: icmp_seq=0 ttl=53 time=4.553 ms 64 bytes from 139.162.5.112: icmp_seq=1 ttl=53 time=3.758 ms 64 bytes from 139.162.5.112: icmp_seq=2 ttl=53 time=3.995 ms 64 bytes from 139.162.5.112: icmp_seq=3 ttl=53 time=3.549 ms 64 bytes from 139.162.5.112: icmp_seq=4 ttl=53 time=3.926 ms 64 bytes from 139.162.5.112: icmp_seq=5 ttl=53 time=3.724 ms 64 bytes from 139.162.5.112: icmp_seq=6 ttl=53 time=3.839 ms 64 bytes from 139.162.5.112: icmp_seq=7 ttl=53 time=3.747 ms ^C --- sg.kano.is ping statistics --- 8 packets transmitted, 8 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 3.549/3.886/4.553/0.282 ms That is not the definition of lagging. They're different servers in different data centres (run for different pools even). One happens to be closer to you. Under 40ms is still very low latency.
|
|
|
Hi CK,
I started using rentals to try my luck on solo.CKPool and rig renters indicated to use a difficulty level. But I recalled your previous advise about using difficulty levels and kept it as none or "x" since the stratum & ckdb will take care of everything. .... having said that I tempted to try following renters diff recommendation but I donot to waste those precious rental time... any advise? Thanks
There's no way to adjust difficulty at the pool anyway unless you use a miner that supports --suggest-diff (which cgminer does), though you don't have that kind of control over it from rentals. So it's a moot point as there's nothing you can do about diff with rentals on solo. Solo will cope with whatever you throw at it and do the right thing.
|
|
|
-ck, I posted this in the gekko solo club thread but at Phil's suggestion I'm bringing it here, too. I recall reading about some best ever share bugs a little while ago and am wondering if I experienced another one? My current "best ever" as of this morning is approaching 1M. Hmmm, can someone explain how my best ever share has gone down over the last few hours? Is this a bug of some sort? Worker in question: http://solo.ckpool.org/workers/1JiWuyX94wrCr7JhkAn7x5qNMCEef1KhqX.Jan11mikestangstickNote the time stamps on the posts, I'm not sure what happened but could try to provide any other information if it was helpful. Thanks. I'm not aware of any issue with bestever any more. Was this a bestever on one of the secondary pools - only new best evers are carried over as of yesterday. Are you also sure you were looking at the same worker? I see one with just mikestangstick as the extension that has "bestever": 14155816
|
|
|
Okay sg.ckpool.org up for testing. I'm not using crappy VPS providers any more. Connect to one of: sg.ckpool.org:3333 sg.ckpool.org:443 sg.ckpool.org:80
All stats appear at solo.ckpool.org , do not go looking for stats on the sg server itself So far only two very small miners on sg. However since that part of Asia has only just woken up for good I'm bringing this post forward so others know about it.
|
|
|
|