Bitcoin Forum
April 24, 2014, 02:00:40 PM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
Poll
Question: What type of pool payouts do you prefer?
Bitcoins - 2932 (80.4%)
Bank transfer / USD - 389 (10.7%)
Gold/silver coins and bars - 325 (8.9%)
Total Voters: 3644

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 [32] 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 ... 820
  Print  
Author Topic: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff  (Read 2084406 times)
BitLex
Staff
Hero Member
*****
Offline Offline

Activity: 868


View Profile WWW

Ignore
February 04, 2011, 05:58:03 PM
 #621

well, it's a bit hard to count them, if you can't be sure they've been 'accepted' (i have to run at least 1 outdated miner-version that doesnt tell me).

and why do you think slush needed to?
if i want to cheat, i can still take the time since last block and current approx.cluster performance and calculate shares-this-round that way, can't i?

1398348040
Hero Member
*
Offline Offline

Posts: 1398348040

View Profile Personal Message (Offline)

Ignore
1398348040
Reply with quote  #2

1398348040
Report to moderator
1398348040
Hero Member
*
Offline Offline

Posts: 1398348040

View Profile Personal Message (Offline)

Ignore
1398348040
Reply with quote  #2

1398348040
Report to moderator
1398348040
Hero Member
*
Offline Offline

Posts: 1398348040

View Profile Personal Message (Offline)

Ignore
1398348040
Reply with quote  #2

1398348040
Report to moderator
Buy a Blade, Get a 5-Chip Free!
Start Mining with GAWMiners.com
24/7 Live Phone & Tech Support
Free Hosting & Electricity for 1 Year!

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1398348040
Hero Member
*
Offline Offline

Posts: 1398348040

View Profile Personal Message (Offline)

Ignore
1398348040
Reply with quote  #2

1398348040
Report to moderator
1398348040
Hero Member
*
Offline Offline

Posts: 1398348040

View Profile Personal Message (Offline)

Ignore
1398348040
Reply with quote  #2

1398348040
Report to moderator
1398348040
Hero Member
*
Offline Offline

Posts: 1398348040

View Profile Personal Message (Offline)

Ignore
1398348040
Reply with quote  #2

1398348040
Report to moderator
1398348040
Hero Member
*
Offline Offline

Posts: 1398348040

View Profile Personal Message (Offline)

Ignore
1398348040
Reply with quote  #2

1398348040
Report to moderator
CFSworks
Member
**
Offline Offline

Activity: 63


View Profile

Ignore
February 04, 2011, 06:13:02 PM
 #622

I agree with BitLex here. Cheaters can find their share count easily anyway, since the pool still tells the worker whether or not the share was accepted. Even if that were taken out, a cheater could monitor the work that their miner was sending and check if the sent work was of a low enough hash and not stale, and count that way, so a person's share count isn't secret information. Taking it out just frustrates honest people tweaking/monitoring their legitimate miners.

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)

I don't understand pool cheating all that well, but to make an educated guess, the only really secretive information is the total number of shares in the current round. I have no objection to removing that. (And, you could put the estimated reward back in, just lower the decimal precision so it's harder for cheaters to calculate the share total exactly.)

Phoenix Miner developer

PGP/GPG key: FC5461A3
Personal donations: 1Abq88sPz2MjH4Yi8yZVCbfu1ZXRSP7id5
slush
Hero Member
*****
Offline Offline

Activity: 1078



View Profile WWW

Ignore
February 04, 2011, 06:20:08 PM
 #623

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.

BitLex
Staff
Hero Member
*****
Offline Offline

Activity: 868


View Profile WWW

Ignore
February 04, 2011, 06:23:07 PM
 #624

Unfortunately, slush had to do what he did. Good call.
i still don't get the point,
a "cheater" would just change it's behaviour from switch-after-X-shares to switch-after-Y-hours, what's the big difference?
yet for me the difference is quite big, i don't get ANY useful stats at all anymore.

slush
Hero Member
*****
Offline Offline

Activity: 1078



View Profile WWW

Ignore
February 04, 2011, 06:27:10 PM
 #625

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.

Quote
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.

Quote
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.

Quote
I don't understand pool cheating all that well

This explains a lot Smiley.

Quote
you could put the estimated reward back in

Will be back soon, please be patient.

Ryo
Newbie
*
Offline Offline

Activity: 28


View Profile

Ignore
February 04, 2011, 06:29:30 PM
 #626

I don't understand pool cheating all that well, but to make an educated guess, the only really secretive information is the total number of shares in the current round.

That's correct (regarding the specific type of cheating I described; there may be other ways to cheat).
slush
Hero Member
*****
Offline Offline

Activity: 1078



View Profile WWW

Ignore
February 04, 2011, 06:33:57 PM
 #627

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'.

Quote
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.

slush
Hero Member
*****
Offline Offline

Activity: 1078



View Profile WWW

Ignore
February 04, 2011, 06:37:10 PM
 #628

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.

BitLex
Staff
Hero Member
*****
Offline Offline

Activity: 868


View Profile WWW

Ignore
February 04, 2011, 06:37:21 PM
 #629

