Haha - totally forgot about Schrodinger's Cat. Am so glad the cat is alive  This image haunts me. Am glad to hear cgminer will work with BFL SC line  Ckolivas and lodcrappo - BAMT and cgminer work so nicely together! My little 7 GPU mining setup has been running reliably for months, even on a weak wifi signal... I just wish I had discovered this genius combination a year or so ago. From 95F to 30F ambient temps, I never have to worry about fan settings, auto-downclocking etc with cgminer. The best part is how it all can be reset with a simple power cycle, by using BAMTs ultra-easy config file. Although cgminer can be re-added to BAMT, it'd be a shame for an updated version of it not to be included in the BAMT image. People should have the option of a future version of cgminer, so they can discover from day 1 of testing that cgminer will have been the correct choice. Lodcrappo, Ckolivas is a non-stop improver, and I'm sure cgminer will continue to have its strengths over other miners in the ASIC era. I'm looking forward to the next BAMT release, where it'll be run on a mix of FPGA and ASIC (and possibly GPUs to heat my garage area ambient temp to above freezing during this transitional time)  ! Thanks. However I'm pretty sure Lodcrappo won't be reading this particular forum thread. |
|
|
|
Ok I see what's wrong here. The expire= parameter with x-roll-ntime is how many seconds after the getwork is sent that the miner is allowed to roll time for... it is NOT how many "seconds of rolling equivalent" they're allowed to add to the timestamp. That should be limited only by what bitcoin would accept, which is a maximum of 7200 seconds.
The spec seems to imply (to me) BOTH the allowed values of the timestamp AND a deadline time for which they will be accepted. As a practical matter, we even accept work with larger timestamp rolls as long as the block being worked on is still current. I suggest you ignore the timestamp entirely so long as it's within 2 hours of the getwork generation since that's how the spec is implemented by mining software and other pools alike. We do. The only thing we check is work age. We measure how old the work we gave you is. If it's stale, we still give you credit if it falls within our 60 second grace period. So PLEASE DO send stale shares to us (but please also refresh your getworks each 60 seconds). If you do both of those, I see no reason why miners on our pool would see anything but 0% stales. Great And cgminer submits stale by default unless it has tried multiple times to submit it and the pool is unresponsive. |
|
|
|
Does anybody know if cgminer will be able to work with the new ASICs? It's the only miner I use in my BAMT setup I know the author of cgminer is working directly with Tom for the bASIC hardware support. Yes, I will be developing for both bASIC and the BFL SC devices. However, BAMT is dropping support for cgminer. See: https://bitcointalk.org/index.php?topic=65915.msg1146320#msg1146320 |
|
|
|
Variable difficulty -has- to adjust upon new work without being opened up to exploitation, regardless of protocol used. It's very simple for a fast miner to withhold higher difficulty shares when it knows that it's going to force a difficulty increase, then submit them for higher credit once the adjustment lands.
Which - if I'm reading the spec right - is quite hard to do with the current protocol. Even if you change the difficulty at the exact same moment as sending out a new work unit, the difficulty change applies to all the previous work units and miners are allowed to continue working on those at the new difficulty unless you invalidate all of them at the same time. Except that if you do that, you're making the miner throw away work they've done without submitting it. There's a mismatch between how the protocol wants you to handle difficulty changes and the way you actually need to handle them to prevent cheating by miners. btcguild is the only stratum pool with variable diff, and it sends out a clean work with every difficulty change meaning all work gets thrown out with each diff change. Even blocks and valid shares at the new diff get thrown out I might add. |
|
|
|
To be fair, I had exactly the same discussion with Eleuthria but I had bigger fish to fry and stopped caring about it. He or slush can come and defend why they think it's ok. |
|
|
|
Since this is the Speculation subforum...   I don't see the point of CoinLab's second half. To me, they started as a bitcoin pool, but wanted to be more than that. Now they have to be more than that to survive, but I can't see how they actually plan on doing that. Actually coinlab was never going to be a bitcoin pool as far as I can tell. I'm guessing the pool was found to be a good stepping stone for people with GPUs to get out of the bitcoin mining scene when it becomes unprofitable. Disclaimer: I work for coinlab but only as a software contractor and have very little knowledge of the goings on in the company. |
|
|
|
Ok I see what's wrong here. The expire= parameter with x-roll-ntime is how many seconds after the getwork is sent that the miner is allowed to roll time for... it is NOT how many "seconds of rolling equivalent" they're allowed to add to the timestamp. That should be limited only by what bitcoin would accept, which is a maximum of 7200 seconds.
The spec seems to imply (to me) BOTH the allowed values of the timestamp AND a deadline time for which they will be accepted. As a practical matter, we even accept work with larger timestamp rolls as long as the block being worked on is still current. I suggest you ignore the timestamp entirely so long as it's within 2 hours of the getwork generation since that's how the spec is implemented by mining software and other pools alike. |
|
|
|
Even people who currently have 50GH do NOT solo mine...
No matter what your hashrate is, solo mining is always a much much bigger gamble than pool mining.
People with 50GH right now spend a lot of money on electricity, so they cannot gamble on solo mining to keep their bills paid. With ASICs, power usage will be much less, and I think we will start to see more gambling on solo mining once they recoup the initial cost in a pool. People are more willing to gamble when the cost is low. Of course, those with 50GH/s currently will probably end up with 1TH/s and still pool mine to pay for their electricity costs. Not really. People with 50GH include people who have 2 minirigs, which is about 2kW. Not much compared to GPU mining, and they still pool mine. |
|
|
|
An update on our LONGPOLL experiment.
Notice that we specify a 60 second expire time in X-Roll-Ntime. That's telling miners that not only can they increment the timestamp 60 times, but also
that they should NOT be submitting this work more than 60 seconds in the future (if they do - they risk getting a stale). I don't know if other pools
have the same kind of strong guarantee of accepting stale work, but we've implemented a "Grace Period" - we will accept even stale work for 60 seconds
after the end of a block - but only if you received the work within the last 60 seconds.
We notice many miners do not update their work frequently. According to the semantics of the X-Roll-Ntime extension, a miner should cease mining
on blocks older than expire seconds old. My aggressive sending of LONGPOLL flushes was my attempt to get miners to update their work each minute. Ok I see what's wrong here. The expire= parameter with x-roll-ntime is how many seconds after the getwork is sent that the miner is allowed to roll time for... it is NOT how many "seconds of rolling equivalent" they're allowed to add to the timestamp. That should be limited only by what bitcoin would accept, which is a maximum of 7200 seconds. |
|
|
|
I've updated cgminer to 2.8.5 on all my 5 rigs (all with win7 x64 and 7950+7970 cards), with --fix-protocol key it seems to be the most stable version i've ever seen.
Without --fix-protocol cgminer sometimes stops if internet connection is broken.
Thanks. Can you at least describe what you mean by "stops"? It's really supposed to reconnect. Unfortunately windows sockets don't quite behave like real unix ones so once again I'm forever adding workarounds for windows. |
|
|
|
report:
OS: win 7 x64 / 2 x HD7950OC , SDK 2.7 , cgminer 2.8.5
driver 12.09 and 12.10 a lot of reject and hardware errors ...
back to driver 12.08 more stable and profitable at the moment
Thanks for that. Typical of AMD to screw up something like 4 out of every 5 driver releases in one way or another. |
|
|
|
That's a very generous donation and I only implemented unwittingly while implementing stratum, but I gladly accept it No problem glad to help out, just not sure what you ment did you implement GBT as well when implementing stratum? No I mean the sticking to an IP. I have not begun to implement GBT as I think it's not as comprehensive a solution as stratum and has some serious weaknesses for pooled mining. I am in discussions with jgarzik to try and improve GBT to make it better and address one of its biggest weaknesses, but really, I'd much rather all the pools just moved to stratum instead. |
|
|
|
|
One of those single devices or equivalent from the various manufacturers is around 50GH. Even people who currently have 50GH do NOT solo mine. At the current difficulty of 3 million it takes over 3 days on average to find a single block. If you're unlucky, you could fuck up and end up not finding a block for up to 10x the difficulty, or 30 days. You may completely utterly miss any window of opportunity to make something extra even at the current difficulty and by then the number of people who have them will skyrocket, probably to 10x the difficulty.
No matter what your hashrate is, solo mining is always a much much bigger gamble than pool mining.
|
|
|
|
I'd love to use P2Pool with my upcoming ASIC miners.
Of course I'm not psyched about configuring it because I suck at software implementation and really just don't like dealing with software.
Anyway, if it's reasonable enough to set up ASIC miners and use P2Pool without penalty, I'll do it.
no problem at all, set ur difficulty to a higher fixed difficulty and thats all https://en.bitcoin.it/wiki/P2PoolDon't forget provision of work, not just difficulty targets, and in fact p2pool still expects diff 1 shares, it just tests them all and ignores most of them. So none of the scaleable solutions have really been implemented yet as far as I can see. |
|
|
|
EDIT:
By sending out a long poll every minute, you are also asking miners to abort the perfectly good work that they are working on. This means more wasted computing cycles compared to other pools which, in turn, means less shares submitted.
This is very true. Extra longpolls are very wasteful. |
|
|
|
edit: again:
so, as it turns out, i have the newer drivers on this rig, which from what i am reading is not optimal for 5 and 6x cards......
Summary: PEBKAC. Please don't blame cgminer upgrades. I don't like spending thousands of hours coding and people thinking it's making things worse for them. |
|
|
|
That may be the most intelligent post I've seen from you yet. |
|
|
|
Certainly this is a real danger with a proxy pool...
but only if the proxy pool is using PPS, otherwise it would harm much. i wonder if anyone already created some patches for miners to do this... Indeed, but they could easily redirect shares to a PPS should they feel malicious. |
|
|
|
|
There is one caveat though: If p2pool sticks to using getwork for communications instead of stratum, it may be rate limiting...
|
|
|
|
there is only one goal where it could be usefull, if a pool owner wants to take down a others pool and only if the others pool is PPS. Prop isnt worth it since u lose too.
Certainly this is a real danger with a proxy pool... |
|
|
|
|
Show Posts
