Yeah, I didn't update the database code yet. Things suddenly got a lot better. I think it was just an index in the database that wasn't quite done being generated that made things slow. But it still creates gaps once in a while. I'm working on a new version with donations, where a lot of the database access has been changed. Coming soon!

Even if there was a flaw with the database code or block generation I'd still see it when the server receives a proof of work that is good enough to build a block. It looks like this in my logs:
The first message is logged immediately upon seeing a good proof of work. Checking all those "passing" messages it is easy for me to see if something goes wrong. And trust me, I check the logs often when we have bad luck.


Reducing variance by mining with others is a good idea. It will take a lot of changes in the pool back end. But I'm starting on that very soon.

I might go for having multiple options for miners to choose from. So you could choose whether your hash power is used in p2pool (with 10 second block changes) or GPUmax, or something else. Maybe a prioritized list.

Not sure whether work on all these different projects (or work sources or whatever) should go into a common shift. The alternative would be different sets of shifts, but that would kind of split the pool into multiple pools.

Yes, I can, and I will probably put in support for backup pools. I just have a lot on my slate, everything takes time.


Glad you like it.


We are one and the same.

What do you think sucks about the pool?

We get 20 new users every day, but hardly any of them stay. I'm assuming variance is the problem. But I'd love to hear about anything that could be improved. After almost a year of intense work this is still one of the smallest pools. I'm open to the idea that I may be "doing it wrong" in some fashion.

Cool, looks like a simple serial port design. Do the other bitcoin FPGA solutions work in a similar fashion, anyone know?

Would be a little hard to add support for this without an actual device to test on. But it looks simple enough that I could give it a try if someone has a device to test my beta versions on. Anyone get a BFL single yet?

Btw, you can abort work, but then it won't report good nonces found during that round?

There's no BFL support in it. I suppose I could add that, though. Is there any info on how to program them?

I don't have a working crystal ball either, but I do hope we hit some fast blocks soon.

We're getting over 20 new users every day, but with this kind of luck they are not staying.

Sorry little hick-up on the website

It is a nice graph. It is per block and not per time though, on the X-axis, so it's basically the same as ours. But the Y-axis is number of shares instead of CDF, and they have a running average for the pool shown in addition to each individual block. Might be an idea adding such an average. Not sure about shares vs. CDF though.


Yeah, I changed most of the database stuff in the pool backend. I put in some stuff to make parallel updates safe and added automatic retries in case a database operation fails.


That's due to parallel database transactions conflicting and one being rolled back and retried. When a database transaction is rolled back everything you did is reset to how it was before the transaction started except sequences. When a number is allocated from a sequence the same number won't be given out again, even after a rollback. Already there are many gaps in the user IDs. Now with the new database code there are gaps in the block numbers. Looks a bit ugly. I think maybe I'll switch to not showing the internal ID. The table is also sometimes too wide, so that may help with that problem. Or is a block ID of some sort useful?


170838 was stale on the NMC side unfortunately. I checked the logs and we received a new namecoin block from the namecoin P2P network 5 seconds before we attempted to create ours. Let's just be glad that was a new NMC block just ahead of ours, and not a BTC block.

170495 and 46281 were created from a single proof of work from kjakman. They were created at the same time, but one had trouble getting registered in the database. It took a full 5 minutes from it was created until it was successfully registered in the DB. I was watching and cursing as the database transactions were being retried.

Also this database code is putting 10x to 20x the load on the database, compared to earlier. While that's not a problem for the server, I don't like it. I am already working on a new solution that should run much smoother. On my test server the load was much lower and conflicting transactions happened very rarely. Back to the drawing board!

Phew, kjakman finally ended that monster block. I hope we get some easier ones now.

Glad you like the pool, guys. And bad luck is just something that happens. Some time back we had +30% luck for a while. Luck will turn again, sooner or later! Let's hope it's now.


Yes, but it makes it easier to judge luck in general when every block gets the same size in the graph. If unlucky blocks get much more space, it will look like we have bad luck all the time. Maybe a new graph would be useful though that shows luck per time instead of per block.


Both are on my list. I will first add pagination for blocks, shifts and transaction history. Luck and reward graphs are lower priority.

No, each block gets the same width in the graph. I should probably add timestamps on each one though.

Yes, a lot of bad luck lately. I sure hope there is a lucky streak just around the corner.

Let's bring down this monster block now!

When you click the "engine start" button on the website Firefox should open a small window saying "You have chosen to open bitminter.jnlp which is a: JNLP File (2.7 KB)".

Below this, on one of my computers the top option (which is the default) says "Open with Java(TM) Web Start Launcher (default)". On another computer it says "Open with Sun Java 6 Web Start (default)", but the second option "Save File" comes up as the default (pre-selected) option. As long as you get an option to open with web start, choose that and click OK - you're good to go.

Something else may show up as the default "open with" choice. Click the combo box and see if web start is listed. If not, click "Other..." which will list many applications you could use to open the file. If Java web start is on the list, choose that. If you check "do this automatically for files like this from now on" then Firefox will remember your choice for next time.

If Java web start doesn't show up as an option then there's probably something wrong with the file type associations and Firefox doesn't know what to do with a JNLP file. Firefox (unlike some browsers) gets this information from the operating system. Normally there should be a JNLP file type associated with Java web start after you install Java. Not sure what would cause that to fail.

You should have a file under /usr/share/applications/ with javaws in the name.

Ubuntu 11.10 example, /usr/share/applications/icedtea-netx-javaws.desktop

Could you try starting it from the command line and see if that works better?


Also you could try "javaws -viewer" and delete bitminter from the cache. Next time you start it, it will be downloaded anew, which might help.