Quote
But there is also not any 'time on current round'.
but you tell us when the last block was found, not hard to guess the current round duration.

CFSworks
Member
**
Offline Offline

Activity: 63


View Profile

Ignore
February 04, 2011, 06:40:22 PM
 #630

Which is related to new _bitcoin_ block, not _pool_ block. No useful info here.
The true/false return value on getwork? I thought it told the miner whether or not the sent data was accepted by the pool and whether or not a new share had been awarded to that worker. Why can't cheaters count that? Or am I gravely misunderstanding something? (Also like I said, a cheater can always have a miner hash the getwork submission himself and determine for himself if it's valid/stale/invalid.)
Edit: Wait, I just saw what the problem is. A cheater can tell when a new round starts by watching the share counts reset to 0. Yeah, a "shares in last hour" system would be pretty agreeable then.

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.
...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.
Edit: Just noticed it's delayed. I guess that's acceptable, too. Sorry about that.

Timestamp is simply current time, nothing about round duration.
The difference of two timestamps is a duration. If I take the time the last round ended (which can be obtained from the "block history" table -- and is equal to the time the current round started, right?) and subtract it from the current time, I can determine how long the current round has been running.

This explains a lot Smiley.
What does it explain? Are you saying I'm naive? Wink

Phoenix Miner developer

PGP/GPG key: FC5461A3
Personal donations: 1Abq88sPz2MjH4Yi8yZVCbfu1ZXRSP7id5
slush
Hero Member
*****
Offline Offline

Activity: 1078



View Profile WWW

Ignore
February 04, 2011, 06:55:58 PM
 #631

The true/false return value on getwork?

It said if share was accepted by pool, but no info about new round or so. Useless.

Quote
...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!

Quote
If I take the time the last round ended...

...which you don't know...

Quote
What does it explain? Are you saying I'm naive? Wink

I was not serious, this is my special humor Smiley.

slush
Hero Member
*****
Offline Offline

Activity: 1078



View Profile WWW

Ignore
February 04, 2011, 08:28:10 PM
 #632

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...

DiabloD3
Hero Member
*****
Offline Offline

Activity: 1134


DiabloMiner author


View Profile WWW

Ignore
February 04, 2011, 09:30:01 PM
 #633

I've updated my miner to reduce share loss in pool situations. Update to newest.

geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW

Ignore
February 05, 2011, 02:09:23 AM
 #634

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...

Couldn't you just check against a local bitcoind for the current block number and have it updated in realtime? or near-to-realtime? I don't see how implementing a delay in stats reporting really stops them from knowing the block has changed.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW

Ignore
February 05, 2011, 02:25:31 AM
 #635

All you would be concerned about is current round, but realistically, if you're (the pool) only collecting shares for the current block, it doesn't matter whether or not you're on current round, or what the round is for that matter.

By only accepting shares for the current block, you're forcing the focus of anyone attempting to exploit to be just the current block, and even pulling or delaying server statistics, there are plenty of ways to determine what block we're on. I.E. getwork hash, local bitcoind, invalid or stales submitted for previous getworks, etc...

I don't see how delaying, or simply not showing stats is a feasible way to prevent any sort of exploitation.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
slush
Hero Member
*****
Offline Offline

Activity: 1078



View Profile WWW

Ignore
February 05, 2011, 11:00:37 AM
 #636

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.

Quote
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...

Quote
etc...

For example?

Quote
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.

ribuck
Donator
Hero Member
*
Offline Offline

Activity: 1218


View Profile

Ignore
February 05, 2011, 11:09:24 AM
 #637

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).

Because this is a sliding window, there is never an incentive for a miner to leave the pool at any particular time.
slush
Hero Member
*****
Offline Offline

Activity: 1078



View Profile WWW

Ignore
February 05, 2011, 12:40:55 PM
 #638

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...

geekmug
Newbie
*
Offline Offline

Activity: 4



View Profile

Ignore
February 05, 2011, 07:42:31 PM
 #639

You still didn't find any solution how to find, that pool found a block, which makes "43% cheating" impossible.

I think all you really need to is to estimate the compute power of the pool to work out expected time for 43.5% (as of writing that is about 23 minutes). If you switched to working solo after an average-43.5% duration and worked solo until the average block-find time (as of writing that is about 40 minutes), then your miner's average performance should still exceed the performance of full-time pool mining. Although, I haven't done the math to work out the expected pay-off of that strategy, so maybe I am wrong.

1AvAtrahbbXWdFHSA6zC9mb64esrBsRUw9
FairUser
Sr. Member
****
Offline Offline

Activity: 255


View Profile WWW

Ignore
February 05, 2011, 11:46:17 PM
 #640

Damn, I leave for 1 week, come back and the server stats are totally different and gone.
All this crap to try and prevent "fraud".  Delaying/removing stats doesn't stop that BTW.
The server already only accepts shares for current blocks, but what you've done is overkill, plain and simple.

Time for a new pool server to be born, cause this just blows now.

BitcoinPool.com - 0% Mining Fees - Jump In!
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 [32] 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 ... 820
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!