Yes, the problem is on the server. I'm solving it, hope it will be better in few minutes.

I just added some caching of stats on site, because some people like stats too much that they keep their fingers on "F5" key :-). Graphs and hall of fame are generated every hour, stats page is cached for 30 seconds. Profile page is not cached (yet).

...said bobR after three rounds of (probably) bad luck.

(But if you mine using CPU, you are probably right. The electricity cost more than you mine. It is just the nice way how to get your first bitcoins to play with - except Bitcoin Faucet).

Well, this is not a bug, this is feature :-). I didn't want to complicate the stuff with score based system in the introduction, but as you are asking...

Using exp(round_time/C) can lead to extremely high numbers. Such big that with many workers and extremely bad pool luck, it may overflow somewhere. So in reality, the score based system is implemented with one optimization, that was not explained yesterday:

The real formula isnt score += exp(round_time/C), but:

where round_time is count of seconds from round beginning and hour_time is count of seconds in current hour.

And every hour, exactly at 0 minute, 0 second +- 50 miliseconds, I'm performing "renormalization". This means that all worker scores are divided by exp(min(3600, round_time)/C).

This has NO IMPACT on score system itself, but helps handling huge numbers in application. So your observation was absolutely correct, because every hour the system score drop to very low number.

+1 for use of standardized binary protocol everywhere.

Short summary:

JSON-RPC (over TCP):
+ Already used in bitcoin
+ Standard protocol
+ Extremely easy to use
- Missing support for binary data
- General overhead (repeating of data field names)

Protocol buffers:
+ Easy to use
+ Standard protocol
+ Support for binary data
+ Bandwidth effective
+ May replace current binary protocol on P2P side
+ No external dependency needed (protocol compiler produces plain C++ code)

Proprietary binary protocol:
+ Extremely bandwidth effective
+ No external dependency needed
+ Support for binary data (noticed for integrity of this summary)
- Hard to learn & use (everybody have to implement support in his preferred language)
- Not reusable (P2P and push interface needs two different protocols)

From this summary, I prefer solutions in this order: 1. Protocol buffers 2. JSON 3. Binary protocol

On the server side, every worker has queue of 12 last jobs (by default), which are needed to verify submitted jobs by worker. If you submit a share, but the job was already deleted on the server (by asking 12 next jobs from server in meantime), the share won't be accepted. So, if you're mining only by CPUs, you probably don't need separate workers, as CPU miners does not need such high number of parallel jobs. But I still recommend to use workers - it is easier to track miner problems and you don't need to investigate how much jobs is your worker asking (it does not need to correspond with number of CPU cores). If you are GPU miner, you should definitely use separate workers to not losing shares.

Yes, this is fixed. I implemented 10 minute timeout for  in-memory credentials. Not ideal, but I had to balance user comfort and performance.

Raulo, please receive my apologies, I confuse your and Ryo, when I wrote the post. I changed the original post with link to your thread and fixed "Ryo" to "Raulo".

Today I would like to introduce new system for calculating round rewards. Currently the "share based" system calculate user's round reward as

(fees and donations are not calculated here for simplicity)

which gives the oportunity for cheating by switching between more pools (or between pool and  "solo mining"). For further reading please follow paper written by Raulo and also read history of this thread.

Thanks to Cosurgi and Raulo, I implemented new, "cheat proof" strategy for calculating reward. Basic idea is that older shares (from beginning of the round) has lower weight than newer shares, which demotivate cheater from switching between pools inside one round. Once cheater disconnect from pool, his submitted shares lose value, so he cannot perform "Raulo's attack" effectively.

Matematically said, for every submitted share, pool perform


round_time is count of seconds between "now" and time when round started, C is magic constant which define how fast old shares lose their value. All following calculations are using C=300, but it may be changed in the future to provide the best cheatproof/usability ratio.

And on the end of round, system calculate rewards using formula


Question: I'm honest miner, how it affect my mining in the pool?

In longer time, this does not affect you at all. In shorter time, this introduce some bigger variance in daily rewards. When "solo mining" has the biggest possible variance and "share based" pool has the lowest possible variance, "score based" system is something between, but it is extremely close to "share based" system.

