Quote from: ProfMac on June 24, 2014, 09:26:23 PM

Quote from: baddw on June 24, 2014, 09:20:20 PM

Quote from: ProfMac on June 24, 2014, 03:15:13 PM

Quote from: mdude77 on June 24, 2014, 12:27:00 PM

Quote from: taipo on June 24, 2014, 12:21:35 PM

Quote from: robix on June 24, 2014, 10:09:33 AM

Don't think so. AFAIK the transfer of the complete URL is already encrypted.

The other way someone could take a guess at which address was yours was if they knew what hashrate you were hashing at. If that were the case then they could merely visit http://eligius.st/~wizkid057/newstats/topcontributors.php and work out which one was yours.

That's easy to defeat. Use more than one address!

M

Back pay rises as sqrt(n) / n, so for 2 addresses it rises twice as fast.

How's that? My understanding is that back pay (which I'm assuming you're using to refer to either the shelving of shares, or the payment of previously shelved shares -- if you're referring to something else here, please clarify) simply goes on a share-by-share basis and has nothing to do with which account a share is under. If I submit 1000 shares under Account A, and 500 of them are shelved, that's the same as submitting 500 shares (250 shelved) under Account B and 500 shares (250 shelved) under Account C. The order in which the shares go into the system is the only thing that matters. Assuming that hashpower is equally divided between Accounts B and C, and thus they are both submitting shares with approximately the same frequency, I don't see how one's overall payout would be affected by splitting up in this way. (Aside from the payment queue, which of course is managed on an account-by-account basis.)

There was an analysis and also a simulation a few weeks back. The conclusion seemed to be the sqrt(n) / n growth in time. If you split the account in two, that would be 2 * ( sqrt(n/2) / (n/2) ).

Are you talking about this?

https://bitcointalk.org/index.php?topic=441465.msg6740270;topicseen#msg6740270

I'm not sure that I buy that the shelved shares increase by sqrt(N), and I don't think anybody should put much credence into a result that has no documentation. Good pool luck decreases shelved shares, and bad pool luck (whether natural or due to attacks such as block withholding -- which, my gut is telling me, has not been completely eliminated from Eligius) increases shelved shares. Orphan blocks increase shelved shares, but that is a predictable percentage. Over the long run (assuming that luck normalizes over the long run, as it should), shelved shares should be directly proportional to N.

In particular, I think that this 2*(sqrt(n/2)/(n/2)) result shows that the correct calculation for increase in shelved shares for a given account could not possibly be proportional to sqrt(N)/N. We have reached a result that is nonsensical by simple logic; proof by contradiction.

To work through the logic again: Take a given account A, and mentally split its hashrate into two: B and C. Look at each individual share submitted by A to the pool, and assign each share randomly to B or to C, given equal weighting. Any given share will either be shelved or paid out. This is true whether the share is credited to A, B, or C. In this case, A = B+C exactly, and this applies to both Shelved(B+C) as well as Paid(B+C). There is no reason for Shelved(B+C)>Shelved(A) or for Paid(B+C)