Just flipped back to the old software after encountering a crash on the server end.
HellDriverUK: That still makes no sense that you're submitting a few shares and it quits. It's not like the servers send different information after a few shares. I need pastebin log files to have any chance at figuring out what is going wrong on your end.
Topic: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers - page 145. (Read 903163 times)
January 20, 2014, 04:07:13 PM
January 20, 2014, 04:03:33 PM
Trying to get a working version of cgminer 3.10 working, but since cgminer likes to fuck with drivers and make itself incompatible with bfgminer it's taking a long time. I'm not seeing anybody else complaining about a similar issue though...I'm still thinking it's a config problem.
Absolutely nothing has changed on the validation server in the last week. Any connection attempts have been connecting to the validation server all week. Additionally, the communication between the server and client is identical to what it used to be.
No problems, just reporting a possible issue. I'm chasing the issue over on the cgminer thread as well. If I'm any the wiser I'll come back to you, but I thought I'd forewarn in case somethings up.
It's mining away like a champ on Eligius, as soon as I flip to BTCGuild it takes a few shares then quits. If I change priority to BTCGuild and start cgminer it just quits at startup.
January 20, 2014, 03:59:19 PM
Anyone else noticing cgminer 3.10.0 crashing when connecting to BTCGuild? Runs fine on Eligius and p2pool, but as soon as it connects to Guild it just quits.
It's self-compiled on Debian, running 2x Nanofury and 1x Bitburner Fury.
It's self-compiled on Debian, running 2x Nanofury and 1x Bitburner Fury.
My guess is you messed up your argument on the worker name/port or something similar. Works fine on bfgminer 3.9 and 3.10 here.
It gets a few shares then craps out. cgminer.conf hasn't changed in....oh...about 3 months. It's CGminer, not bfgminer, too (only using cg because bfg doesn't support the Bitburner). So, I think your guess is wrong.
I'm pointing out the issue in case it's something with the new servers? Nothing's changed here.
Try -S AVA:/path/to/btb
If I remember even the btb fury uses Avalon emulation
Only thing would be no support for btb voltage adjustment
January 20, 2014, 03:53:48 PM
Anyone else noticing cgminer 3.10.0 crashing when connecting to BTCGuild? Runs fine on Eligius and p2pool, but as soon as it connects to Guild it just quits.
It's self-compiled on Debian, running 2x Nanofury and 1x Bitburner Fury.
It's self-compiled on Debian, running 2x Nanofury and 1x Bitburner Fury.
My guess is you messed up your argument on the worker name/port or something similar. Works fine on bfgminer 3.9 and 3.10 here.
It gets a few shares then craps out. cgminer.conf hasn't changed in....oh...about 3 months. It's CGminer, not bfgminer, too (only using cg because bfg doesn't support the Bitburner). So, I think your guess is wrong.
I'm pointing out the issue in case it's something with the new servers? Nothing's changed here.
Trying to get a working version of cgminer 3.10 working, but since cgminer likes to fuck with drivers and make itself incompatible with bfgminer it's taking a long time. I'm not seeing anybody else complaining about a similar issue though...I'm still thinking it's a config problem.
Absolutely nothing has changed on the validation server in the last week. Any connection attempts have been connecting to the validation server all week. Additionally, the communication between the server and client is identical to what it used to be.
January 20, 2014, 03:32:44 PM
Anyone else noticing cgminer 3.10.0 crashing when connecting to BTCGuild? Runs fine on Eligius and p2pool, but as soon as it connects to Guild it just quits.
It's self-compiled on Debian, running 2x Nanofury and 1x Bitburner Fury.
It's self-compiled on Debian, running 2x Nanofury and 1x Bitburner Fury.
My guess is you messed up your argument on the worker name/port or something similar. Works fine on bfgminer 3.9 and 3.10 here.
It gets a few shares then craps out. cgminer.conf hasn't changed in....oh...about 3 months. It's CGminer, not bfgminer, too (only using cg because bfg doesn't support the Bitburner). So, I think your guess is wrong.
I'm pointing out the issue in case it's something with the new servers? Nothing's changed here.
January 20, 2014, 03:27:49 PM
Anyone else noticing cgminer 3.10.0 crashing when connecting to BTCGuild? Runs fine on Eligius and p2pool, but as soon as it connects to Guild it just quits.
It's self-compiled on Debian, running 2x Nanofury and 1x Bitburner Fury.
It's self-compiled on Debian, running 2x Nanofury and 1x Bitburner Fury.
My guess is you messed up your argument on the worker name/port or something similar. Works fine on bfgminer 3.9 and 3.10 here.
January 20, 2014, 03:22:33 PM
Anyone else noticing cgminer 3.10.0 crashing when connecting to BTCGuild? Runs fine on Eligius and p2pool, but as soon as it connects to Guild it just quits.
It's self-compiled on Debian, running 2x Nanofury and 1x Bitburner Fury.
It's self-compiled on Debian, running 2x Nanofury and 1x Bitburner Fury.
Could it be related to eleutheria's post right above yours?
January 20, 2014, 03:22:20 PM
Anyone else noticing cgminer 3.10.0 crashing when connecting to BTCGuild? Runs fine on Eligius and p2pool, but as soon as it connects to Guild it just quits.
It's self-compiled on Debian, running 2x Nanofury and 1x Bitburner Fury.
It's self-compiled on Debian, running 2x Nanofury and 1x Bitburner Fury.
do you mean BFGMiner?
January 20, 2014, 03:16:36 PM
Anyone else noticing cgminer 3.10.0 crashing when connecting to BTCGuild? Runs fine on Eligius and p2pool, but as soon as it connects to Guild it just quits.
It's self-compiled on Debian, running 2x Nanofury and 1x Bitburner Fury.
It's self-compiled on Debian, running 2x Nanofury and 1x Bitburner Fury.
January 20, 2014, 03:00:53 PM
At 4:27 AM this morning, the validation server finally froze up (this is a good thing). I copied the log files out and restarted it just a few minutes later.
Now I've had a chance to go through the logs to find out exactly what was happening inside the server at the time of the freeze, and I believe I've got a workaround implemented. Two of the public backend servers have been restarted with the new code with the workaround implemented. Sorry to the users that experienced a disconnect when the swap happened.
Now I've had a chance to go through the logs to find out exactly what was happening inside the server at the time of the freeze, and I believe I've got a workaround implemented. Two of the public backend servers have been restarted with the new code with the workaround implemented. Sorry to the users that experienced a disconnect when the swap happened.
January 20, 2014, 01:51:19 AM
Just wanted to thank the forum-goers today. This outage lasted a lot longer than I would've liked (well, hard to have any outage that is shorter than 0 minutes), and lasted longer than my original projections due to just how long the resync took.
However, for the first time in quite a while, the thread remained clear of useless posts, no demands, no crying foul. Even my email inbox was *mostly* empty during this event. The ability to concentrate solely on the task at hand (and providing updates) really made it easier to focus than having to pull double-duty as public relations.
My cat licked his fur today.However, for the first time in quite a while, the thread remained clear of useless posts, no demands, no crying foul. Even my email inbox was *mostly* empty during this event. The ability to concentrate solely on the task at hand (and providing updates) really made it easier to focus than having to pull double-duty as public relations.
;-p
January 20, 2014, 01:13:21 AM
Just wanted to thank the forum-goers today. This outage lasted a lot longer than I would've liked (well, hard to have any outage that is shorter than 0 minutes), and lasted longer than my original projections due to just how long the resync took.
However, for the first time in quite a while, the thread remained clear of useless posts, no demands, no crying foul. Even my email inbox was *mostly* empty during this event. The ability to concentrate solely on the task at hand (and providing updates) really made it easier to focus than having to pull double-duty as public relations.
However, for the first time in quite a while, the thread remained clear of useless posts, no demands, no crying foul. Even my email inbox was *mostly* empty during this event. The ability to concentrate solely on the task at hand (and providing updates) really made it easier to focus than having to pull double-duty as public relations.
January 19, 2014, 10:37:20 PM
somebody get this man an e-beer stat
January 19, 2014, 09:40:37 PM
All of the pending manual payouts have now been processed. A few more manually triggered automatic payouts will happen over the next 1-2 hours in order to catch up with the backlog of accounts that have reached the threshold.
January 19, 2014, 09:00:18 PM
New payout server is finally synchronized with the blockchain. Doing a few checks and then I'll start letting the payouts flow.
UPDATE #1 (6:02 PM): New payout server is properly reporting blocks to the website and recording/paying them.
UPDATE #2 (6:04 PM): First batch of small payouts (< 0.10 auto payouts) has been successfully sent and recorded.
UPDATE #3 (6:25 PM): 5 batches of small auto payouts sent, two batches of large (>= 0.10) auto payouts now sent.
Taking it slow to prevent something that has happened in the past, where payouts were using the unconfirmed outputs of other payouts, causing a severe delay in how fast payments were getting confirmations.
UPDATE #1 (6:02 PM): New payout server is properly reporting blocks to the website and recording/paying them.
UPDATE #2 (6:04 PM): First batch of small payouts (< 0.10 auto payouts) has been successfully sent and recorded.
UPDATE #3 (6:25 PM): 5 batches of small auto payouts sent, two batches of large (>= 0.10) auto payouts now sent.
Taking it slow to prevent something that has happened in the past, where payouts were using the unconfirmed outputs of other payouts, causing a severe delay in how fast payments were getting confirmations.
January 19, 2014, 08:51:17 PM
Quote
An 8 hour lapse of time (like for example, sleeping) with somebody else with any access to core functionality is literally a million dollar or greater liability.
So.. basically you've become the worlds first BTC Monk?
January 19, 2014, 07:13:55 PM
I didn't update the little "New News" counter, but the pause was extended to 01:00 GMT. I think it will be ready by then. Old server is at block 266k, new server at 237k. I think at least one of them should be caught up before the hour is up.
UPDATE: I think I should've gone outside to watch some grass grow. This process gets exponentially slower the closer it gets. New server is only 2k blocks behind the old one now, ~9000 blocks behind the live blockchain. I've got the debug.log file scrolling on half my screen so I can start processing payouts the moment it finally catches up.
UPDATE: I think I should've gone outside to watch some grass grow. This process gets exponentially slower the closer it gets. New server is only 2k blocks behind the old one now, ~9000 blocks behind the live blockchain. I've got the debug.log file scrolling on half my screen so I can start processing payouts the moment it finally catches up.
January 19, 2014, 06:54:09 PM
...
In the meantime, I'm continuing to watch blockchain.info and add block solves manually so rewards are applied to their proper shifts as blocks are solved.
In the meantime, I'm continuing to watch blockchain.info and add block solves manually so rewards are applied to their proper shifts as blocks are solved.
So are blocks 281384 (1 hour ago) and 281389 (20 minutes ago) on blockchain.info really ours and are they having to be added manually since they haven't posted yet in our block rewards??
I was adding those as I wrote that response, they should be showing already.
Yes they are. Thanks!!!
January 19, 2014, 06:40:20 PM
...
In the meantime, I'm continuing to watch blockchain.info and add block solves manually so rewards are applied to their proper shifts as blocks are solved.
In the meantime, I'm continuing to watch blockchain.info and add block solves manually so rewards are applied to their proper shifts as blocks are solved.
So are blocks 281384 (1 hour ago) and 281389 (20 minutes ago) on blockchain.info really ours and are they having to be added manually since they haven't posted yet in our block rewards??
I was adding those as I wrote that response, they should be showing already.
January 19, 2014, 06:36:57 PM
...
In the meantime, I'm continuing to watch blockchain.info and add block solves manually so rewards are applied to their proper shifts as blocks are solved.
In the meantime, I'm continuing to watch blockchain.info and add block solves manually so rewards are applied to their proper shifts as blocks are solved.
So are blocks 281384 (1 hour ago) and 281389 (20 minutes ago) on blockchain.info really ours and are they having to be added manually since they haven't posted yet in our block rewards??
Jump to: