Nobody is lying here. Yes, in my case on 30ghash/s the bitcoind started to fail. But it is not related to hashrate, but to getworks/sec. As you're using the same core as me, you'll hit the same problems later.

But maybe no, because you know (from me) that there will be problems with bitcoind. That's the point. Btw, my pool software (not bitcoind) can handle thousands of getworks per second and I never had problems with speed of my custom software.

(Bts it's nice example of another issue, in the times when I made the pool, running more instances of bitcoind on the same machine was not possible because of hardcoded listening on the 8333 port.)

But BTC per share IS meaningful rate...

Hehe, don't say this - you are still on 30ghashes, I had no problems on this speed, too (and also don't have problem at current 90ghash/s).

And please don't forget that lot of issues was caused by non optimized miners; I spent weeks with miner developers to find those glitches and bugs. The last huge improvement was support for long living HTTP connections, this was the reason why I closed the pool registrations, because hundreds of miners connecting every few seconds literally DDoSed the server with SYN floods.

I never had troubles with speed of pool software itself and I see your statement as little unfair, because you didin't have to solve 90% of troubles which I had. Just my 2 cents...

No, it should work fine.

If you don't want to take risk of bitcoin price fluctuations, you should quote your BTC prices using actual exchange ratio and "hedge" yourself with counter trades on mtgox. That means - immediately as you accept bitcoins, you sell the same amount on mtgox.

This can be fully automated and then you can receive Bitcoins, but don't take the exchange risk.

In the pool terminology, you found one "share", which is only small piece in the finding of valid Bitcoin block.


I don't know miner you are using, but I expect you should set one thread per real CPU core. I doubt you have 25 core machine :-).

Also, mining with 85-100 khash/s is absolutely worthless. You probably spent much more money on electricity. With your computation power, you'll earn 50 BTC in 32511 days (yes, almost 90 years). I recommend you to turn off mining on this machine...

This is not about pool itself; pool is just one of the first case for large amount of tiny transactions. In my specific case, I can (in the future) include my own transactions into the next mined block for free (or with fees paid to myself .


I'll be happy with not spamming the network, but this is not the real problem; I solve my case somehow (rising sending threshold, including txes into my own block). But other people will hit the same problem later and maybe some of them won't be so kind to save Bitcoin network resources - so we're talking generally about general scalability of Bitcoin transactions and about the painless way how to avoid this. I think we all agree that current infrastructure for fee negotiation is not powerfull enough at this time.


I'm perfectly fine with that.

It would be also nice to allow specific fee for every single transaction using JSON RPC. Then I can quickly introduce new settings for pool users - they will be able to choose if they want to pay fees for their withdrawals or not. It effectively move the decision about spamming of bitcoin network from me to them. (I'm pretty sure that those people withdrawing every 0.1 won't select fees, but they can spam network from their clients with zero-fee transactions as well).

+1

Expected daily reward for current difficulty  for 340Mhas/s is 6.15 BTC, so it looks correct...

One share in pay-per-share mode is 45 BTC / (current difficulty)

Do you check validity of submitted shares? I mean, does your json interface return "false" when the share has older prevhash than the current bitcoin block is?

Originally I counted everything, but changed it right because those miners with very long ask period...

Check your disk free space. I had similar problem when I was very near to 0.

I decided to completely rewrite the pool core and avoid using standard bitcoin client. This is quite big project and I don't see it's finish yet. So no, I currently don't have an idea when the new pool will be up.

TLD is .cz, but server is really located in London.


Difficulty?

I see that one pool instance underperform a bit, which may also explain problems of ronaldmaustin reported few hours before. I'll try to fix it tomorrow, but I'm busy right now. Unfortunately there is not any hot fix possible; pool uses sticky sessions, which mean that specific worker is always going to the same instance.

Edit: My apologize to all for the last batch of "Connection timed out", I tried to fix it and had to restart the server. I think I wasn't succesfull , but I will definitely solve ronaldmaustin's and dishwara's problem tomorrow.

This is normal variance. For example, I have two identical miners, both 1.2 ghash/s, running for the same time. One found 19 blocks, second one 34...

* slush is searching his pool switching proxy

FairUser, you show again and again, that you completely don't understand the problematics. You are wrong, because this graph shows the oposite that you think, because it shows cheater rewards INCLUDING anti-cheating policies.

The best what cheater can give is +3% in his reward, but with very low probability, because the time to connect to the pool will vary in the future. Simply said, the time from round beginning is not fixed to 2000 second, it is just historical statistics. In the oposite, with share based pool, cheater can give fixed +25% (if I remember the number well) _all_the_time_, because the time to start cheating is well known (it is start of the new round).

By the way, feel free to introduce new pool, but, please, stop trolling here. If you don't like my services, don't use them.

Yes, it is strange, but this is probability. Many people told me that they were lucky with the pool, then they disconnect and didn't find any block in solo for multiplies of average time :-). My advice - choose solo or pool (depends on personality and hashing power) and keep it. Switching from pool, when you feel lucky and connecting to the pool, when you feel unlucky is the road to the hell, you are cutting your reward by bad management :-).

I found 80 blocks (=4000BTC) for the pool and my total payout is 4017 BTC, so I can say it really converge to expected reward distribution :-).

This error does not mean that program crashed. It just inform you that there was trouble on network side, but it can recover easily. No restart or whatever needed...