All three of my miners on cgminer are complaining that bitminter isn't providing work fast enough. Stratum is coming soon, right?  "Isn't providing work fast enough" (even with BFGMiner) is most likely a problem with your miner, not the protocol. Con intentionally designed GBT support in cgminer to work inefficiently, but as a side-effect of this particular inefficiency, there is no excuse it should ever be starving for more work. |
|
|
|
It is also a good idea to register your nick with nickserv, and turn on nick protection (set enforce), so that others can't use your irc nick when you're not around. Whoever runs this wiki (registration is not open to the public) needs to either remove that line entirely or make it 100% explicitly required to register and enforce. Wayyyyyyyyy to many people pissed off about this. Why? It's perfectly correct. It is a good idea to register and set enforce. But it isn't an obligation, that would be overstepping. |
|
|
|
Seems like a clear abuse of the system. Whoever runs WOT should probably purge the user and all his database entries from the DB. Unfortunately, nanotube's policy is to simply ignore bogus/shill accounts and ratings, and none are ever removed. Since OTC has a "gettrust" command that weighs ratings based on how much people you trust have rated someone, that is supposed to solve it in theory. techmrw appears to be a real person, and only downrated people when they were actually being squatted (at least, I can't disprove this), so he only has a -1 from me. That -1 is mainly because his ratings demand* the squatter user enable the NickServ ENFORCE setting to get the downrating lifted. I also think he should be either automatically or on request removing these downratings after a squatter has left for some time, but given his explanation as to why he does not, I'm okay with him leaving them up until the user has auth'd to gribble. * He claims it isn't a demand, but it clearly reads like one. Users have a right to choose if they want to enable the ENFORCE setting, so this is unreasonable. Furthermore, considering his description of how the squatters in question are operating, ENFORCE would have absolutely no effect to deter them. Also, there are numerous reasons why a user would legitimately not want to set ENFORCE. |
|
|
|
GBT replaced X-Mining-Hashrate with the "target" request option (BIP 23 Basic Pool Extensions). Stratum has no equivalent (and no HTTP for headers) yet. I didn't implement the target request option yet. I don't know if I would use it for anything but the first minute either. Letting a user with 10+ TH/s set the difficulty makes me a bit uneasy.  Well, you could always set it up to honour it within some reasonable limits (or maybe leave it unbound upward, so miners can always opt to increase their variance at will). Admittedly, I also haven't seen a need to implement "target" requests yet either. |
|
|
|
If everything runs perfectly I could perhaps enable Stratum and GBT with var diff on the main pool before the weekend is over. But perhaps delay var diff on getwork a bit longer until hashpower.com supports it.
My only other concern with vardiff is that when you enabled it on the main pool, it was done per worker. Does vardiff now work by used the x-mining-hashrate header if available? GBT replaced X-Mining-Hashrate with the "target" request option (BIP 23 Basic Pool Extensions). Stratum has no equivalent (and no HTTP for headers) yet. |
|
|
|
Does bug at (2) exists or not I can't tell. I just wanted to know how miner should work. I tried "deciphering" stuff posted on screen by
miner when enabling debug and RPC debug but I can't really tell what's going on with nonce since data comes to screen way too fast,
even with window set to 80 chars x 80 lines. Even when I focus enough to filter-out everything but value for nonce, I'm not sure it is
what it should be, LOL! I think bug at (2) doesn't exist since BFGMiner will roll time as possible (and it always is with bitcoind). There is a problem I have with newer versions of both BFGMiner and CGMiner, those that show best share difficulty = on way too many occassions, it happened that value shown was higher than current network difficulty but absolutely nothing happened, e.g. share was neither accepted (it should solve block), nor rejected, nor some other message was shown (solo mining Terracoin, in case you wonder, so it's scenario like "network difficulty 731 and my best share 755"). Miner version 2.8.3 does not seems to be having the issue. It costs me hours to detect the issue, so don't ask me to check with 2.8.6 or some other version. I've lost way too many TRC already! You mean the block is actually being lost? That's not good :/ Can you open a github issue for this? |
|
|
|
Make on Linux (Xubuntu) does not work without libminiupnpc8-dev installed. You mean with USE_UPNP=- (don't compile support)? Its set to USE_UPNP=- in line 41 of makefile.unix . No, it's set by default to USE_UPNP=0 (compile support, but disable by default) on line 5, and changed from (null) to - on line 41. So eg, USE_UPNP= will work also (but there is no way to support this syntax with -Qt) The problem is that the README states that libminiupnpc is optional but make -f makefile.unix doesnt work without it, so maybe the default setting should be USE_UPNP=-. But probably its not that important. And immediately under the dependency list: miniupnpc may be used for UPnP port mapping. It can be downloaded from
http://miniupnp.tuxfamily.org/files/. UPnP support is compiled in and
turned off by default. Set USE_UPNP to a different value to control this:
USE_UPNP=- No UPnP support - miniupnp not required
USE_UPNP=0 (the default) UPnP support turned off by default at runtime
USE_UPNP=1 UPnP support turned on by default at runtime This isn't something new either, it's been this way since 0.4 |
|
|
|
Make on Linux (Xubuntu) does not work without libminiupnpc8-dev installed. You mean with USE_UPNP=- (don't compile support)? Its set to USE_UPNP=- in line 41 of makefile.unix . No, it's set by default to USE_UPNP=0 (compile support, but disable by default) on line 5, and changed from (null) to - on line 41. So eg, USE_UPNP= will work also (but there is no way to support this syntax with -Qt) |
|
|
|
Make on Linux (Xubuntu) does not work without libminiupnpc8-dev installed. You mean with USE_UPNP=- (don't compile support)? |
|
|
|
1. Scantime defines upper boundary for scanning current work. Once GW gets data from pool, miner starts working on it for duration of scantime or until new block is announced by some pool. What happens is pool, especially local server (solo mining), accepts transactions after GW is complete? Does it informs miner about the change? What happens if miner finds valid hash for work which does not include mentioned transactions accepted by local server? Does valid hash becomes stale, e.g. upon miner submitting it to local server, hash is rejected? What are the negative consequences of using 30 seconds or less for scantime, and what becomes improved by reducing time? When you're talking about localhost, you probably want to set scantime as low as possible to get the best benefit for the Bitcoin network. Pool mining is different, and usually the pool tells you how long to work on the job. 2. If there was no data change on pool since last GW, e.g. new GW gets same data as previous one, does it mean miner will start over or it will continue where it stopped (nonce), e.g. ignore data received by new GW? Actually, this might very well be a bug.  3. Queuing less data than default (1) results in less stales and destroyed works, but it results in more requests per time sent to pool? There is no harm to higher or lower scantime, so long as your bitcoind supports long polling to notify of new blocks. As of 0.7.1, it doesn't. More requests to localhost shouldn't hurt, except for the possible bug in (2). 4. Why miner does not switch to new block as soon as local server detects it? I'm solo mining without LP and looking at "Current number of blocks", which goes up at certain moment but miner does not changes block it's working on for < or = scantime seconds. Does it mean all those seconds miner is actualy working on previous block, which would result in hash becoming rejected if submitted? If your bitcoind doesn't support long polling, yes. In short = if I'm mining solo without LP and want to reduce number of stales (rejected), should I set queue=0 and scantime=few seconds? In theory, yes. If the bug in (2) exists, it's a tradeoff. |
|
|
|
With the clarifications from slush, I've fixed 2 bugs in eloipool's stratum server: - clean_jobs is now sent true when previous jobs are immediately invalid
- idle job updates occur every 55 seconds instead of 96 (stratum expects a 60 second grace window on old jobs)
This should get things working in the new block case of cgminer, but the fact that cgminer was still working on an old job after 24 seconds (at 800+ Mh/s) means it isn't switching to the new job when giving devices more work right away, so there's still a (cgminer) bug there (althrough the reduced 55 second update period will likely avoid that being as common). Note that these changes won't affect EMC until Inaba updates it there. |
|
|
|
How do pools say "previous job remain valid for N more seconds"? Is there any use case for this feature? Except pools which "pay for stales" (=pay bad miners on behalf good ones). Um, yes? So you don't need to keep around old jobs indefinitely... This was an important fix added to getwork longpolling Is there any pool actually using it? As we're primary talking about bitcoin mining, there's no motivation to work with stale shares on pool side... Motivation: Don't lie to miners about their stale rate. |
|
|
|
Stratum jobs can be used infinitely, until the block is invalid or the pool expires the job. Unlike getwork, there is no 232 nonce limit.
True. But there is a limit to ntime. If a pool were to hash a stratum job ad nauseam and finally solve it, and then submit it, it would be rejected based on ntime (being some large time into the future). Stratum doesn't roll ntime and thus depends on the pool pushing new work requests. Well, if you can't roll ntime (sounds like a major flaw to me), you'd just keep using the same one until you found the block. So if anything, it'd be too old. But Bitcoin itself doesn't care what ntime is as long as it is greater than or equal to the median of the last 10 blocks - in other words, the ntime the pool gives you the first time for each new block remains valid. Perhaps slush could clarify the current meaning I don't understand what is unclear here. a) clean_jobs=False means that previous jobs are still valid. b) clean_jobs=True means that previous jobs become invalid. c) If new work is received, miner automatically should use this job. There's no reason why to add a new flag to specify this, it is "by default". However miners can do whatever they want, because with or without a special flag, previous jobs are still valid. KISS, please. Ok, so that seems to agree with conman's interpretation somewhat. How do pools say "previous job remain valid for N more seconds"? It's unreasonable to expect pools to accept shares on previous jobs indefinitely, and also harmful to miners to discard shares across the change-over period. In short, there seems to be no possible way to implement the 2 minute expiration over stratum... How do pools say "previous jobs shouldn't be used, but please submit them anyway"? This was an important fix added to getwork longpolling to correct pool-side statistics as well as avoid losing merged mining shares in some cases. I've read a certain number of posts from Kano speaking of these problems with Stratum now. Kano's problem is just one of many... If I believe Kano, Sounds like a pretty bad idea. (because GBT has too much stales) This is either a myth or a cgminer bug. |
|
|
|
ok so
96+ 23 = 119
114.8+5.2=119
Was my point. Maybe it's the maths... You're not supposed to stop at 5.2 seconds. Stratum jobs can be used infinitely, until the block is invalid or the pool expires the job. Unlike getwork, there is no 2 32 nonce limit. This left me wondering why you said 120 seconds to start with and only had math to make 119. Possibly to account for round trip delays or the share validation. You didn't really say. So either your math was off, or you left out part of your math. I subtracted a second for the time between the pool sending the job and you receiving it. P.S. Kano is simply a liar, as usual. |
|
|
|
Throwing out work with every notify message on stratum, which comes on average every 30 seconds, would have the same effect as a longpoll every 30 seconds. That's a lot of work to discard midstream. Why on earth would there even be a clean_work method with stratum if every notify implied we throw out the work? You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares). So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough? That sounds highly unlikely, and unrelated. What kind of a reject? Top post on the page you are asking on. LOOK UP! Ok, I missed that somehow. "unknown-work" can only occur if one of these 3 cases: - a block was found (which you ruled out)
- the miner submitted it after it expired (120 seconds on EMC; new work is delivered at least every 96 seconds)
- the user extranonce1 was lost (only possible if you reconnected)
I'm pretty sure cgminer discards all work/shares in the last case (reconnection), so that means it either: - was working on a job 23 seconds after it had been replaced (this is sufficient for as low as 200 Mh/s)
- was working on a job 21 seconds after it had been replaced AND took over 2 seconds to submit it to the pool
This makes sense, since cgminer is failing to move on to new jobs as they come in. So a BFL single running 864mhash bitstream in your example would need to work on the work for 114.8 seconds to go over. Interesting to know. No, that 21-23 seconds is real time. No matter what hashrate. 200 Mh/s is the hashrate where if you are any slower, you might still be working on the old work normally. |
|
|
|
Throwing out work with every notify message on stratum, which comes on average every 30 seconds, would have the same effect as a longpoll every 30 seconds. That's a lot of work to discard midstream. Why on earth would there even be a clean_work method with stratum if every notify implied we throw out the work? You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares). So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough? That sounds highly unlikely, and unrelated. What kind of a reject? Top post on the page you are asking on. LOOK UP! Ok, I missed that somehow. "unknown-work" can only occur if one of these 3 cases: - a block was found (which you ruled out)
- the miner submitted it after it expired (120 seconds on EMC; new work is delivered at least every 96 seconds)
- the user extranonce1 was lost (only possible if you reconnected)
I'm pretty sure cgminer discards all work/shares in the last case (reconnection), so that means it either: - was working on a job 23 seconds after it had been replaced (this is sufficient for as low as 200 Mh/s)
- was working on a job 21 seconds after it had been replaced AND took over 2 seconds to submit it to the pool
This makes sense, since cgminer is failing to move on to new jobs as they come in. |
|
|
|
Throwing out work with every notify message on stratum, which comes on average every 30 seconds, would have the same effect as a longpoll every 30 seconds. That's a lot of work to discard midstream. Why on earth would there even be a clean_work method with stratum if every notify implied we throw out the work? You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares). So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough? That sounds highly unlikely, and unrelated. What kind of a reject? |
|
|
|
let user select wallet file with -wallet=foo.dat gmaxwell commented 2 months ago
Eh. The functionality is desirable, but the ability to filesystem split the wallet and data dir is a surefire way to end up with a corrupted wallet. This is subtle and I suspect hard to warn people out of doing, esp since it would mostly work. (until it eats your keys for lunch).
Whats the problem with using multiple wallet files with the same bitcoin client? Ok you could miss recieved coins if you update the blockchain when there is the wrong wallet loaded, but if you make sure that doesnt happen, is there any technical reason why i cant make 10 wallets and load them when needed? Because im already doing that and didnt have any problem so far  You won't even miss received coins since the client automatically detects when it needs to rescan. The problem gmaxwell mentions is only if you do something stupid like -wallet=/mnt/usbdrive/wallet.dat, since the database/ directory it depends on is still on the main hard drive. So long as you keep all your wallets on the same disk it should be fine. |
|
|
|
8min for 30% synchronization, was this always this fast?  No, that's a combination of ultraprune and the upgrade hack... |
|
|
|
Okay I see the problem here on EMC stratum.
Based on a commit luke-jr did to bfgminer, it seems he thinks that new work notification by stratum mandates that all work be thrown out in favour of the new work, because he FORCES the clean flag. However no other pool actually expects this, only forcing a clean when they actually send the work clean message. So I'm going to go out on a limb here and say the problem lies with the implementation of stratum on EMC, as coded up by luke-jr.
No, I think new work notification should be used as soon as possible without throwing out the previous jobs, just like it is for getwork and GBT (which have an equivalent submitold indicator). This is implied by the current Stratum documentation: clean_jobs - When true, server indicates that submitting shares from previous jobs don't have a sense and such shares will be rejected. When this flag is set, miner should also drop all previous jobs, so job_ids can be eventually rotated. Admittedly, there is room for improvement in stratum here, since it could support 3 states: - Previous jobs are invalid, don't send shares (getwork/GBT submitold=false; impossible with cgminer now)
- Previous jobs are valid, but please start using this immediately (getwork/GBT submitold=true; how cgminer interprets clean_jobs=false now)
- Previous jobs are valid; use this for new work at your convenience (how cgminer is interpreting clean_jobs=true now; no getwork/GBT equivalent)
Perhaps slush could clarify the current meaning, but it would be disappointing to learn stratum discards another fix for a problem we had already solved with getwork/GBT. Regardless of the current meaning, I intend to suggest the tristate when stratum's BIP process begins. |
|
|
|
|
Show Posts