To be even more specific, your reward variance depends on two factors: your hashrate and your uptime on pool. Higher uptime in pool and higher hasrate leads to more steady pool payouts.

Model 1: If you're slow miner and have only few shares in hour, you may be unlucky and submit your shares to fresh rounds. In this case, all of your shares will have very low score which lead to low round rewards. But in longer time, it is very unlikely that you submit shares everytime to fresh rounds. In the other case, if you are lucky, you can hit share near the round end and your round reward can be much higher than average, which compensate your bad luck in previous rounds.

Better said, with few shares per hour, you probably never find the block mining standalone, so you should not care that your daily reward does not perfect fit your theoretic reward. It is very unlikely that you will be unlucky every day.

Model 2: You're quite strong miner, but you're disconnecting from pool frequently, because you play games, crack passwords using your GPU or anything else. Also in your case the round rewards can have bigger variance, because the score based system is pointing exactly this case. Pool don't know that you're disconnecting because you want to play games or because you're trying to peform switching attack. Simply said, it will be everytime better to disconnect from pool when next round begins. But even when you disconnect inside round, you never lose more than "expected round reward", of course. Still, even with random disconnects, your daily reward for longer time should be very similar as in share based system.

I gathered some statistics for score based system in last days and Cosurgi was so kind and prepared some nice graphs.

"line number" on x-axis show pool participants sorted by count of submitted shares. On the left side are the strongest miners, on the righ side are CPU miners.


The graph above shows absolute reward for every participant for score based and share based systems. You see that common miners have almost no difference. Last ~60 slowest miners have bigger difference in rewards in percentages, but we're talking mostly about less than Bitcoin cents (see exponential scale on y-axis). One lucky round for those slow miners is enough to get more steady payout, which is very likely in longer time period.

Those three miners with extremely big difference between score and share systems in the middle of the graph were extremely unlucky in disconnecting from the pool or (more likely) people who were using Raulo's attack. If this is true, it is not real problem for current pool participants, as their total rewards are only in few bitcoins for whole period of stats.


This second graph shows how variance is going down with more submitted shares. As you see, there is big variance for people submitted tens of shares in total (those stats are for more than four days of pool uptime!), but with rising count of shares, it become more steady as everybody has the same chance to hit good and also bad times for share submits.


The last graph shows variance in % for pool participants. That means, that strong miner can expect +- few percents of daily rewards and the slowest one +- 20 % of daily rewards. This is still extremely better than mining solo. Please keep in mind that those differences in daily rewards will be only temporary, in longer time average it will be the same as original share based system and you probably never hit such small variance in daily rewards without some kind of pool. Also don't forget that this change is necessary to show pool stats back again and keep you, honest miners, safe.

If there won't be any important reason to not start counting rewards this way, I'll start score based system tomorrow. I'll also publish pool stats without delays, as little compensation for bigger variance in the pool.

