I'm looking into additional payout options after the server move is complete. I am currently avoiding direct cash (PayPal/Dwolla), but will consider it in the future.
Would there be any interest in being able to request payouts as Gift Cards (most likely Amazon & NewEgg, open to other suggestions).
Topic: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers - page 409. (Read 903217 times)
January 30, 2012, 10:53:31 AM
January 29, 2012, 09:25:47 PM
Will you support BIP16 ?
Due to the impending server switch, I have not been making an official decision on BIP16/17. I will likely side with whatever most of the developers have sided with, which at this time is BIP16 (the only major dissent has been from Luke). But we will see what happens between now and the second week of February when I compile a fresh bitcoind for the new server.
January 29, 2012, 08:32:01 PM
Will you support BIP16 ?
January 27, 2012, 03:15:59 PM
Great pool
I am using it
I am using it
January 26, 2012, 09:36:26 AM
Hall of Fame got a few tweaks last night. Most Shares is now only recent shares (still needs tweaking, is supposed to only show top shares for current BTC difficulty). Blocks found has returned but has been reset. The blocks found now includes NMC blocks.
Server move is still planned but may be delayed another week (so 2nd week of February) due to some personal issues with my day job.
Server move is still planned but may be delayed another week (so 2nd week of February) due to some personal issues with my day job.
January 23, 2012, 11:30:17 PM
After the new servers are ready I will be compiling bitcoind from the latest source which includes P2SH support, unless I can receive a clear reason that doing so would in some way damage bitcoin (from somebody other than Luke).
January 23, 2012, 11:21:18 PM
Eleuthria, do you have any plans to support OP_EVAL, P2SH or EVC?
January 22, 2012, 08:09:50 PM
So, I'm mining away at BTC Guild earning all these Namecoins and I don't have a clue what to do with them. I'm storing them at Cryptoexchange for now. I just want to know if it's possible to spend them like Bitcoin or is exchanging them for BTC the only option at this point?
Namecoins are not a currency, so I'd be surprised if you could find someone selling things for namecoins.
Then why the heck are we mining them? Just because we can?
Sam
Namecoin is a spinoff a bitcoin which attempts to use a blockchain system to store data, with proof of work hashing to ensure the integrity of that chain. It is used as an alternative to DNS and provides the '.bit' top level domain to people with namecoin setup.
The reason we merge mine namecoins is because it does not hurt Bitcoin production, and it is not a currency, which means it is not in any way competing with Bitcoin adoption.
January 22, 2012, 06:39:12 PM
So, I'm mining away at BTC Guild earning all these Namecoins and I don't have a clue what to do with them. I'm storing them at Cryptoexchange for now. I just want to know if it's possible to spend them like Bitcoin or is exchanging them for BTC the only option at this point?
Namecoins are not a currency, so I'd be surprised if you could find someone selling things for namecoins.
Then why the heck are we mining them? Just because we can?
Sam
January 22, 2012, 04:40:11 PM
So, I'm mining away at BTC Guild earning all these Namecoins and I don't have a clue what to do with them. I'm storing them at Cryptoexchange for now. I just want to know if it's possible to spend them like Bitcoin or is exchanging them for BTC the only option at this point?
Namecoins are not a currency, so I'd be surprised if you could find someone selling things for namecoins. If you're not interested in namecoin, the only option is exchanging them for BTC (or holding onto them and speculating on the best time to do so).
I've done a bit more work on the current server, website should be loading a bit faster again, and it may reduce some of the load on the pool at the same time. Hoping to ship out the new servers in the next week and then begin preparing the new server for a seamless transition. I'm still hopeful that when the next move happens the worst you'll see is a handful of invalids (however many your shares miner had queued before the DNS updated).
January 20, 2012, 05:36:07 AM
Is there some reason my worker hash rate has been showing up as half-value the last few hours?
cgminer reports I'm doing 630 MH/s as usual but for a while now on my account page it has been showing half rate - same as only one of my GPUs. Weird. Just wondering if there was some reporting change causing a bug or if only half my shares are being counted.
cgminer reports I'm doing 630 MH/s as usual but for a while now on my account page it has been showing half rate - same as only one of my GPUs. Weird. Just wondering if there was some reporting change causing a bug or if only half my shares are being counted.
January 19, 2012, 08:56:52 PM
Eleuthria:
I had a scantime of 8 secs on all my miners. i changed 1 of my miners to scantime 45 seconds and that improved my efficiency to 60%+
I'm currently monitoring to see whether this affects my stales/invalids in anyway
I had a scantime of 8 secs on all my miners. i changed 1 of my miners to scantime 45 seconds and that improved my efficiency to 60%+
I'm currently monitoring to see whether this affects my stales/invalids in anyway
Why was/is your scantime set so low? Are you not useing Long Polling? You are basically dumping un-solved work and requesting new work every 8 seconds. Not only does this put un-needed work on your network, it does so to your pool's network also.
My scantime is set to 120, I use a pool with merged mining, and I run at 84% E.
The thing is, a couple of months ago when the merged mining started I would get a lot of: "pool does not provide work quick enough" or "pool is not responding quick enough" (smtg like that) message on my GPU's. Lowering the scantime to 8 secs gave a massive reduction of those message and increased the number of Valid shares/min
But reduced my efficiency
In the end it all comes down to your valid shares/min so I left the in-efficiency.
It seems whatever caused this problem has been solved in the last few months for a higher scantime does not affect my valid shares/min anymore and increased my efficiency, so all is well
I probably had to do with Namecoins being at such a relatively low difficulty to BTC, now that it is catching up, you should see far fewer of these "pool does not provide work quick enough" errors.
January 19, 2012, 07:10:45 PM
Eleuthria:
I had a scantime of 8 secs on all my miners. i changed 1 of my miners to scantime 45 seconds and that improved my efficiency to 60%+
I'm currently monitoring to see whether this affects my stales/invalids in anyway
I had a scantime of 8 secs on all my miners. i changed 1 of my miners to scantime 45 seconds and that improved my efficiency to 60%+
I'm currently monitoring to see whether this affects my stales/invalids in anyway
Why was/is your scantime set so low? Are you not useing Long Polling? You are basically dumping un-solved work and requesting new work every 8 seconds. Not only does this put un-needed work on your network, it does so to your pool's network also.
My scantime is set to 120, I use a pool with merged mining, and I run at 84% E.
The thing is, a couple of months ago when the merged mining started I would get a lot of: "pool does not provide work quick enough" or "pool is not responding quick enough" (smtg like that) message on my GPU's. Lowering the scantime to 8 secs gave a massive reduction of those message and increased the number of Valid shares/min
But reduced my efficiency
In the end it all comes down to your valid shares/min so I left the in-efficiency.
It seems whatever caused this problem has been solved in the last few months for a higher scantime does not affect my valid shares/min anymore and increased my efficiency, so all is well
January 19, 2012, 05:45:25 PM
Eleuthria:
I had a scantime of 8 secs on all my miners. i changed 1 of my miners to scantime 45 seconds and that improved my efficiency to 60%+
I'm currently monitoring to see whether this affects my stales/invalids in anyway
I had a scantime of 8 secs on all my miners. i changed 1 of my miners to scantime 45 seconds and that improved my efficiency to 60%+
I'm currently monitoring to see whether this affects my stales/invalids in anyway
Why was/is your scantime set so low? Are you not useing Long Polling? You are basically dumping un-solved work and requesting new work every 8 seconds. Not only does this put un-needed work on your network, it does so to your pool's network also.
My scantime is set to 120, I use a pool with merged mining, and I run at 84% E.
January 19, 2012, 11:41:22 AM
Eleuthria:
I had a scantime of 8 secs on all my miners. i changed 1 of my miners to scantime 45 seconds and that improved my efficiency to 60%+
I'm currently monitoring to see whether this affects my stales/invalids in anyway
I had a scantime of 8 secs on all my miners. i changed 1 of my miners to scantime 45 seconds and that improved my efficiency to 60%+
I'm currently monitoring to see whether this affects my stales/invalids in anyway
January 19, 2012, 09:58:46 AM
Fixed a problem for 12 users - An automatic payout batch wasn't able to execute from the server restart a few days ago. bitcoind was offline when the payout was attempted, and the server was restarted before the cleanup script removed the batch from the payouts table.
I've checked the payout batches for the few periods of downtime earlier this week, and so far this is the only one I've identified. I encourage everybody to make sure I'm not overlooking any unprocessed payouts from the last few days.
I've checked the payout batches for the few periods of downtime earlier this week, and so far this is the only one I've identified. I encourage everybody to make sure I'm not overlooking any unprocessed payouts from the last few days.
January 18, 2012, 01:36:24 PM
LPs aren't that much more frequent these days with merged mining now that NMC difficulty has essentially lined up with BTC difficulty. Scantime is definitely the culprit though. Slower cards will ask for work way earlier than they need to just to keep up to date with the pool.
I think the change I posted above should solve the performance issues in an automated fashion without causing it to false positive legitimate users except in very rare circumstances [which I'm willing to whitelist].
I think the change I posted above should solve the performance issues in an automated fashion without causing it to false positive legitimate users except in very rare circumstances [which I'm willing to whitelist].
January 18, 2012, 01:25:13 PM
Edit: I just restarted cgminer, so we'll see what the efficiency is in a day or so, but less that 50% is quite normal here.
OK, approximately a day later. I doubled the scantime parameter and the efficiency went up to 16%. before that it stayed at ~10%.
I have never seen efficiency levels that low on CGMiner. I can't fathom getting 12%.
What are you people doing on your PCs at the same time as CGMiner? I'm assuming they're not all dedicated PCs, but even on my most "inefficient" machines, I'm looking at 80+%, when they're actively being used.
What are you people doing on your PCs at the same time as CGMiner? I'm assuming they're not all dedicated PCs, but even on my most "inefficient" machines, I'm looking at 80+%, when they're actively being used.
The problem is that cgminer tries to keep the card active, so there is a queue of workitems. On each LP, both active and queued work is discarded. Since any merged mining pool (and apparently especially PoolserverJ with MM) will send an abnormally large amount of LPs, lots of work gets discarded and requested again right away.
There's also the fact that the default scantime is 60s, so every 60s any current work is discarded, if the GPU is too slow.
You can tweak cgminer to be more efficient even with MM and slow GPUs, but that will result in a dramatic increase in stales, so I'm not really eager to do that...
January 18, 2012, 09:20:04 AM
I have never seen efficiency levels that low on CGMiner. I can't fathom getting 12%.
What are you people doing on your PCs at the same time as CGMiner? I'm assuming they're not all dedicated PCs, but even on my most "inefficient" machines, I'm looking at 80+%, when they're actively being used.
What are you people doing on your PCs at the same time as CGMiner? I'm assuming they're not all dedicated PCs, but even on my most "inefficient" machines, I'm looking at 80+%, when they're actively being used.
January 18, 2012, 09:16:42 AM
In light of the reports about how poorly inefficient cgminer is, I'll be tweaking some settings in the new pool software when it launches. Inefficiency will only be one piece of the puzzle, the other will be related to IP addresses.
A normal user would only use one IP to access one worker [there is no reason to use the same worker when connecting from two different locations]. Since some people have dynamic IPs, this will be extended to 3 IPs [1 current IP, 1 "expired" IP, and 1 spare in case you have network issues and change IPs twice in a short time frame].
This restriction should not affect any normal user. If anybody has a special case, I may whitelist them upon request. This change will make it significantly harder for botnets to operate on the pool without using proxies to mask the different IPs. I will still ban inefficient workers, but it will be based not only on efficiency, but also the rate of getwork requests. An inefficient worker asking for a 5 getworks per minute isn't a problem. A botnet would be asking for 100+ per minute.
A normal user would only use one IP to access one worker [there is no reason to use the same worker when connecting from two different locations]. Since some people have dynamic IPs, this will be extended to 3 IPs [1 current IP, 1 "expired" IP, and 1 spare in case you have network issues and change IPs twice in a short time frame].
This restriction should not affect any normal user. If anybody has a special case, I may whitelist them upon request. This change will make it significantly harder for botnets to operate on the pool without using proxies to mask the different IPs. I will still ban inefficient workers, but it will be based not only on efficiency, but also the rate of getwork requests. An inefficient worker asking for a 5 getworks per minute isn't a problem. A botnet would be asking for 100+ per minute.
Jump to: