thanks but i still want to figure this out considering others have had luck solo mining with bitcoin core and guiminer
You didn't read the fundamental component: You cannot mine with guiminer to current bitcoin core any more. It doesn't have code to support the mechanism used to communicate with current bitcoin core to mine. |
|
|
|
|
GUIminer is so old and dead code that it can't even solo mine to the current bitcoin core. Don't waste your time as CPU and GPU mining bitcoin is basically defunct and pointless with no real meaningful way to even try doing it any more.
|
|
|
|
|
Usual pattern: New forum member, announces a service from a site that no one's ever heard of before, asking what people think about it. Scam.
|
|
|
|
Right now, every Slush Pool miner can vote for larger blocksize.
He probably should have clarified that it's a vote for XT, not just a larger blocksize. Probably not. It is what it is, that which WE are voting on with OUR hash. There are, I'd imagine, multiple threads discussing THAT distinction where you'd no doubt be on-topic. With all due respect, I think making it clear that it's XT you're mining for by selecting the alternative ports IS on topic for miners who mine on this pool. EDIT: Respect withdrawn based on your obviously inflammatory response ignoring what the implications of said vote are. It is NOT just a vote for bigger blocks. I'll let others judge for themselves. |
|
|
|
Right now, every Slush Pool miner can vote for larger blocksize.
He probably should have clarified that it's a vote for XT, not just a larger blocksize. |
|
|
|
And do you care what someone who controls reddit and this forum says? I sure don't... But if that is your opinion then I'm it is OK with that...
It's not about us passing judgement about what we believe - that's not under question here. The issue is this is a private run forum where the admin has set rules regarding XT that affect forum administration and moderation which brings up an interesting dilemma - if the forum rules specify that XT is not bitcoin, then if a pool is mining XT then by forum definitions it's become an altcoin pool. (I don't wish to open yet another discussion regarding that decision on this thread, there are millions of them already in meta/). However unless Theymos makes an issue of XT pools specifically I have no intention of applying that technicality to moderation. |
|
|
|
|
This pool is NOT running bitcoin XT, in case you're interested.
|
|
|
|
|
I suspect the bulk of the pools feel the way Kano and I do: We're all in favour of bigger blocks but most of us don't want XT and are not adopting it. We're waiting in the vain hope core dev gets off its arse and increases block size itself.
|
|
|
|
Everything would be fine, if pools simply sent out diff before first job. How hard is it to do that?
Oh wait... maybe the problem is that your own ckpool implementation DOESN'T do that thus doesn't follow stratum specifications.
Are you having fun yet? I guess you really never want this change merged in any form with that attitude. Remember you're the only proxy pool that is affected in any beneficial way due to constantly dropping connections and switching upstream pools and changing diff too often as a result. I guess I'll leave you to talk to Kano instead. |
|
|
|
Finally a responds from a Staff member, and then it is a meme?
Great job, you guys are doing, very professional ...
That's because there are already dozens of threads about this already. See any thread about Theymos censoring XT and so on... |
|
|
|
The cgminer has the "bug": apply the difficulty for current job: so L2 job has 1042 sharediff. this conflict with mining doc. Solutions: - fix the doc: "Applied to Every Next Job" -> "Applied to Every Current Job"
- fix cgminer (with the patch) and fix your pool: send the set_difficulty first and mining.notify next
Since Kano so often is so eloquent with his explanations (heh) I may as well elaborate. The issue is that following the standard destroys the startup of many devices by using diff1 until the next stratum update. Most of the low power controllers (like those in antminer S*) fall over trying to create that many shares and just about every pool would be seriously annoyed to get every miner sending their first 30 or 60 seconds of shares at diff1, especially with 5+ TH miners available. All pools would be affected by this. This is what I meant by the default behaviour of cgminer since stratum was first added is "robust". If you want to add the old/next diff idea back in you need to add a workaround for startup that veers off the standard. Standards are fine and all but real world workarounds for problems with the standard are essential (and a huge part of making cgminer practical solutions for today's mining). |
|
|
|
...bound to be faked. Don't be fooled by bullshit like that, even if you agree with what that person says. |
|
|
|
Hello,
Is there a problem with the stats? My hash-rate is 0 while the machine is fully pointed to the pool.
Thanks.
Nope, everything's working fine. Have you just started mining with a low hashrate device? It can take a while to get any shares and the diff adjust at the pool if you have something under 500GH. |
|
|
|
Thank you.
Do you know which pool software give the ability to point it to other pool?
ckpool in proxy mode can be pointed at another pool or a p2pool node |
|
|
|
|
One thread on this irrelevant tech is enough. /locked
|
|
|
|
Halo everyone,I using Dell R310 server Windows server 2012. When i try to run GUIminer.exe in solo mining, Why it shows nothing to mine on?? pls help me..
You resuscitated a 4 year old post for dead software doing dead mining that no one does today... you cannot mine bitcoin with CPUs or GPUs or guiminer in any meaningful fashion let alone in solo mode. Please do more reading. |
|
|
|
|
Show Posts
