|
You could definitely do a withholding attack, but why on earth would you do it? It doesn't benefit you, you just make the pool poorer that you mine with, and unless you have ultramegahashes to waste, your effect of withholding a block solve will be insignificant to the final outcome. There is nothing suspect about not returning a share from any work gathered from a pool, and a block solve is no different to returning a share. There is no way to check if a miner is returning all the shares it's "supposed to" as there is no such metric. Pools never send the same work item out to two different miners, so they'd have to have some reason to suspect this is the case, so unless you mine with a pool and after 10x difficulty submission of shares you still haven't sent a block solve, then they'd have to start investigating. Even then, bad luck alone is enough for even 10x difficulty and no block solve to occur. So at current difficulty, for example, a pool operator would have to get suspicious only after you had sent 30 million shares without a block solve. That's a heck of a lot of work you're doing just to withhold one block. So unless you personally have something like >1% of the total bitcoin network hashrate, this is a futile exercise.
On the other hand, if you get enough people running the same malicious mining software you could achieve this. But to what end? It doesn't benefit you directly in any way. Luckily all the source code for my mining software (along with most other mining software) is free and open and anyone can audit it to ensure it's not doing this.
|
|
|
|
|
Oh you're scrypt mining. I didn't spot that. Good luck.
|
|
|
|
|
You do not put -n in when you're trying to mine... it's for information only
|
|
|
|
|
None of the current BFL issues will matter with ASICs on p2pool because they will complete a work item so quickly that aborting work will not matter. Unless BFL do something to completely screw up the communication protocol to their ASIC devices, they will work fine with p2pool.
|
|
|
|
From what I have read Stratum wins based on the fact that it's less work and less hardware load for both pools and miners. This is my opinion based on threads I have read. Now anyone have a stratum pool back end they are selling?  ckolivas I am sending you 10.25 BTC for your work on cgminer, I noticed you implemented my request of "sticking to an IP address until it fails" after rejecting it because you thought it was for merge mining. It was my fault I should have pointed out the benefits such as less DNS lookups. Good work keep it up. Davinci That's a very generous donation and I only implemented unwittingly while implementing stratum, but I gladly accept it  |
|
|
|
We can't hold on to shares forever, even with submit stale being the default. I understand that, you 've made that point to plenty of people plenty of times. My concern was with the fact that the pool was marked as down while I received a longpoll. My question is this: "should the pool have been marked up when I received a longpoll from it?" Maybe the answer is no, in which case that share was destined to be discarded, but if the answer is yes, then I would think submission should have been attempted before it expired (or maybe it was, and that's why the pool wasn't marked as up?). Actually the issue is not whether cgminer has even flagged the pool as down or up at all because share submission is done asynchronously and ignores that flag. The issue is cgminer actually tried to submit it, likely numerous times, and it failed repeatedly till it eventually expired. The sign that it has failed to send is when cgminer says "Pool 0 communication failure". After that it keeps trying to submit, it just doesn't spam the logs with every attempt. Often pools get into situations where they can send getworks or longpolls and can't accept shares, or they can accept shares but fail to send longpolls and so on. That's the thing about the getwork protocol versus something like stratum; everything is done separately. |
|
|
|
|
ASIC mining makes you absolutely faster, but relatively the same speed. You'll all be pool mining just like you were before, earning the same amount, only the difficulty will be 50x higher. You're dreaming if you think this magically makes it worth you solo mining.
|
|
|
|
I rarely look at cgminer running, but last time I looked, I saw this: [2012-10-24 12:04:00] Pool 0 communication failure, caching submissions
[2012-10-24 12:04:03] LONGPOLL from pool 0 detected new block
[2012-10-24 12:04:05] Share became stale while retrying submit, discarding
[2012-10-24 12:04:05] Pool 0 communication resumed, submitting work This was witnessed in 2.8.5; I actually saw it twice within 15 minutes (the second time there wasn't a share discarded in the few seconds after the longpoll). The pool isn't great on connectivity, so the communication failures don't surprise me, especially just before a longpoll, however, I am curious as to whether or not cgminer should have said "oh, communication is working now" when it got the longpoll instead of waiting a second or two to check/determine communication was restored. Obviously the share that was discarded would have been rejected anyway, I only ask because I wonder if there might be something missing/inefficient in the communication failure code. We can't hold on to shares forever, even with submit stale being the default. Imagine a scenario where the pool keeps sending work but the server is borked in a way it won't accept work. Cgminer could get a backlog of work so large that it crashes due to running out of memory. So cgminer keeps trying to resubmit the shares only until it reaches the expired work criteria. However, if cgminer thinks it has found a block, it will hold onto it until it successfully submits it no matter how long it takes. Either way, a reliable pool is the most important variable here. |
|
|
|
This night, crashed and ... cgminer restarted!!! (windows xp). fine.
Thanks! it works for me.
 Shame I didn't fix the actual crashes in the first place  Still, there is a workable solution till someone can debug windows |
|
|
|
Did you try Cgminer 2.8.5?
Also if the driver crashed, I doubt it is Cgminer's fault. Probably AMD's crappy drivers.
cgminer works the cards pretty hard. I don't recall having the problem until I upgraded to 2.8.4. I'll try 2.8.5 this weekend when I'm around to babysit it. I don't want it crashing again while I'm at my day job. M 2.7.6 died as well. *however* it tell me the GPU was sick and was trying to restart. alas, it failed on restarting. 2.8.4 never told me that. I'm assuming I have something else going wrong that's causing this. Not sure what yet. M Still, a hardware failure is a hardware failure. Time to reassess your clocks, cooling, power or whatever else. |
|
|
|
How can we be sure that all that nice computational power will not be used for malicious purpose. Maybe not from you, but suppose that you rent that power to someone, how can you know what it will serve for ? This could be use like a giant password craking tool !
just wondering
Since when is password cracking malicious anyway ? ... It's surely not in Bitcoin land. Fine, I can agree for many reason, but what if my wallet.dat got stolen, even with a pretty long and complex password, such power could crack it in a manner of minutes :S True ? Nope. If you have 8 or more characters in your password and it's not an obvious dictionary word, it can be extremely hard to crack and becomes exponentially more with each extra character. If you look at the vanity gen software, generating a word with 8 characters can take months with current machines that can do 2GH. If you have a password with something like 20 characters, then unless your software has a flawed encryption mechanism, the only weakness is you telling someone the password. |
|
|
|
Regarding Stratum Rejected shares:
If you have any network reliability issues you will get rejects due to that.
Reconnects always lose you shares.
Of course a difficulty change loses you shares too - which may happen soon after a reconnect.
In general I find I get about 54% of the Rejects per LP "(stale)" compared to Getwork.
That's a drop from about 0.35% to about 0.19%
These sort of Reject messages really suck also:
[2012-10-24 00:06:07] Rejected 216df95a Diff 7/1 GPU 0 pool 2 (olddifficulty)
[2012-10-24 00:06:08] Rejected 5af4e74e Diff 2/1 GPU 0 pool 2 (olddifficulty)
That's interesting and a good point about reconnects. Your rejects went down when you moved to stratum which is the desired effect. With getwork, you are forever grabbing new connections and are allowed to continue working on previous work. However once you have to reconnect with stratum, all your old work is now redundant. So lots of disconnects would be expensive with stratum. |
|
|
|
I notice that i am getting many more rejected shares now that im using 2.8.4 compared to 2.7.5. I usualy get about 10 rejected shares per 20 000 accepted shares. Now with 2.8.4 ive gotten 200
Nothing's changed in management therein, so I can only assume it's coincidence and pool related. I immediately stopped the 2.8.4 and restarted 2.7.5 and i have no stale shares at all yet. Soemthing is definetly up Did you move to stratum with 2.8.4? EDIT: To explain why I ask that, cgminer + stratum gets notification of block changes much faster than ever so it should reduce the number of stales. On the other hand, I have noticed that slush uses that as an excuse to ignore any shares that are returned from the previous block immediately once it has stratum notified you of the new block saying job not recognised, so to me it looks like stales on slush went up, not down, despite the potential advantages. I'm not sure how btcguild fares there. I signed on 2.8.4 like this http://btcguild.com:9332username whatever password whatever Yes that will be switching to stratum on startup. For a more objective test, try the latest 2.8.5, run for a while with your regular login details above (that will automatically switch to stratum) and then try running 2.8.5 again but this time add --fix-protocol to your startup. I'm wondering if users are losing out due to the way pools are implementing this and being very restrictive about how and when to accept stales. |
|
|
|
I'm still using 2.8.4. Yesterday I'd swear it restarted itself. I manually removed all the pools I didn't want using the P command, but they were still in the config file. A few hours later I noticed my p2pool activity had dropped to zero again, so I checked it. cgminer was mining away to a pool that wasn't supposed to be there, and a pool I'd added manually was no longer there! I'm 99% positive I didn't restart it, and I don't have any scripts that would restart it if it crashed. After that I edited the config file to put it the way I wanted...
There is only one occasion where cgminer restarts itself prior to version 2.8.5: That is when the fanspeed monitoring fails on windows. It used to be the bane of my existence quite a few versions ago where people would either lose their fanspeed monitoring or cgminer would crash. Now it sneakily restarts itself if the ATI driver's fanspeed monitoring stops working so it can get it going again. |
|
|
|
Yes, we certainly are. And so should everyone in the ASIC business, including Intel. If BFL's numbers are to be believed, our assertion is that they have discovered new manufacturing processes that are vastly more efficient than anything the semiconductor industry has seen before.
i hope BFL will continue to invest in these technologies, i love hardware hackers and maybe one day there will be BFL CPUs BFL CPUs? Yep, they're only 4-6 weeks away. |
|
|
|
|
With the new stratum mining protocol and variable difficulty targets, the network bandwidth will be about 1K/minute regardless of your hashrate.
|
|
|
|
|
New version: 2.8.5, 23rd October 2012
Minor bugfix version.
Human readable changelog
More minor stratum fixes hopefully addressing some of the remaining windows crashes. No debugging has been able to capture their actual cause as of yet.
cgminer now tries to actually catch crashes and unless the --no-restart option is given, it will try to restart cleanly. Yes this is a desperate but hopefully quite useful thing to do.
A small delay is added between queues when the network is out to prevent the huge sudden spikes in queued values.
It was possible to run out of work if a stratum pool was going down often and cgminer was resorting to a regular getwork pool.
Build fixes for mingw builds on windows.
Stratum information now in the API.
Full changelog
- Handle crash exceptions by trying to restart cgminer unless the --no-restart
option is used.
- Switch queued count when choosing a different pool from a failed stratum pool
in getwork thread.
- Put a mandatory 5s wait between reattempting a getwork on failure to avoid
hammering requests.
- The ATI stream / AMD APP SDK environment variables appear to only interfere
with win32 builds so bypass them.
- Make sure to check pool stratum curl exists under lock before attempting any
recv to not risk dereferencing upon attempting to reinitiate stratum.
- Avoid redefining macros and align to 4 byte boundaries.
- API - add Stratum information to pools
- update FPGA-README for MMQ
|
|
|
|
User switching on windows does mystical voodoo the adl library doesn't like.
It is impossible to catch that somehow? Some watchdog on ADL thread to detect and fix when it happen? ADL thingy is good to disable mining when it is overheating. It is my desktop pc, so i need to switch user to allow my kids play on theirs accounts... Alas not that I'm aware of. |
|
|
|
|
User switching on windows does mystical voodoo the adl library doesn't like.
|
|
|
|
|
Show Posts
