Yes, this is just a luck. There is no reason for just big difference, you have only small statistical population to make conclusion.

*such high* term is very relative. When I come to bitcoin, prices were at 0.25. I was just curious and bought my first bitcoins for 100USD at this rate. And people asked me the same question - why are you buying at *such high* prices? :-D

I'd like to say that *such high/low* is only in your head. When price will be at parity, people will be surprised why somebody sold his all time bitcoin savings for 0.5. Similar situation can happen in case of bitcoin crash (big security issue, ...) - now people *think* 0.1 is too low to sell, but once price will be at 0.08 already, anybody will sell on 0.1 price.

Any barriers (at least in Bitcoin market) are purely psychological. There was no fundamental reason for resistance at 0.3 or 0.4, there was no fundamental reason for support at 0.2. With resistance at 0.5 or even at 1 BTC/USD it will be the same - people just *think* that price is too high, which creates the resistance.

I also like your article, well done! I think it is one of the best introduction to Bitcoin, because the most of current articles is concerning to technical details of project too much.

I'm not rounding, but flooring with 8 decimal places precision, to avoid divide more than 50BTC between workers. The rest from "flooring" (50BTC - calculated rewards for all workers) is added to random user which participated on the block (it is usually something like 0.000000x BTC or so).

You are right. I replaced some occurences of 'block' to 'round', which make more sense. Will be on site soon.

Try to add ending slash to URL. There is redirect and rpcminer maybe don't handle it correctly...

It's probably me. Bitcoin Pooled Mining server.

There exists stuff like Comet or so. I will probably prefer something TCP based to avoid HTTP overhead (which is significant in our case).


I'm not talking about limiting requests per second. Push based protocl just don't need polling every 3-6 seconds. Workers will receive new job immediately when merkle changed...

I think technohog described it well. I'm thinking about push based protocol instead of current getwork, where server will send a job to client only on merkle hash change (so only few times per minute, in the worst case). But it will takes long time before it will be stable enough to switch pool to this.


Nobody who owns 1000 old computers will let them compute hashes, because thanks to hash/W ratio it is completely worthless.

It would be nice if you can turn it on again and log data which throws invalid hashes. There must be some reason for that. I have to say I did not change anything in core in last many days (exactly until 5.January).

Afaik there can be those reasons for invalid hashes:
1. Old poclbm version
2. Overclocked card
3. Network connection troubles
4. Server troubles

I don't know about other reason why it should not work. From server graphs, I see one small drop in network transfers at 1:00 UTC (approximately for 5-10 minutes), which may indicate some network troubles, but I don't think it is significant. But I can confirm that some miners are trying to re-upload shares, which means they have troubles with their connection. But it is probably nothing what I can manage.

Today I blocked one user with 1000 registered workers and many hundreds of them active. Looks like first botnet on the pool, which is something I don't want to support. I'm thinking how to prevent this, because it consumes too much resources for nothing (from my first investigation, every worker had around 500-800 khash/s, but generated too much network traffic).

No, that cannot be a reason. It's just about you are sending garbled data somehow.

Wow, it is really weird. Could you please try another miner?

Hi, I just checked registration and everything works fine. Please check your spam folders or use another email provider (not just another email address).

Glad to read that! So all users which have invalid shares often, please check, if you are using latest version of miners!


Yes, latest sources are without known problems. This issue was related with previous optimization in m0mchil miner, which is not compatible with pool because of more strict checks on pool side. So when m0mchil released version without 'changing ntime' feature and I turned on strict job checking on 5.January, things become broken for users on old version...

m0mchil fixed important issue on 5.January, so if you really 'havent changed anything', THIS is a problem .

But if you are running correct version, it looks weird. Please switch on debugging on miner and send me details about rejected hashes as PM. Thanks!

I did not changed anything in core today, only added few stats views on existing data.

From ~300 active workers, I see that only few of them has a problem, so I don't expect it's on pool side. There can be a lot of possible troubles on miner configuration...

Users with problematic workers: vsladkov.worker1, vsladkov.worker0, everpex.gpu1, Tek022.Zack2, jakub300.gpu1, fabianhjr.x1-5970 That's all. Another 318 workers is going well. Please check your configuration, overclocking and so. Don't forget you have to use separate worker accounts for every software instance!

Far easiest way is not reload page 10x per second . Site with it's 500 registered users is not big enough and doesn't need any caching layer yet. As I'm working on big sites with many caching layers in my job, I'm enjoying that I see fresh data on every refresh on pool site now .

Well, I'm not a specialist for mining software, but there can be tons of reasons. Enabled crossfire, bad driver version or so. Please ask on #bitcoin-mining or #bitcoin-dev for help.