Yep, we already do that. That's why it is better to run payments every hour (and now on every confirmed block). If you run payments when a user clicks a button, then you can't batch transactions together and you run the risk of paying lots and lots of transaction fees. This is why a pool needs to be a little smart about an "instant payout" button.

An option would be to completely remove the minimum payout threshold and just pay out every user's complete balance every time a block is confirmed and money comes in.

Upside:

• You get your money in your wallet sooner
• The servers become a less profitable target for hackers. I can sleep well at night and not be responsible for (as much of) your money.

Downside:

• The transaction history in your wallet (the bitcoin program or other wallet) becomes full of tiny transactions
• Negative for the bitcoin system in general: when you next send money from your wallet, the transaction will consist of many sources, each of a tiny amount of bitcoins. This means bitcoin has to handle more large (in number of bytes) transactions. We will contribute to that 600+ megabyte blk0001.dat file growing on everyone's harddisk.

Any thoughts?

I put these changes in right now, for higher and faster payments:

• Pay out income from transaction fees - the pool now only keeps rounding errors. This goes for block #24 (next block we create) and up.
• Use "half down" rounding. The last "bit dust" of income cannot always be split fairly among users. I think this is the most fair way without the pool losing money. 0.000000006 is rounded up, but 0.000000005 is rounded down, just like ...4. This leaves a tiny amount of income which is kept by the pool.
  
• Make an extra payment run immediately after a block generated by the pool is confirmed
• Run the scheduled hourly payments exactly on the hour

Payment (from BitMinter to your own bitcoin wallet) is once per hour, currently 10 minutes past the hour. Perhaps it would be less confusing if it was exactly on the hour?

I am planning to add an "instant payout" button as well. But that will probably have to cost something to use. Alternatively, when I get a donation system implemented, if you donate over a certain percentage it could be free. I don't want to pay more of those 0.0005 BTC transaction fees than I have to. I'll need some income to balance out those expenses.

One thing I could do, probably without incurring more transaction fees than today, is to run payments also immediately when a block we made is confirmed.

So you get your bitcoins immediately when they are added to your account, if the payout threshold is low enough. And if you, at any time, change the threshold from above to below the current balance, you have to wait 60 minutes in the worst case.

I think I will also lower the default payout threshold set for new users from 1 BTC to 0.1 BTC or maybe even 0.01 BTC. I don't really like handling other people's money longer than I have to.

Wow, Fefox, you are really hitting one homerun after another here.

Thank you, that's very kind of you, sir

Sorry to hear of your misfortunes, FalconFour and P4man. Looks like your box did contain awesome, though, Falcon

Seems noone could reach the server between 07:01 and 07:19 UTC. Sorry about that. Looks like a network outage at the datacenter. Everything running smoothly again since 07:19.

I have to move to a different datacenter anyway, so I'll do that soon. Will let you guys know ahead of time, as that will mean a little down time.

Phew, I could breathe a sigh of relief when that block ended. Nice work, Myvolition !

And nice work on the banners, P4man. I will get personalized banners working soon


Sweet!

Nice looking banners!

I think "One-click miner" might be better than "Java WebStart" since a lot of users won't know what that is.

Also, the slim version would probably look better with shadows on "BitMinter". Although there may not be room? It should be easy to get shadows on the numbers as well by printing the text twice, first in black, then in white. Won't be as nice as the shadows you put on there, but hopefully it should look ok. If it doesn't, maybe I can try some sort of smoothing on the black (shadow) text.

Personalized banner with a meter with actual number on it is a great idea!


Pool stats are available at http://bitminter.com/api/pool/stats - it's just not documented anywhere. Adding individual miner stats is on my TODO list.

BTW, a couple users are sometimes submitting proofs of work based on work data the pool has never seen before. Those proofs will be rejected and you'll be wasting your hashing power. If you are using software that connects to multiple pools it may have bugs causing it to grab work from pool A and send the resulting proofs of work to pool B. I asked ckolivas and this should not be a problem with cgminer. Any other multi-pool software worth checking?

Yeah, just two ways of deciding how big each job for the GPU should be. If you give it so much work in one go that it takes more than 5 seconds to process, Windows will think something locked up and it will restart the graphics driver. And even before that the desktop will of course get extremely laggy. On the other hand, there is a little overhead every time you give the GPU new work. So if you give it tiny jobs things get slowed down from the overhead.

