Topic: [1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff] - page 364. (Read 837180 times)

Interesting.  Not sure if you have access to it but would be interesting to see which GPU are used (at least for those running Bitminter miner).
Also a top 10/20/50 list for highest hashrates in the pool would be nice.

Haha, that's awesome. Also brings up a question I'd had... is there a way to get BitMinter to start/stop via command line? My roommate leaves his PC on 24/7 and I just convinced him to buy an AMD A6 APU that nets a good 40Mhash/sec during idle time while barely using any power... but I want to set up an automatic profile that starts mining when WoW is closed and stops when he opens WoW... it plays smooth even with mining going, but it runs smoother with it stopped. If there's just a simple command line option I could feed it (like "-stop"), I could probably set up a utility to do it automatically...

I was just idly checking statistics and I was like, WHOA HOLY SHIT... that's like, the most I'd ever made in any pool at once! Sweeeeet! OK, my patience has officially paid off.

w00t! I found my first block :p

Feature request: play some appropriate jingle when youve minted a block

Still adding more stats...

Ever wonder which miners people are using? https://bitminter.com/miners

Some new stats available.

In the block list (https://bitminter.com/blocks) the CDF is now shown, which indicates the luck we had with each block. For block 17 it is 92.6%, meaning that when we started there was a 92.6% chance to finish with this many proofs of work or less. Or put another way, 92.6% of blocks are found faster than this one. That's pretty bad. let's hope our luck turns back to the way it was with blocks 11 through 14. The difficulty at the time the block was created is also shown.

The live stats (click live stats button at the top of any bitminter page) now has round statistics. This gives a pretty good idea of what is going on at any moment. The numbers are updated from the server every 5 minutes. In between that, local updates are extrapolated based on the pool hash rate.

At first the block income was split using PPLNS rules instead of proportional rules. It may be that you looked at the future payouts before I fixed it. These numbers were up on the webpage for some minutes before I noticed it was wrong. At that point I removed this data from the database and the block disappeared from the block list. After that it took me a while to write a program to parse the audit logs and create the payout data anew, this time with the proportional system. Then the block reappeared, now with correct numbers.

I feel it would be bad form to switch reward system in the middle of a block, so we had to get that last proportional block out of the way.

It could be that you saw these PPLNS-based numbers sometime between the time I posted the first message saying there was a problem, and the time I posted the message saying everything was fixed.

I'm very sorry for the bumpy ride switching to the new reward system. Everything worked properly when I tested it on my test server last sunday.

At least now we are hopper proof and the next time we are on a lucky roll the bitcoins will be distributed more fairly instead of being affected by pool hopping.

Yep, now it shows as unconfirmed.
Is it possible the % have changed though? Maybe I clicked the wrong block earlier, but I thought I saw I had under 1%. Now Im at 0.76%.
I probably just clicked the previous block tho.

Try it again. I had forgotten to update the unconfirmed balance after the PPLNS changes. Sorry about that!

Clicking the block shows my share, but I see nothing as unconfirmed payment, nor did I receive anything yet.

Everything in order again. You can see your pay as unconfirmed in your account, or click the block in the block list and have a look.

By the way, if anyone would like the audit log for this or another block, let me know and I will get you a copy where IP addresses are censored out. You can use it to verify that the number of proofs of work for each user for a block is correct, and even check that every proof of work is valid (requires a little programming - but the complete block header is available in the audit log).

That was the last proportional block. We are now on PPLNS with shifts, and hopper-proof.

Block 17 was found this morning, but there was a problem with splitting the income. I am working to fix correct shares to everyone based on audit logs. More info will follow. Everyone will get correct payment, and next block will be split according to the new PPLNS shifts.

On one of my machines with 4 GPUs the hash rate drops from 1435 to 1415 (roughly), when I go from performance to detailed mode, which is a 1.4% drop. On a couple machines with single GPUs I can't really see a drop.

While I was developing the miner the drop was much higher until I put in code to update the meters less frequently.

But yeah, a drop from 750 to 720 does seem excessive. That's 4%. I don't think I've seen the meters cause that high a drop.


Yeah, on the machine mentioned above the hash rate drops from 1435 to 1360 with a youtube video running. But if I right click the video, go in the flash settings and turn off hardware acceleration, I get hash rate up to 1415 with a video running (have to reload the web page after changing settings though, to see an effect).

You cant be serious? Drawing a 2D tacho needle would require basically zero GPU resources and perhaps a tiny % of CPU resources unless you update it 10.000x per second (and even then). You sure you are not doing something wrong here, or is that a side effect of the toolkit you are using?


If you run youtube, on windows at least, UVD is used, or whatever the hardware video decoder is called. That results the GPU clock being slowed to 400 MHz (on my machine). That is causing the slowdown. I can watch youtube on linux and it has no real impact on hashrate.

My point is that if you download and run a binary it really doesn't matter if it came from an open or closed source. In both cases you have to trust the person who made that binary. The binary isn't necessarily built from the source they are showing you. If you download a binary from a mirror and there is no crypto signature or hash to verify the file came from the people you think it came from, then you have to trust the people running the mirror as well.

If you look at source A and then run binary B, then saying it being open source improves your security is security theatre.

If you download the source and build it yourself, then that has real security value. As long as you or others go through the source.


If you are running it in full detailed mode then all the speedometers will slow down one of the GPUs. That's why I put in "performance mode" with the button in the lower right corner which can be used to hide the speedometers. Also minimizing the program should prevent the slow down, as you observed.

One GPU has to do the screen updates, and the more screen updates there are the less it can work on bitcoins. Therefore the slowdown is more noticable the more GPUs you have, because then you have more speedometers. You'll also see a slowdown from using youtube, etc. (old AMD drivers would crash if running video and mining at the same time, but that seems to be fixed now)

One thing I have noticed and I am not sure if it is a true slowdown or just a bug is that when minimized the program runs faster (or at least reports it does).

Simple experiment.

I have a 5970.  I get ~720MH/s.  If I minimize bitminter, wait a few minutes and then open it the "speedometer" is at 750MH/s.  It then predictably falls off slowly back to 720MH/s.

750 vs 720 ~ 5% so not insignificant.    I just noticed this today over a RDP session so maybe it only happens when viewing remote?

I just don't have detailed enough stats to see if it really is a speed change or if it some graphical/reporting bug.

On edit:  I guess I could use the reset counter.  Run it for a couple hours "visible" record time & shares.  Reset.  Run it for a couple hours "hidden".  Compare shares to expected hashrate.  I will try that tonight.

Anyone else notice this.  Pretty easily to replicate.

1) start bitminter.
2) run w/ bitminter app visible until hashrate stabilizes.  record hashrate
3) minimize bitminter
4) restore bitminter and confirm changed hashrate.
5) watch hashrate decay back to number recorded in step 2.

True but one could hash both a "known good" version and the version downloaded from server.  If the hashes don't match then the code has been changed/tampered.


The community is safer even those who download precompiled versions because if ANYONE who does compile notices something unusual they can notify others, start and investigation, create a thread, etc.  With source completely closed you choices are limited to a) run it b) don't run it.  Period.


W/ java webstart 99.9% of users likely will still just run it but it is more difficult to get away with malfeasance if source code is available for the other 0.1%. 

How many people compile chrome (technically chromium)?  Those that don't still benefit from those that do.  While open-source isn't a magic bullet to call it security theater is silly.

Good to hear Just remember to turn off "manual vectors" when mining on nvidia as this seems to slow things down.

I just tried bitminter, that is really cool!  Such a pity that I did not discover it earlier on.  Using my oldest machine on nvidia to mine is still quite fast!  The best thing is it is so simple!  Do not have to go through all the configurations as in others.

Found a nasty bug causing memory to leak. This and two other fixes in the new beta version:

https://bitcointalksearch.org/topic/m.534764

Please try the beta and see if it works better.