|
Btw. the pool need only 3 shares to found block 106959 yesterday. Congratulation for all three users, which get 16.6 BTC for one share! :-)
|
|
|
|
Why everything changed?
Read this forum for few posts back. It will be back soon. |
|
|
|
"Take" is actually a bit of a misnomer, as the server only gives out.
I like your service, but please, don't mist the reality that earn 50BTC against your pool is like mining standalone with higher than current difficulty, something around +10%. It is absolutely OK, as you take a risk of block variance and must be ready for unlucky times, but it is real cut off. |
|
|
|
Bob only gets a share of half the blocks created by Alice's pool, although he's connected 24/7.
Which is, of course, irrelevant. Bob gets all money corresponding to his hashrate. There is no reason why user with 1 hash/s should get a penny from every block. Simply said, only difference between this and my pool is that OneFixt take risk on his own, but cut payments for 10%. I don't take risk of mining probability, so miners payouts are not _so_ clear (but they are at least at daily scope), but I don't cut off payments (except donations). Both modes fits to another audience, so it's OK, but don't say "this is better for XYZ miners, because those big players on slush's pool cut off your money", that's not true. |
|
|
|
guess they'll lose more on pools (the more the bigger a pool gets) than the ~12.5% on this server.
Can you explain this more, please? |
|
|
|
I like your service and tested it by sending a tip as suggested  . But missing slider and zoom. Also better precision would be nice. Last mtgox trade was at 0.896, but graph displayed it as 0.9. |
|
|
|
|
What is all this stuff for? What's wrong on decimals? And no, I'm not American.
How many fingers do you have?
|
|
|
|
For those that like to see, say estimated performance, what if you included: Number of shares in the last 2 hours?
If you read yesterday's posts here and in pool thread carefully, I mentioned this many times. But things changed, looks like there will be all stats back soon. |
|
|
|
Hiding number of my shares seems weird. I can see them in my miner. Why hide information that came from me in the first place?
You see your shares, but you don't know to which block it fits. But shares on profile page were cleared when block was found. That's the difference. |
|
|
|
I think you are all missing the point a little. The concern is not cheating but undetectable cheating.
Bad guy can mask his behaviour pretty easily, so with anonymous registrations it is still a problem. And I'm also trying to keep the system to be fully automatic, with clear rules. I don't like to disconnecting users because I 'think' the worker is 'maybe' cheating. |
|
|
|
So it's been changed back to how it was.
No, nothing changed. It is how it works all the time. You mixed it with jgarzik's pool, which worked like you're talking. |
|
|
|
All this crap to try and prevent "fraud". Delaying/removing stats doesn't stop that BTW.
Tell me the reason why not. (well, I know it, but I bet you don't.) The server already only accepts shares for current blocks, but what you've done is overkill, plain and simple.
No server accept shares for whole round, not only for current block. |
|
|
|
When the pool finds a block, it could pay out only for shares that were found in the last time "t", where "t" is 43% of 10 minutes (I think).
All of these techniques can help, but add a lot variance for slow miners, which goes against the pool idea. Don't forget there are users which have less than one share per hour... |
|
|
|
there are plenty of ways to determine what block we're on. I.E. getwork hash
Which is different for every getwork(). Merkle si also changing with every new bitcoin block and every minute, when TX is received. Nothing useful for determining, if pool found a block. local bitcoind
Where you see only new bitcoin blocks, not pool blocks. Some kind of traffic analysis may be useful here, but it also may be obfuscated by pool and I doubt it will be exact enough. [/quote] invalid or stales submitted for previous getworks [/quote] Which is for every bitcoin bloc, not only for pool blocks... etc...
For example? I don't see how delaying, or simply not showing stats is a feasible way to prevent any sort of exploitation.
You still didn't find any solution how to find, that pool found a block, which makes "43% cheating" impossible. |
|
|
|
If the stats are delayed two hours and we are currently working on a block, would they be able to tell after two hours if we are on the same block to abandon the current block?
The delay is calculated from block found time. So even if you don't see new block after three hours from now, you don't know if block was mined in 1:01 and pool crunched many short round in meantime or we are still on this one. Of course, with rising delay between last visible block and (now-delay) timestamp, users may be more suspicious that pool hit extremely long round. But you don't know what to start/stop mining, because you don't see what happen inside the last two hours... |
|
|
|
The true/false return value on getwork?
It said if share was accepted by pool, but no info about new round or so. Useless. ...did you mean to take out the "block history" on the stats page? Because that leaks information on which round is current (we're working on #737 at this writing) - again, I could be misunderstanding its purpose.
No, we're working on #742 right now. Read carefully, those stats are delayed by two hours! If I take the time the last round ended... ...which you don't know... What does it explain? Are you saying I'm naive?  I was not serious, this is my special humor . |
|
|
|
As the pool was before, with full statistics, users could check whether their revenue was really ((50/total_shares) * nb_shares). They could also, by talking with each other, evaluate if the pool reported a plausible number of total shares. While there were ways for the pool to cheat, the statistics allowed users to check it didn't cheat too much.
Currently, you don't see realtime stats, but you can compare those numbers on found blocks older than 2 hours, so not such big difference. Also, as I said, this is only temporary solution. Once I'll change some internal things, I'll show realtime stats per actual hour, so everybody will see almost the same numbers as before this last update. As long as you release data on how much a share is worth, "cheating" becomes possible. But you can calculate it itself, too. There is no fancy stats now, but I don't hide any needed info. You know how many shares you submitted and how many reward did you get. You also know that one round is worth of 50BTC. There's nothing hidden! You only cannot calculate/use this numbers at realtime. I was wondering if you had found a way to preserve both openness and fairness. Yes, described above. I believe having the value of contributed shares decrease over time would also fix the cheating problem, ensuring that the expected gain of joining is the same at all times.
Tell me how, I'll implement this! But this attitude open completely different way of cheating, I spent on this many hours by thinking. And once I'll need to take a financial risk of pool unlucky/cheating, pool mining won't be for free anymore :-). |
|
|
|
the only really secretive information is the total number of shares in the current round.
And time, which is bounded to shares in round with given hashrate. That's correct. That's the reason why I hide all numbers calculated from those numbers. For example, with current formula, expected reward drop to zero when new round is started, so it should be hidden, too. I'll change it to not leak info about new round. |
|
|
|
a "cheater" would just change it's behaviour from switch-after-X-shares to switch-after-Y-hours, what's the big difference?
There is no difference. But there is also not any 'time on current round'. i don't get ANY useful stats at all anymore.
I'm sorry for removing share counts per worker, it was really usefull, but it need major changes in core to allow displaying it back. So hiding it was quick patch. What other are you missing so much? I will replace 'shares in current round' by 'shares in current hour', so you will be able to check your performance and expected reward from those numbers (by comparing 'shares in current hour' with your worker's numbers). And total pool performance is very exact right now. |
|
|
|
|
Show Posts