Thanks for ideas for messages, boozer. Added to earlier ideas on a general message system. It will be super cool, only problem is to find the time to make it.

That's one hell of a hunt for GPUs too - good that it's finally coming together.

Hmm, I always assumed it couldn't run as a service because it uses a window and/or systray.

Now I was hoping I could build "run as service" into the miner. But I guess it would only work on XP? Is it impossible for a service to use the GPU on later Windows OSes?

Yes, switching to solo mining if p2pool is 51% attacked is a good solution. You can detect it before losing much income, so it should be adequate.

Also, I'm starting to think maybe p2pool's problems with frequent block changes and high difficulty stem from copying bitcoin's block chain technique directly. P2pool has different needs. Maybe this can be fixed by doing things a little differently. Have to think about that.

Quick update today. Version 1.1.2.

Only one change: Recognize FirePro M5950 (Toucan) and enable BFI_INT patching for it.

This was unfortunately broken by the recent GCN changes. Please let me know if you have other GPUs that are not recognized (or CPUs).

Quick backend restart. Fixed a memory leak and a couple other issues. The memory leak is what was causing the downtime today and the slow response which gave high stales earlier. Should be back to low stales, quick response and stable server. (knock on wood)


Sure, it becomes like 2 separate p2pools. But I imagine all nodes end on the same fork after a while, to prevent degenerating into everyone solo mining by themselves.

Btw, awesome miner project you have.

I don't want to sell the BitMinter source code. It should be possible to hook up pushpool or poolserverj or something else to p2pool though. And there is already a pool running on top of p2pool.

When there is a split in the share chain, I would assume p2pool nodes will see multiple chains and go with the longest one, just like bitcoin does?

Imagine if I am an evil pool with 310 GH/s and you are the honest p2pool miners with 280 GH/s. I hop over to p2pool with my pool and start mining on top of your shares, entering the share chain. You then try to build shares on top of mine, but every time you do I create a fork. I only build shares on top of my own shares. My forks are always longer than yours, so you never get paid. I am now using 310 GH/s and getting paid for 590 GH/s. You get nothing.

How does p2pool prevent this? If it doesn't go with the fastest-growing fork or something similar, but just stays on the local fork whenever a fork occurs, then it would have forked into a whole bunch of solo miners a long time ago.

Also, I don't see a way to control the difficulty - it's based on the share chain.

Bitcoin block chain technology gives you a single advantage: decentralization (hard for bad guys to shut down). You have to pay for it with 51% attacks, high difficulty locking out small players, and in general very inefficient processing, especially with 10 second block intervals. In this instance I'm not sure if this is a good way forward.

If I'm wrong about 51% attacks, and the 10 second block intervals could be turned into 10 minutes, I'd jump on the bandwagon right now. (The remaining problem, difficulty/variance, is what pools are there to fix)

D&T, I agree with what you are saying about variance. I have long been thinking about how this could best be done, pools cooperating in a "pool of pools". I believe that can even things out so that people join pools for their features, not for their size (which is a self-reinforcing thing, causing the biggest pool so stay biggest no matter what).

About 51% attacks on bitcoin and securing against this, I believe what Luke-jr. is doing with expanding on the "getmemorypool" json-rpc interface can be a solution. Also for making pooled mining totally transparent. We've been discussing that in another thread. It would make it impossible for the pool op to hide blocks from miners (stealing the 50 BTC), and could also prevent a pool op from using your hash power in a 51% attack, or using your hash power to pool hop other pools without your knowledge. I intend to implement getmemorypool as an alternative to getwork on BitMinter and build some features around that to make mining more transparent and give miners more control.

I think "getmemorypool" with the expanded functionality will fix a lot of problems with pools. So what remains is the backbone or "pool of pools" which could enable a small pool with better features to beat a bigger pool. It could make variance a non-issue and finally let miners and pool ops focus on everything else.

So what about p2pool? I think p2pool has a couple of problems due to its reward system being based on a chain of proofs of work. I see two problems which is a reason I don't think p2pool is good for end users: A small p2pool, if I understand it correctly, is vulnerable to 51% attack on the reward chain. Someone with 300 GH/s today (a hopper proxy or pool?) could hook up to p2pool and cash out every bitcoin that is created. Everyone else would be mining for free, giving away all their income to the attacker. And a big p2pool, well, the difficulty on the reward chain would approach the difficulty of bitcoin, and make p2pool useless.

What about p2pool as a "pool of pools" backend? The 51% attack could be scary. The difficulty issue makes it useless for the smallest pools. And 10 second long poll means the server is doing long polls all the time. Things like x-roll-ntime become useless. There's no way around it, the server spends all its time pumping out new work to every single miner. You need much faster servers and use a lot of resources simply because of the way p2pool is designed. If you can't do it quickly enough, your stale rate on the reward chain will sky rocket, payouts will drop and the pool dies.

I have some ideas how stales on the reward chain could be reduced. But I see no way to prevent 51% attacks or p2pool creating very high server loads when used by a pool. Otherwise I would have switched already. I would love a tool to make variance less significant.

The only way I see how to fix this is by making a pool backbone that doesn't use a reward chain, but works a little differently. I have a lot of ideas for this. But I'm not sure how much point there is to working on that. I'm not sure if any pools would join a backbone. There isn't much interest for "getmemorypool" either.

Sorry for the downtime. Looks like there is a problem with the pool backend. I'll start working on that in about 2 hours. Looks like it's the same issue that was causing slow reaction and high stales. I hope things will run ok with low stales until I get it fixed. At least the pool should not go down again.

Again, very sorry for these issues.