And again, big thanks to Cosurgi (long talks on IRC and nice stats in gnuplot) and Raulo (models for cheater's reward with and without score based system).

I cannot agree more! I'm not talking about HTTP based stateless protocol.


If you're talking about stateless calls over TCP (maybe binary, but I don't like it, as we discussed in protocol forum thread), there is only little overhead (probably only in sending username/login on every request), but it make thing little easier on server side and also open some possibilities like reusing the same TCP connection for many workers (GPU threads). Currently the GPU miners are asking for more getworks at once, which needs (and probably will need with state protocol) more independent TCP connections from app to server (It's hard to say now, because we are not discussing getwork internals).

But I think this is just a cosmetic thing and I won't fight for this.

Which is not against JSON over TCP. All of this you can perform also with my proposal. I just mentioned that the biggest saving (for mining) will be the step from current getwork() over HTTP to the TCP communication and push mining together, but not in saving single bytes in binary protocol.

OK, I didn't told that the pointer lookup is not needed/performed inside, automatically. It is just done by standard libraries presented in every language and there is no need to implement binary stuff again.


Well, we are talking about personal opinions. My opinion is that high level programming is much easier and error prone than low level implementation. Thanks to this attitude, we're programming in high level languages and not in assembler.

And you still does not give the calculation of bandwidth savings against JSON RPC over TCP.


Correct. But I hope you don't want to say that

import json
json.decode(sock.read())

is harder to do than creating own parsing library for every language (C, Python, Java, PHP?) and unpacking binary data, right?

I don't want to be personal in any way, I think it's great that you open this topic. I'm just finding some equilibrium between hardcore lowlevel stuff and almost standard protocol implemented anywhere. I'm simply not convicted that this protocol need such heavy overoptimization.

I really doubt this. I'm pretty sure that at least 70% of hashpower will be up on solo in less than day, which does not give any real advantage to overtake the network by anybody else. And the rest of 30% are the slow CPU miners, which don't want to mine on their own. So in reality, the pool add this hashpower, because without pool it will never come to network.


I think this is little tendentious. As pool is generating correct blocks, pool miners also making the currency more stable. There is only one real threat, this is "cartel mode" of strong miners or pool itself. DDoS of pool or any other serious pool outage does not make network weaker that without any pool.

Well, I know that I'm again mixing protocol and getwork implementation. But there is no big point in supporting getwork over tcp and still sending job every 5 seconds. So I'm talking about real situation, about using TCP protocol and real pushwork implementation at once.

Absolutely marginal overhead. Average CPU core can encode megabytes of data to hexadecimal per second.


So 2x more data (two bytes for one raw byte) for payload itself. For one mining job, only few bytes is really required, most of current data sending to client are not used (source: m0mchil). Much more effective way is to change job payload itself.


Which is also in your proposal, for storing message payload. Again, I don't see real trouble here.


That's why I told I'm probably too highlevel. I really don't care about finding pointer in hex string. It is much more cost effective to leave this job on computers and high level libraries than fiddling with bits on low level protocol. Don't forget that this protocol have to be reimplemented in many languages, so using standard protocol, you save tens of hours of labour for programming and bug fixing.


You are right that raw binary protocol is really the most effective. But let's find some reasonable level of optimizations. It does not need to be _perfect_. It need to be effective AND easy to handle/debug. Don't forget that you are optimizing nanoseconds of CPU job and then perform one SQL request, which is 100x slower than any protocol parsing.

Rough calculation:

Now:
--------
One request: 300 bytes of HTTP request, 700 bytes of data ==> ~1 kB of data every 5 seconds for each worker. It is 12kB per minute per worker.

Json over TCP:
--------
One request: (approx) 20 bytes of request, 300? bytes of response EVERY MINUTE ==> 320 bytes per minute per worker.

By very simple optimization, you cut bandwidth to 2.5% of original size. Without any binary fiddling and proprietary stuff. How many % will be the savings between Json over TCP and binary over TCP?[/list]

I just read the sources and mixing binary protocol with json compressed data looks weird for me. Why not simply use (compressed) json RPC over TCP and define only RPC methods? This should be way easier to implementation in any language, more standard, readable etc. But it still enable push features and will be more efficient because we get rid of HTTP overhead. Please don't reinvent the wheel.

Maybe I'm too high-level oriented, but encapsulating JSON RPC into proprietary binary protocol is very unusual.

For example, method 'login' should look like {id:'xxx',method:'login',params:['username','sha256 of username+password']}. One command can be finished by new line, or better, almost every language has support for streaming JSON (well, I know Java and Python libraries), because it is very easy to detect that message is complete.

I have probably another opinion that many of you. I think this forum should be about project development and comunity. Not about selling Romanian women, drugs, child porn or <anything>porn. If anybody want to offer this, let the separate forum appear somewhere around. But I prefer to keep Bitcoin "clean". I just don't want to send link to Bitcoin to my grandma, when big horse dicks appear on first forum page...

I'm not scared that somebody shut down this forum because of illegal content, but it can damage Bitcoin reputation ("Did you see their forum? Bitcoin is just for drug dealers").

You don't need Bitcoin client working for mining. Please follow instructions from pool homepage, there are few clients, compilation is not needed in any case.

I just finished big system upgrade. Pool is running on two servers now and should be able to handle 3x more traffic now. I hope it gives me enough time to work on pushwork implementation again. Tomorrow there will be also one short maintenance, I need to move main database and it cannot be done on running system.

Two bitcoin instances, mostly because reducing network latencies between those two boxes.