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

Pool backend was just restarted with a small bug fix. It would sometimes send out work that the new miner version did not like, which would result in miscalculations ("bombs" in the GUI). This is now fixed. Sorry if this caused you to think you had a hardware problem.

Some updates to the miner today. Details are in the separate miner thread: https://bitcointalksearch.org/topic/bitminter-client-windowslinuxmac-31163


I have some good ideas for this. Hopefully if things work out this will be in the next update.

Seconding the post above, I have 5870's and 5830's and there was a very slight decrease from phoenix and tweaked phatk vs the java front end.. less than 5mh/sec difference on any given card. Something's wrong with your friends gear.
Plus, at the same oc the java miner is much more stable in my experience, so I'm a fan of it even though it's not optimized for 5800 series cards.

I think not allowing other mining software would mean losing members.

Also, I think it's best not to let people know in advance whether a proof of work they submit will get a high or low payment, unless using PPS (Pay Per Share). From what I understand, what happened to Swepool was that they got a very very unlucky block, and almost everyone left the pool.

I think it works well if this is the situation at all times: If you do some work and submit a proof of work, you are very likely to get paid an average value for it, and there's some chance to get paid a lot or nothing at all. You can't know in advance how much value the proof of work will bring.

This way it always makes sense to keep mining, and things are perfectly fair for 24/7 miners. I think things are fair for casual miners too, although they may be unlucky and mine for 30 minutes without getting any pay (very unlucky).

The only problem with requiring the current front end is that the 5800 series is still not 100% optimized.  While I use the front end for my 6970 series card, as it is the fastest available...one of my buddies uses it for his 5870 and is almost 90mh/s slower than me.  The 5870 should be as fast or faster than my card using any miner.  I know this is being worked on, but until it is resolved, it would be cruel to force individuals to use the front end if using a 5000 series card.

As you may have noticed there are more pool hoppers these days, and tools for pool hopping. Therefore moving away from proportional payouts seems prudent. Of course we won't switch in the middle of a block, and the new system will take a bit of time to implement, but it's probably a good idea to switch soon.

Of all the payout systems people have thought of so far I believe PPLNS is the best. It's a good combination of fair payouts and not letting the pool become bankrupt or end up in some other situation where miners leave.

Basically PPLNS (pay-per-last-N-shares) works like this:

  payout = blockvalue * your shares among the last N shares / N

The people over at Eligius have a write-up on PPLNS with more details here: http://eligius.st/wiki/index.php/Pay_Per_Last_N_Shares

As for the question of how to determine N, I think N = 2 * difficulty might make most sense. In that case many shares will get paid twice. If choosing N = difficulty / 2 then many shares aren't paid at all. I think people will be more comfortable with most shares being paid 2 times, instead of 0-1 times.

One issue I have with PPLNS is the idea of storing million after million of individual shares in the database. This could become a bottleneck as the pool grows larger. It could also limit running statistics, and I would like to have a lot of statistics.

An idea I have to limit the load on the server is to group shares into "shifts" and pay per shifts. Just like some people work night and day shifts. Every time we have, say, a number of shares equal to 20% of the difficulty, that is stored away as a shift, and we begin on a new one. Whenever a block is found, the last 10 shifts are paid. This way the server only handles a handful of numbers instead of millions to display statistics.

It would be possible to pay the last 10 complete shifts, or the last 10 shifts + the current (incomplete) shift. Paying the current shift would make share payments vary in value with how complete the current shift is. This might make the system slightly hoppable. Not paying the current shift might feel unfair to some, though, especially as you might solve a block and not even get paid 1 share, if you don't have any shares in existing shifts.

Any thoughts?

It would also be possible to pay for last N hours, for instance last 12 hours. But I think this is a bad idea at least while the pool is small. If it takes a week to find a block, paying only the last 12 hours means a lot of shares aren't paid. And if we pay all shares from the last 7 days, then it gets out of hand when the pool gets larger.

