Almost. It means how many getwork() can worker perform at once. This is hardcoded now, but it is enough also for strongest card on the market. I'm working on some improvements which make autodetection to this.

Good news here! Firstly, another block found. But with current cluster power this become more and more common  

Then, new round of bitcoins sent.


Then, I fix typo in 'threshold'. I had many complains about this critical bug!  
Next change: You can enter your account without logging in again and again.

And, by the way, I just finished new accounting system. It is online already. Good to know:

a) Rolling between old and new accounting system:

Current unconfirmed blocks will be paid with old system, that means I cannot guarantee order of payments.

b) Changes in accounting:

You can see new type of balance on your profile pages => 'unconfirmed reward'. That mean we already found a block, but he is still unconfirmed by network. After 120 confirmations, reward will be moved to real balance. And of course, only real balance is sending by cron script.

Performance

I see your reward is 5.8xxx. Technically, there is only one method in whole software which touch reward and set it near to zero and I'm sure it was not triggered in your case.

If you mean 'expected reward', it is completely different issue. It is calculated from your current shares and shares contributed by all miners. When we solve block and start new round, this may be a little bit crazy for a moment.

Thank you guys. Your support help me a lot when sitting on code many hours.


I understand your request. Unfortunately my miner is implemented in other way. It is built above common bitcoin client without any custom patches, so this is technically impossible. I would like to let it be as is. You can see maturing on site already and payments will be processed almost instantly soon.

(tired) Ok, it was already written, but I'll sumarize:

ad 1) NOW the payments are not bound to blocks. I cannot say which blocks were paid and which not. I KNOW it is not good idea. I'm WORKING ON IT.
ad 2) Probably no. I'm WORKING ON IT.
ad 3) Because you see one 'reward' on your profile. Rewards are accounted directly when block is found, so when sending script start before block is confirmed, payment is sent directly and there is no balance for some others (which maybe worked on older block). Again, I KNOW it is bad. I'm WORKING ON IT.
ad 4) This is beta service. When I prepared this before a week, I did not imagine there will be almost 5000mhash/s so fast! So as proof-of-concept I implemented algorithm described above. It was easiest way to get it work and it work well, until cluster do not find so many blocks faster than network confirm that. Get it now? I KNOW it is bad. I apologize. I'm WORKING ON IT. But again, this definitely does not mean you lost your rewards. After I start new accounting engine (maybe today, maybe tomorrow, because it really needs testing), all payments will be definitely cleared after all blocks become confirmed.


No, they were already answered, but not in so compact form, it's true.


I know what you mean, but this is definitely not scam. I must be an idiot to steal this way. There are much better ways how to steal you all. Most of them all one-liners. These problems are pure technical. And trust me, I spent much more time on this service last two weeks, so stealing few bitcoins is absolutely pointless. I care about pool future. Let's see if long-term statistics show that I'm honest person.


Sorry, but I'm doing my best .


Your choice. This is definitely not scam.

Your current reward is 5.82180106. If you mean 'expected reward', it is cleared every round we started. We found next block before few minutes.

@Other guys. I don't answer this because it is absolutely useless. I already post statement that I'm working on it hardly. If you don't get it, disconnect from pool, if you want. But shut up please.

I made little tweak in server settings, I hope it will be at least less often.

Thanks for your support! I appreciate it. Accounting rewards after block maturity is exactly what I'm working on. But I have to test a lot otherwise people will definitely kill me (too bad I have my location on bitcoinmap.com :-D).

Cool! During this post we found new block!

REWARD IS NOT BOUNDED TO BLOCK MATURITY NOW. I'M WORKING ON FIX. RIGHT?

Guys, you are making me crazy. Until you see corresponding reward on site, everything is OK, you do not miss single bitcoin.

Oh! Good to know! I didn't realized that. So it should not be related to 'max_jobs' solution in pool.

It is still today. I explained why some rewards was not still sent. I'm still working on. What is the issue?

I know it is your money. I know you are nervous. But keep in mind, this is free service in beta mode as was announced. No single milicent was lost yet, so please be patient. I'm doing in my free time. Last two days I spent on fucking hackers (I do not mean davout and bitlex now) which flooded single page of site and sending crippled PoWs again and again. Still you have excelent response times. Because of that, development is not so fast as I wish. But again, no money lost, no real problem.

Yes, I apologize Noodles, it looks there are some compatiblity problems between newest m0mchil's miner, pool and strongest card. Too bad that I tested it together yesterday and worked for me . We are talking on irc

Your limit is already over 20 parallel jobs (increased before days). I hope m0mchil's miner is not so hungry .

Are you still using separate workers for each chip/gpu?

To m0mchil - how many getworks() do you prefetch now? I probably have to tune "max_jobs" for those cards.

I see _this_ problem is on my side, because I register every getwork for later checks. Due to optimizations, I have 10 jobs per worker, which worked very well for all miners and 5970. But when m0mchil made some changes, maybe he is prefetching more jobs and I throw away oldest one; it leads to 'stale' errors.

I will increase max_jobs to 20 for your card. Please report if it goes better.

No. PoW is checked directly on server. No job resending.

Why should cluster client go directly to bitcoin network? If proof of work is valid, it's 50BTCwill be received by server, not client.


It is already possible that some miner find valid block and until he submit it to bitcoin network, somebody will be before them. Yes, in this case block will be invalid. But there is almost no latency between sending PoW from client to bitcoin network, if block is found.

Noodles, I become little angry. Stop flooding server or I will ban whole your subnet. There is NO race condition. Double spending will not work. Please save your time and server's resources.

No, this is not possible. Every worker gets unique sources for hashing, so when he found nonce which makes correct proof of work, it is definitely not valid for other jobs.

EDIT: Oh, I still don't understand your question. My answer was about broadcasting single PoW on low target between clients before submitting to cluster.

If I understand you question, you are asking if some node to which miner broadcast its final proof of work cannot hijack it and use for yourself? It is not possible because 'proof of work' is unique to miner who found it (there is encoded reward for miner inside; found block is useless for other miners).

Another words, I trust you there is hardware problem and you are not trying to hack the service :-).