since the pool still tells the worker whether or not the share was accepted.
Which is related to new _bitcoin_ block, not _pool_ block. No useful info here. person's share count isn't secret information. Taking it out just frustrates honest people tweaking/monitoring their legitimate miners. It is. Nobody than miner and pool know how shares he submitted. And once miner don't know when the round ended, he cannot tell on which round he's working. Also as I said, some kind of share counter will be back soon, to allow miner checking by user. I don't really care about what information is on the statistics page, though, since I don't check that very often, but taking out the current round duration is another piece of easily-obtained information: (Current Timestamp)-(Timestamp of last round ending)
Timestamp is simply current time, nothing about round duration. I don't understand pool cheating all that well
This explains a lot  . you could put the estimated reward back in Will be back soon, please be patient. |
|
|
|
Hi guys, I temporary removed some stats which may be useful for pool cheaters following this thread: http://bitcointalk.org/index.php?topic=3165.0. I believe it is the best way how to prevent pool abuse. I had prepared this for days ago, but now it was the right time to hide stats. I'm sorry for discomfort for you, honest pool users, but I'm doing my best for pool safety and fairness. I'm working on stats, which will be time-oriented instead of round-oriented. So you will see accepted shares (X shares / last hour) profile page and expected reward soon back. |
|
|
|
I'm not sure you can remove the stats that allows one to "cheat" and still provide users with proofs that the pool is fair. Did you find a way ?
If you critize my trustworthy, then yes, I can cheat users all the time, I don't need to hide stats to do so. Please tell me reasonable way how to cheat now, if you forget some timing attacks as comparing latencies in notifications of new blocks from p2p site or so, which I'm also working on. I'll put back stats soon, as I make some improvements in pool core. |
|
|
|
If someone cheat and get more money on on quick blocks, than someone must lose on quick blocks. I am surely will not be the looser (nor will my customers).
In quick rounds is much bigger variance. Many people asked me why they have low reward from some short rounds. Basically it is because they was unlucky in those 3 minutes or so. Mining isn't steady at all, even on diff1 and strong machines, of course. Slush, I think that simply delaying or removing real-time stats will not help a lot, because most of relevant data can be obtained from the block chain itself.
Which one? Do you use new BTC address for every new block?
Afaik this is default bitcoin behaviour. |
|
|
|
Actually, the only thing that the cheater needs is the time when the round started so he can join the pool.
Which pool does not provide... You will not only need to hide the number of shares but the round starting time and the number of shares one accumulated in the given round (otherwise the cheater can connect one of its miners and see when the counter starts from zero).
Of course, I see no problem with hiding this. This way you can effectively turn off all the statistics and publish only "pool mining digest from yesterday".
Not exactly. For now I disabled some numbers completely (expected round reward or worker shares), but I plan to reimplement this from round-oriented to time-oriented stats soon. So you will still see how many shares will miners does and so. It will also be unfair to anybody who wants to join the pool (and not cheat) because joining midround is unfair.
It isn't unfair. Everybody have the same probability to hit good or wrong time to join the pool. Also don't forget that 99% users don't care about this when connecting the pool. Until you don't perform cheating, your loss from connecting in the middle of the round are almost zero. he may estimate the probability that you found the block
Nonsense. You cannot say who find the block by listening, for example, #bitcoin-monitor. |
|
|
|
Sorry, I misunderstood, I thought that new reboot was coming. Anyway, the email advice would be nice.  I have email notification about crashed miners almost done for many weeks. Unfortunately bad guys are inventing more and more bad things, which makes me busy on fixing it |
|
|
|
Please advice at what UTC time you are planning the reboot, so I will be watching accordingly.
Tell me your phone, I'll call you! This reboot was unplanned outage, so sorry, I cannot tell you 6 hours before in this case. |
|
|
|
Just checked online and my miners are still running, I assume they restarted themselves when the server was back up.
Did it go down last night? My miners stopped running for a while and I kept getting 502's when trying to load up the site.
Yes, I did mistake in network configuration, so there was small outage, too. But it was not full restart with all stuff bootstrapping. |
|
|
|
I'd advice slush and other pool operators to implement this counting. It slightly increases the variance of ones income but it's fair, it's simple and eliminates cheating which with multiple pools can become widespread.
No, it increase the variance a lot, which is against the purpose of pool. Also resetting on new block isn't solution, because bad guy can start mining on every new bitcoin block & stop after 43% of standard time between two bitcoin blocks. Maybe not such effective as cheating against current pool accounting, but this will still works. So I don't plan to change accounting itself. I know that it is only matter of time, when somebody start to cheat pool with this technique. So I have prepared 'delayed' stats on the pool. With this update, nobody will known how many shares is in current block. This obfuscate real time statistics a lot, but remain completely fair for all miners and cheaters won't have enough data to know when to switch. |
|
|
|
|
I had to perform full server restart. I'm sorry for short outage. This is also first restart for more than month where many stability patches in miners were included. So I'm wondering if anybody had problem with reconnecting his miners back to restarted pool. If so, please post errors/tracebacks here...
|
|
|
|
Because trying to accept bitcoins instead of whatever currency one normally retails things for is so ridiculously fraught with various hoops one has to jump through and maybe even daytrading one has to get into just to let someone give you $x.xx using bitcoins instead of using $ directly, I have been trying to figure out how a bot might be able to accomplush the feat instead of trying to make a retailer do it themselves using hours they probably should be using to do retailing instead of to do arcane forex stuff involving bitcoins.
Heh, interesting topic, but I totally didn't catch the rest of the post. Am I alone? |
|
|
|
Does "Your Daily Reward" Graph stands for Total Reward, or only Confirmed Reward ?
It's calculated from all found blocks in this day, so total reward. And yes, yesterday was not good, but it is how it works. Two days before were fine, for example. |
|
|
|
and those records cannot easily be recreated
So, shortly said, this is a scam. gene, where are you??? (edit: I hope it is obvious that I'm kidding.) |
|
|
|
more like 15% or so (note, that's hashing power, not hashes).
Looks weird. How is you network going? Any packet losses, timeouts? |
|
|
|
It would be nice to say to potential users that this version is vulnerable and may not be used in production. |
|
|
|
Do you keep a record of which work has been assigned to which worker?
Yes. Only the work (nonce? is that what it's called?) changes,
'Nonce' is 32bit number, which every miner iterate over to find a valid share. Nonce is valid only for given job, which is bounded to specific worker. So malicious Tor exit cannot pick your share and submit it as own. He can only corrupt/refuse the submit request or so. I reduced the ask rate to every 10sec, so it pauses less often.
With rising ask rate you have bigger chance to hit stall share. That means, if you get work from pool and then new bitcoin block is found, your submit from this share will be invalid. With 10sec ask rate and Tor latencies, you are on ~15 second delay. Bitcoin block is found in average every 600 seconds (practically it is less, because Bitcoin network is growing rapidly), so your average overhead is 15/600 = 2.5%. So 2.5% of your hashing power is wasted. Not an extreme, but you have to count with it. |
|
|
|
Using pool over Tor is nonsense, your rountrip will be much higher, so you hit stale blocks more often. I'm running some Tor relays so I have quite knowledge about latencies . About stealing shares - it's not possible. Share is valid only for your worker. |
|
|
|
How does one calculate that?
shares * 2**32 / round time |
|
|
|
Hello,
I've earned some money on Flattr. This means that I now have Flattr Euros.
How manu Euro? Try to ask in #bitcoin-otc IRC channel |
|
|
|
|
Show Posts