Very nice. I am thinking about some similar ideas, but with BTC prizes.


The button could blend in better, otherwise I think it's great. I like the background. Maybe you could make one that is not quite as tall and without text/button on, for dynamic text showing a user's speed? Or even the same background, just less tall. Then I can code a personal banner for each user.

The logo font is Century Schoolbook L Bold Italic, size 45, for "BitMinter", and FreeSerif Bold size 20 for "Bitcoin minting made easy". Thrown together with Gimp. Not a program I am skilled with using.

Yes, it's something to think about. But I don't want to force users to donate a percentage of their income to the person who recruited them. And I couldn't afford to pay this out of my own money for long. I'll give it some thought, though.


No, it will never be 100% certain that you create a block. It could even happen that DeepBit from now and 200 years into the future doesn't create a single block, even with 40% of the hashing power the whole way. It's just very very unlikely. CDF never gets to 100, it just goes to 99.99999999.. with more and more 9s

The chance that we go 30 days without getting a block, at 47 Ghps is 0.000005% - I hope that won't happen

Chance that we find one or more blocks within a 24-hour period:

With 40 Ghps: 38%
With 50 Ghps: 45%
With 60 Ghps: 51%
With 80 Ghps: 61%
With 100 Ghps: 70%
With 150 Ghps: 83%
With 200 Ghps: 91%

Chance to find nothing for 7 days:
With 30 Ghps: 8.2%
With 40 Ghps: 3.6%
With 50 Ghps: 1.5%
With 60 Ghps: 0.7%

(At the current difficulty)

P4man, nice looking banner Guess you won't mind if I use it in my signature here?

I will make dynamic sigs later showing GH/s and such... it's on my list

Having more proofs of work than work units is actually pretty good. But I guess the screenshot was taken shortly after things locked up.

Does the power meter get stuck at the same value as well? If so, I guess it is drivers locking up like you suggested, DeathAndTaxes. I'll put that on my TODO list - detect GPU driver locking up, and possibly try to restart.

As P4man said, with blocks 1 through 18 we have on average been slightly lucky. After the current block the average will be slightly unlucky. We are staying pretty close to 50% CDF on average.

The unlucky blocks are very frustrating in a pool with low hashrate. That's why many left this pool and the hashrate stayed relatively low. We now have 807 members, and obviously they are not all mining here now. I think the hashrate is the biggest reason for that.

I strongly doubt there are any bugs with building blocks. When the pool server gets its hands on a proof of work that can create a block, it logs that fact immediately. The last such message in the logs was when block #18 was created. Also, an average CDF around 50% indicates everything is fine.

It helps a bit that our pool hashrate is going up while the difficulty (and hashrate of other pools) goes down.

There are several plans lined up to improve the pool and increase the hashrate. But they all require some work (programming), so it will take time. But trust me, I'm doing my best. I hope people won't leave because others left. Once that ball starts rolling we all know where it ends. I very much appreciate everyone who are mining here today. Better times are ahead.

You can see they produced more proofs of work in shift 64 than in shift 63. Nothing is ever deleted from the database. Workers are just marked as deleted if you "delete" them on the website.

It's OK to run multiple computers using the same worker account.

Maybe in the future I will put in some limitation to discourage botnet miners. But I'll let you know in advance if that happens.

Nothing wrong there, the work is just spread out over more than one shift.

Here's the work from those 2 workers by shift:
 shift     | worker       | proofs
--------+------------+------
current  |  bitminterp4|  191
       65 |  diablocore2|  431
       65 |  bitminterp4| 1525
       64 |  diablocore2| 1455
       64 |  bitminterp4| 1518
       63 |  bitminterp4| 1196
       63 |  diablocore2| 1191

And here is the work by block:
 block  | worker        | proofs
-------+------------+------
current | diablocore2| 3077
current | bitminterp4| 4430

We have 800 members, but only 50 mining at a time. Start mining, you lazy bums!

Because of the way the OpenCL drivers work you get one core at 100% for each GPU on nvidia and on AMD with more than 1 GPU in the system. If you use only a single AMD GPU, it may be possible without one core getting 100% usage.

Apparently it's possible to avoid the problem on nvidia if using CUDA instead of OpenCL, I believe there you can choose to busy-wait (causing 100% usage on a core) or not. Haven't looked into CUDA yet, though.

Edit: When I say 'core' here I mean CPU core.

Hehe.. Nice of them to make the piechart big enough that we are visible.