The unconfirmed balance will be 0 until we solve a block, that's right. Because the pool is small that can take a few days, but I hope we get one soon now. I will soon add something to show how much you are likely to get when the block is solved.

Every proof of work that is accepted gives you 1 share out of the money that is split when a block is solved. Often the word "share" is used to mean basically the same thing when it comes to pool mining.

You should not have so many rejected. That is very strange. At the moment I have 90571 accepted and 138 rejected. The numbers should be more like that - rejected should be very few.

I wonder what could be causing so many rejected proofs of work. Anyone else seeing something similar? I've never seen high rejected numbers ("stales") when using the BitMinter miner.

What does proofs of work accepted and proofs of work rejected mean? I just had 512 accepted and 248 rejected. Is that normal? Also I mined over night and my unconfirmed balance is still 0. Does it not change until a block is solved? I'm still pretty new to this stuff.

Cool that you like it, and welcome on the team.

The only thing saved right now is name+password (if you check the little box in the login window). But it is certainly on my TODO list to save the settings! I hope to get that done soon, there's just a lot of things to do.

I just started using this miner. I like the miner. It's easier to use and It's giving me an extra 6 Mhps. Is there a way to save my setup so my settings are saved?

Thanks, Xephan, I replied in that other thread.

Just updated the website with a few changes:

• Fixed a bug where some workers would not show in the worker list if they had no shares in the current round. Thanks to Soak for reporting the bug.
• Block list now shows the average hashing speed for each block found.
• New LCD-display of the pool speed on top of each page (shows as normal text in old browsers)
• A "contact" page to send me an email, to make it easier to get help in case of problems

Newbie might need some attention here
https://bitcointalksearch.org/topic/error-while-gui-is-running-36604

Good stuff

Pool hashrate looking very nice now.


Yes, me too. Such unlucky blocks are hard for a small pool.


I wanted to make it look a bit like internet banks. Don't they usually show the newest transaction at the bottom? Maybe I should make it possible to switch sorting order.

Anyway, I plan to add pagination before we solve too many blocks, so you can jump from page to page like with a google search. Need to do the same thing with the block list.

Engineers at the datacenter finally fixed their networking after approx. 5 hours downtime. I will think about different hosting options. Sorry for the downtime!

Problems at the data center where the server is hosted makes the server unreachable from the internet. Sorry for this. I hope they get things straightened out quickly.

Hopefully we continue to solve blocks.  One of my buddies was upset with the payout due to the unlucky block, I tried to explain how it works on smaller pools.  He is still thinking about going back to BTCGuild...I am hoping he stays.

Finally! Our first unlucky block is behind us. The solution to finally mint these coins came from Colby, who is now the pool's new hero.


Great! Sounds like my efforts to make the miner user-friendly are paying off.

Hit it with a stick :-p.

Man, hopefully we finish a block soon...the waiting is killing me.

Love the miner...actually have three people from work FINALLY getting into mining, as even at $7-8 it is still profitable for the casual miner.

The two I know of that are going to sign up have a 5870 and the other has a 4870.  That should add roughly another 540Mh/s to the pool.  If I can get the other two 5870's at work to join that would add another 900 Mh/s to the pool.

And here I was thinking I can soon take off the "beta" stamp.


The website appears to work fine with chrome. I'll do some testing with chrome and the sign up though.

The AOL thing is a problem with logging in?

Could you tell me (PM if you want) which OpenID providers that wouldn't work? That way I can track down bugs.


Oops! Thanks for catching this one. I have changed the validity check for bitcoin addresses. Just a (now correct) length check. Next I should let bitcoind validate addresses instead. Anyway, you should be able to set any valid bitcoin address now. Sorry for the inconvenience.


There is some JSON data available:
http://bitminter.com/api/pool/stats
http://bitminter.com/api/pool/topten

Unfortunately no stats on current round yet. I would like to implement a new reward system before making those data available.