|
I absolutely agree, those rules will make testnet more useful for software testing.
|
|
|
|
can anyone explain what possible scenarios are causing an invalid block being created?
When two independent miners find a block with the same previous hash at the same time, only one of them can be valid bitcoin block. So pool announced new block a second after someone else... |
|
|
|
How often are blocks invalid? First time I've seen an invalid block.
AFAIK it is second invalid block in whole pool history. |
|
|
|
VRMs below 125C
Too bad there is not prediction market yet. I'll bet to lifetime of your card  . |
|
|
|
In the case of a block with a transaction fee (eg. 10492) what happens to the fee? Does it get shared out along with the 50BTC generated?
As I was declared this many times before, currently pool keeps fees for self. Afaik, in whole pool history there are only ~0.05 BTC in fees. Once it will become any significant amount, I'll start calculating fees into participant rewards. Btw calculating fees into rewards is difficult now, because pool does not see generated blocks with current JSON API (so I don't know how much fees is for which block). Hacking Bitcoin client for 0.05 BTC is quite worthless at this time. I hope next Bitcoin release will fix that, so adding fees into rewards will be much easier. |
|
|
|
Please feel free to do whatever you like with the 0.00763751 BTC remaining in my mining pool account.
Na zdravi.
Díky  |
|
|
|
Yes, it's me. I just have to explore why I'm paying any transaction fees? |
|
|
|
The pool jumped from 21-22 to 30 today/yesterday  and it is not necessarily all new mining capability, some could just switched from other pools or solo mining. Big jump in today's pool hashrate was done by 13 fresh new 5970 connected to bitcoin network... |
|
|
|
I'm afraid I don't have hash that was submitted many times, each one successful, but I'll note it if I see it happen again. The exchanges where my client calculated the same hash twice and the server rejected it twice each looked like this:
Great, this is enough. From server logs: Share found by xloem.t0, nonce 06b344ff duplicate nonce 06b344ff duplicate nonce 06b344ff That means miner tried to upload block 3x, but only first share was accepted (which is OK). So it looks fine from pool side. Another question is why miner tried to upload one job many times. |
|
|
|
I decided not to report this when I noticed it, because I was concerned somebody would find a way to exploit it, but I imagine it's better to get it fixed:
Hi, it's absolutely fine that you're reporting this stuff. I used rpcminer-cuda, which reports the hashes it finds. Within the past few days, one of my miners found the same hash a number of times in a row, and the server accepted it each time.
It seems the server is sometimes assigning duplicate work?
I'm pretty sure server isn't giving the same job twice. I don't know rpcminer internals, but recalculating/resubmitting of the same job might be possible when some error appear. For example, miner can resubmit the same hash when the first attempt fail on network level. EDIT: This just happened again, but this time the duplicate hashes (including the first) were rejected by the server. (result: false, error: null). Is is this an error on my side or on the server's side?
Could you send me the specific hash, which was submitted many times? I'll search server logs... |
|
|
|
It should work fine on Ubuntu. Use latest fglrx (ATI's proprietary driver) and stream 2.1
I failed on installing package python-pyopencl, because it provide some files as stream 2.1 does. How to fix it? |
|
|
|
Mem scales to 1200, but doesn't seem to influence hash rate so I've left it at 1000.
Memory speed is quite irrelevant for hashing. I had memory also on 1200, but moved back to 1000 without any significant drop in speed (ArtForz said the difference is something around 0.3%). |
|
|
|
|
I can confirm that. SDK 2.1 on both systems, but I can reach 600Mhash/s on Linux boxes much easier (on lower clocks). From my investigation, miners on Windows are using GPUs with 92-95% load, but on Linux load is on 99%.
|
|
|
|
It must be switched off. You can't switch it off on Windows. For now, 5970 can be used fully on Linux only.
This is nice urban legend. With current drivers, it isn't true (this issue is probably related to some ancient drivers). I had also 5970 miner on Win and without problem. Google as far back as 2008, someone said, "Plug in another monitor". Not having another monitor, I plugged in my monitor to the 5870 instead. Now, the 5870 GPU was the only core recognized by poblcm along with the CPU. So I ran poblcm with a device=1 and it worked!
Nice trick! I failed to connect second 5970 to my Win box on the same issue. Now I'm running Linux, but it was a pain (related to non-problem setup of single 5970 on Windows). |
|
|
|
|
Ah, also one note regard to 'unfairness of short rounds'. No, it is completely fair, but in longer term, not in one (short) round. Yes, when you are lucky and find 10 shares in 80 shares round, you will receive significant amount of bitcoins from this round. But everyone has the same probability to hit this premium in every short round. More exact, everyone with the same hashpower has the same probability, of course.
|
|
|
|
Short quote from document: but if several pools were ran based on the same code, it may also be pro table to submit your work to all of them.
It's not true, at least for existing pools (puddinpop's and mine), because each instance of pool has own merkle root. So submitting shares from another pool (even based on the same code) won't work. Please correct this in your paper. About disconnecting from pool after some count of shares; There are much more factors than price of one share and power consumption. For example, rising network difficulty or some fixed costs (costs from owning mining rig, even in idle). If there is only one pool and you are big guy, disconnecting from pool saves your energy, but you have to wait much longer for new round, because pool is missing your hash power. So you are waiting, but new higher difficulty is coming and later it will be even harder to find new block... But I didn't spend time thinking about it, so this is just my intuition, not exact math. Good point is the switching between pools. But unless there are not two pools with similar hashpower, it's probably not relevant. Any rule which affect main formula for calculating rewards from contributed shares probably change overall pool fairness in some way. I think your paper is interesting and thank you for working on this. I'm just missing some graph in section 4.2, which shows time (X), hashpower(Y) and vertical lines where new block was found. All of this is public information and it would add more weight to sentence "there was no evidence that people gave up on old blocks". |
|
|
|
Maybe I worded it incorrectly. Basically, I am saying that the pool is paying fair share and everything is ok.
Oh, sorry for misunderstanding. Nice to hear that. |
|
|
|
How can I be producing hashes, and the server is not recording them.
Because of this, my payout has been dramatically cut...which is not cool.
Any logs from miner available? This looks like network issue & bad exception handling in miner... I shouldn't have to restart my miners at the beginning of every new round!!!
I don't think it can help in any case. This is not a Windows. Slush, did you change something?
No; and other workers looks fine. Which is your new login? I'll check current server logs. Which miner do you use? Do you have correct password? (Maybe miner just don't show you that you've bad credentials) Did you add some type of new restrictions, because if you did you just broke my setup......which ONLY HAS 3 MINERS!  Keep calm. I didn't banned you or something, there will be some reasonable explanation. |
|
|
|
Slush,
Something strange is going on.
This is the second day now that I've woke up, checked my stats, and it shows that I've produced 0 shares....even though my miner's are running and finding hashes!
So I restart my miner, and still, no shares showing up.
So again I have to restart my miner, and nothing is showing up.
Just restarted it a third time, and finally it's showing up with submitted shares.
Slush, the two workers I'm seeing this with are:
fairuser.desktop
fairuser.ATI5770
How can I be producing hashes, and the server is not recording them.
Because of this, my payout has been dramatically cut...which is not cool.
Hi, I didn't change anything for many days, I'm currently very busy in my job. There is no reason on server side for this, because other workers are going fine. I didn't block you or anything (and I also write email to user when I see anything bad with their workers). |
|
|
|
My math show's that BTC income received is less than one standard deviation from expected.
Can you publish your calculations, please? Because I'm doing some stats on my side, I know pool is performing well (rewards are accurate for number of submitting shares). There is only one thing which is not calculated into server's CDF - overhead of miners with network latency. I mean, if you have roundtrip to pool 200ms and you are asking for getwork() every 5000ms, you have 4% network overhead. It depends on miner algorithms, but when you have fast miner and he is stopping work when share is found (and is waiting for another getwork), this overhead can be much bigger. For example, Diablo's ISN'T stopping hashing when share is found, which is better. Those things should be much better with push based protocol, which (I hope) will be ready soon. |
|
|
|
|
Show Posts
