Does withdrawing fiat currency (after selling bitcoins) through a SEPA wire require ID verification? Because I don't feel comfortable giving away my ID.
I believe that it does. Could any of the staff confirm or deny it? From the verify page: There are no transfer limits or trade limits for "verified" Bitstamp users. In the event that you would like to remove the 1000€ first time deposit limit on your unverified account or the 10,000€ deposit limit for any future deposits and/or withdrawals, verification is necessary.
I've successfully done withdraws of less than 10k€ without verification. That limit could be cumulative, my withdraws don't add up to 10k€. |
|
|
|
It would be nice if there was a stat like Eligius's "luck" that told you how the pool was doing that day or round relative to the estimated rate it would be expected to find blocks. That way I could tell whether it was just bad luck or if my miners were underperforming.
http://ozco.in/content/luck-bitcoinhttp://ozco.in/content/share-payout-comparison-bitcoinLooks like the latter needs some work, though. Recent difficulty periods have such small bars because of the huge difficulty spike, so only the tooltips tell anything useful now. |
|
|
|
That doesn't make any sense. The whole point of a 512 diff rate is you send data to the server 1/512th of the time vs 1 diff. If they never get sent, how are they going to be accepted.
Um... I'm pretty sure that that - what you just said there - is what actually doesn't make any sense. By the way, it's not ad hominem to point out when someone is wrong. And based on what you just said, I think you just lost what little credibility you had. I think you should go read up on how mining actually works before arguing any more. What doesn't make sense? If something is 512 times harder to solve, a solution will be found/sent 1/512th of the time. If a block is found before the share, the work is never sent. If you never send your proof-of-work its not counted. What exactly doesn't make sense. And next round you might send way more diff 512 than expected with your hashrate. Yes, that round could turn out to suck by being longer / having smaller PPS% from the coin. It could also be better than the round which you missed by chance. Is that what you're arguing is the problem? |
|
|
|
All miners produce diff 1 shares at the same speed relative to hashrate (let's ignore the variance there). They do this no matter what share difficulty is wanted by the pool. Every one of those shares has 1/pool_diff chance of being accepted by the pool. Saying "it would've taken 31 seconds to finally get that share, but because the block took only 30 seconds I never had a chance" is just blatantly wrong.
That doesn't make any sense. The whole point of a 512 diff rate is you send data to the server 1/512th of the time vs 1 diff. If they never get sent, how are they going to be accepted. It's simple. The miner generates diff 1 shares. If a pool requests diff 512, the miner checks every share against that requirement. The miner ends up sending on average 512 times less shares, but every share is checked locally by the miner, and so has a chance. There is no magical 'buildup' to diff 512 that takes a random amount of time. |
|
|
|
|
All miners produce diff 1 shares at the same speed relative to hashrate (let's ignore the variance there). They do this no matter what share difficulty is wanted by the pool. Every one of those shares has 1/pool_diff chance of being accepted by the pool. Saying "it would've taken 31 seconds to finally get that share, but because the block took only 30 seconds I never had a chance" is just blatantly wrong.
|
|
|
|
Assume a constant difficulty.
Assume pool produces a new block every 30 seconds on average, for a particular coin and at the pools particular total hashrate.
Miner A has 0.5 megahash hashrate
Miner B has 5 megahash hashrate
Assume these hashrates translate to finding a share every 30 seconds, or 3 seconds respectively (again, on average).
Miner A will only find a share in time approx 50% of the time. So half the time he has 1 share, half the time he has 0 shares. He will have worked an average of 15 seconds for nothing when the block changes.
Miner B will find an average of 10 shares. He, as well, would have been working towards another share when the block changes. However, on average, he will have only been doing so for 1.5 seconds.
So the difference for Miner A is the difference between all or nothing.
The difference for Miner B is between, say, 9 and 10 shares... or maybe 10 and 11 shares...
Do you see it yet?
The bolded part is not correct. Sometimes the miner will have 0 shares, sometimes 1, sometimes more than 1. On average, 1. |
|
|
|
I'm planning to flash my jalapeno , only thing I want to ask will I have any trouble running it with bfgminer or Bitminter clients after the flash because I am having trouble running my jally on CGminer now ?? In other words will doing the flash force me to use CGminer only ?...Thanks
It should work just as before, but beware that it might produce scary device init errors for a while after powering up with the new firmware. I don't remember 1.0.0 doing that, but 1.2.5 only produces init errors for about 20 seconds if it's plugged in right after powering up. I was shocked at first and thought my device was bricked. I guess the new firmware is doing some tests after powering up, so it can't start hashing right away. |
|
|
|
I finally flashed my Jalapeno, and it's now running at 8.5 GH/s (was 5.7). However, if I try to turn the fan around, so that it's blowing air to the heatsink instead of sucking from it, the hashing speed starts to drop, and settles at around 7.7 GH/s.
With the original fan orientation, it's running at 8.5 GH/s, 62C and 3.85V. If I turn the fan around, those numbers drop to 7.7 GH/s, 50C and 3.55V. Haven't tried closing the casing after doing the OC.
Did you turn the jallies off when u flip the fans? When you turn off the jally, it will test the engines again on both chips. At some times, you will have more engines running. I normally use CGMiner --api-listen and do a "java API stats" to look at how many engines are running... In theory, you will need 15 engines to be running on both chips at at least 280mhz to achieve 8.5GHz.... If I change the fan orientation while powered down, it will never get to 8.5 GH/s after powered. If I change the orientation while it's already hashing at 8.5 GH/s, it will soon start to slow down towards 7.7 GH/s (while temps and voltages drop too). I didn't notice any changes in the engine counts / clocks reported by the API, but should check that again... Currently the stats are: PROCESSOR 3: 15 engines @ 287 MHz PROCESSOR 7: 15 engines @ 281 MHz THEORETICAL MAX: 8520 MH/s ENGINES: 30 FREQUENCY: 274 MHz (Yes, I have customized that output with preg_replace to cut the crap. BTW, what's FREQUENCY?) I'm getting around 80C readings from the VRM area with a handheld IR meter. Any idea if that's good or bad? |
|
|
|
Still broken? At least the block hash looked similar to what it was stuck on earlier, didn't feel like sticking around  |
|
|
|
|
I finally flashed my Jalapeno, and it's now running at 8.5 GH/s (was 5.7). However, if I try to turn the fan around, so that it's blowing air to the heatsink instead of sucking from it, the hashing speed starts to drop, and settles at around 7.7 GH/s.
With the original fan orientation, it's running at 8.5 GH/s, 62C and 3.85V. If I turn the fan around, those numbers drop to 7.7 GH/s, 50C and 3.55V. Haven't tried closing the casing after doing the OC.
|
|
|
|
|
Since people seem to be getting paid, I switched to this pool also.
Based on cgminer's current block time and block hash, the current block has been stuck at 252622 (0000000000000045da12116dc55785f0b4c889ca3bbb0c7663935a614f7f6263) for almost 3 hours now. I'm watching blockchain.info and no block changes are reported when new blocks come in. Of course this shouldn't really matter for any PPS miners, if the pool pays as it has promised. I just have zero chance of actually producing a block here.
My share counter is also not increasing anymore, it seems to be missing the last 2-3 hours of mining. Hashrate graph is drawing a straight line too.
|
|
|
|
Funny, I was sure that ckolivas' post about that cgminer bug would be misunderstood, since it was right after everyone had been complaining about bad luck for a page or two. I guess he just came to tell us about that bug without bothering to read the thread (and why should he?). Nice timing  |
|
|
|
Post a list of coins that the pool mines and a list of what was mined, and I'll try again. Until then, I'll mine at multipool.in and wait for someone else to come along.
I don't think he is going to care if you are mining on his pool or not. You seem a little upset about this... how much profit did you lose? You must have at least a 500MH/s rig to be this disgruntled. QQ I was actually trying the site out for a day to see it's benefits. Also, offering some ways to make the site better. I'm sure I'm not alone in the issues I see after mining for a day. The thing is I and everyone else that thinks like me will find other options, which results in loss of profit for him, so I do think it matters. Thanks for being concerned about me though I appreciate your thoughts. A whole day... LOL ok.. You must mean that it takes you longer than a day to figure out what you don't like, or maybe after after someone tells you what you don't like? LOL. There is this thing called variance, which forces people to wait, sometimes even long periods like multiple days, until they can know whether what they are experiencing is to be liked or not. |
|
|
|
You do realize that's someone's genius attempt at trolling? |
|
|
|
3.3.2 just cant load my config file anymore. Seems to be issue with int 19 and 20 (wont load it but still can set it). - Any way to avoid Int limit and to make newest cgminer to load file again?
Add --scrypt to your command line. 3.3.2 added a sanity check for intensities, which currently isn't detecting scrypt mode if you are setting it from the config file. |
|
|
|
Exactly. It's actually impossible now to specify all scrypt settings using solely the config file, since the intensity sanity check doesn't detect "scrypt" : true from the config file.
This didn't help, and seems redundant. I've never had to specify a kernel for scrypt, only one exists anyway. I'll just wait for the sanity check code to be fixed. It's not redundant if you use that instead of --scrypt on the command line. I was just telling you how to put it into the config file. I did put that in the config file (in addition to the "scrypt" : true that was already there, above the intensity line), and cgminer's new sanity check still didn't detect I was using scrypt. It's clearly tied to the "scrypt" setting, which just isn't picked up from a config file yet . The setting itself works fine, enabling scrypt mode, but the sanity check code doesn't detect it's there. It also fails to detect scrypt mode if -I is specified on the command line before --scrypt. Neither of these bugs existed before 3.3.2. "scrypt" : true,
"kernel" : "scrypt",
"gpu-engine" : "690,550,650,690",
"gpu-fan" : "80,100,100,100",
"gpu-memclock" : "930,720,790,930",
"gpu-threads" : "1",
"gpu-vddc" : "0.95",
"intensity" : "17",
"thread-concurrency" : "8192"
The above config settings still won't allow high intensities, if --scrypt is not used in the command line. I can't see what that kernel setting is supposed to do with scrypt, since the default kernel is the only one that can/will be used. I'm confident ckolivas can fix this easily. I was actually surprised the GPU mining code is still being modified. |
|
|
|
Exactly. It's actually impossible now to specify all scrypt settings using solely the config file, since the intensity sanity check doesn't detect "scrypt" : true from the config file.
This didn't help, and seems redundant. I've never had to specify a kernel for scrypt, only one exists anyway. I'll just wait for the sanity check code to be fixed. |
|
|
|
I noticed this bug as well. It brought 3 of my rigs down one I updated to 3.3.2 They all had -I before --scrypt.
This is a bug and should be fixed. Parameter order should not affect validation.
Well that may make sense if it were a scrypt miner. But it is not it's a Bitcoin mining program which has graciously added scrypt support. So this is not a bug. Maybe clarification in the Scrypt Readme, if its not already there, would be in order. Sam Well, in my SW development practice this is called a "regression" as it broke prior existing behaviour. Good enough reason for me to call it a bug. Exactly. It's actually impossible now to specify all scrypt settings using solely the config file, since the intensity sanity check doesn't detect "scrypt" : true from the config file. |
|
|
|
I tried building the newest git version, and noticed that my linux scrypt miners no longer worked properly. Hashrates were minimal because intensity was only 8. cgminer was complaining about the config being broken, and after starting with -T I saw the error was "Invalid config option --intensity: Invalid value passed to set intensity". This was introduced in commit 2b171f7fae19a451abefd5189ecad64fbd08d8a0, everything still works fine with commit cb6d62de08995cb3ce2ae906dfa629f42d382c21. I'm using intensity 17 on the linux rigs, I don't have the problem on my Windows rigs with a lower intensity.
Try telling it --scrypt before setting the intensity? Nope, that didn't help. The windows rigs also have intensity set before scrypt in the config, and it works. EDIT: --scrypt on the command line makes it works on linux too, though. So you seem to be on the right track. The intensity sanity check just doesn't detect that scrypt is being enabled from the config on linux. |
|
|
|
|
Show Posts
