Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 916. (Read 4382653 times)

hm ok nevermind I think the issues were caused (believe it or not) by the bitcoin client most likely overloading my home dsl connection both downloading the blockchain and maintaining connections (76+) to the network. Once I closed the client everything was back to normal.

What's with the connection problems today slush? Server issues? Daemon reboot?

21/01/2012 17:18:31] Result: 85b67ad4 rejected
[21/01/2012 17:18:45] Warning: work queue empty, miner is idle
[21/01/2012 17:18:53] Result: e7dc0e3d rejected
[21/01/2012 17:19:10] LP: New work pushed
[21/01/2012 17:19:15] Disconnected from server
[21/01/2012 17:19:20] Warning: work queue empty, miner is idle
[21/01/2012 17:19:36] Result: 91450389 rejected
[21/01/2012 17:19:58] Result: 5256c7df rejected
[21/01/2012 17:20:20] Result: 7e3975d6 rejected
[21/01/2012 17:20:42] Result: 59c31a98 accepted
[21/01/2012 17:20:43] Result: 0b6fe5fc accepted
[21/01/2012 17:20:43] Connected to server
[21/01/2012 17:20:43] Currently on block: 163270
[21/01/2012 17:20:44] Result: d47f8530 accepted
[21/01/2012 17:20:51] Result: eae38684 accepted
[21/01/2012 17:21:12] Result: 451256be accepted
[21/01/2012 17:21:19] Result: 5242f60a accepted
[21/01/2012 17:21:27] Result: 1109877c accepted
[21/01/2012 17:21:41] Result: 74605c87 accepted
[21/01/2012 17:21:53] Result: 29e32b79 accepted
[21/01/2012 17:22:05] Result: 48982211 accepted
[21/01/2012 17:22:28] Result: 5d581f47 accepted
[21/01/2012 17:22:37] Result: 267e7209 accepted
[21/01/2012 17:23:00] Result: a1b93dd7 rejected
[21/01/2012 17:23:08] Result: b1175713 accepted
[21/01/2012 17:23:08] Result: d9c34e14 accepted
[21/01/2012 17:23:24] Result: f1574a06 accepted
[21/01/2012 17:23:29] Result: faba6153 accepted
[21/01/2012 17:23:34] Result: a82188e4 rejected
[21/01/2012 17:23:38] Warning: work queue empty, miner is idle
[21/01/2012 17:24:01] Result: b6216921 accepted
[21/01/2012 17:24:02] Result: 3982401d accepted
[21/01/2012 17:24:07] Result: 31f033c6 accepted
[21/01/2012 17:24:20] Result: 8598509a rejected               
[21/01/2012 17:24:32] Warning: work queue empty, miner is idle

Alrighty

I appreciate you taking the time to check things out I spent a couple hours normalizing figures and doing analysis.

They would additionally be penalized on the following round as well.

Basically, to achieve optimal pay, you'd have to sit tight and not hop.

The result in aggregate would be that all of us that just let our farms hum along without trying to manipulate results would earn 5% more on time/energy.

They already are. There is a time factor in the current scoring system.

I think it works well, but if DGM is what Slush would like to move to, I am sure that will be of ultimate benefit to everyone.

Let's wait to DGM, ok?

So if their handicap were proportional to their reward from the last round, it wouldn't come CLOSE to covering the pain caused by the shares granted to the high end traders.

Example:

Joe Blow 20ghash earns 200000 shares in round 123 in 200 minutes
Jane Blow 2ghash earns 20000 shares in round 123 in 200 minutes
Slowie mc whybother 50 mhashes earns 50 shares in round 123 in 200 minutes
Scammer mcdouchpants 100 mhashs earns 100 shares in 200 minutes

So in the next round you calculate the estimated hashes per user in the first few minutes:

joe bloe 20ghash starts off with 5000 loyalty shares (5 minute estimated share volume)
jane blow 2ghash starts off with 500 loyalty shares
slowie mc whybother ends up with 12.5 or whatever loyalty shares.
Scammer mcdouchpants gets 25 loyalty shares

So if the next round ends in only two minutes

Joe bloe would get 5000 loyalty shares + 2000 earned shares
jane blow 2ghash would get 500 loyalty shares + 200 earned shares
Slowie mc whybother ends up with 12.5 loyalty shares and somewhere around 4 earned shares on the round
Scammer mcdouchpants would end up with 25 loyalty shares and lets say he's running 20ghash and he pulls 2000 earned shares.

So scammer mcdouchpants would be hurt badly in this situation because his payoff would be only 2/7ths what it would be if there were no loyalty shares.

For anyone STAYING in your pool, their percentage of payments would stay the same (actually they'd see a ~5% increase in earnings).

Pool hoppers would see a ~62% drop in profitability.

Also... people that bail on long blocks would be penalized a bit.

[edit] my point is that the aggregate share proportions amongst loyal users shouldn't be affected much, except because they'll have more shares than anyone that was not laboring in the previous block.  If the very FIRST share recieved was the block hash, the payout would be almost identical to the payout for the previous block.

So if you are a scammer and that block was 2 hours long... you're out of luck.  Because even in 5 minutes, you'd still be looking at 50% of the shares relative to your processing power for the block.  In the upper area it'd make hardly any difference.

Bottom line? You get guaranteed safety from pool hopping and you have to work through one block at a decreased rate.

No, they have just higher variance, but it averages out itself (after 1000-10000 shares).

So are low hashrate miners having problems in your current system?

Because if your current system is able to handle them, then by distributing loyalty shares each round (for that round only, then they go away) you'd be handicapping by way of the distribution of rewards for the last round.
                                                                                   
Are you having a tough time with your payouts to slow miners now?

As I said, everything has been discussed before. Adding "loyalty shares" won't work as expected because of low hashrate miners. Are they mining, idling or hopping? Upgrading the rewarding system is definitely the way to go.


Please... read all the stuff and don't open the discussion again... Seriously... Edit: I recommend you papers of Meni Rosenfeld, he has very nice calculations for almost every method.

No no... 5% is the net loss.

The loss only on fast blocks is near 25% on average.  

So we're losing 25% of our potential pay off for a 5% gain in performance.  So the miners are netting somewhere around 25% more per hash by hopping pools than we do sticking it out.

Well, perhaps, but those hoppers didn't do the sometimes 4 hours of processing on the server that we did in order to get a shot at a fresh block.

While we're slaving away at calculating that hash...they're off trying to get more than their due many other places.

Anyway, I can solve the problem with a relative degree of ease.

You create another class of shares called 'loyalty shares'.  You create a number of shares equal to the estimated share count at 5 minutes with current has power.

You distribute loyalty shares proportional to the payouts on your last block.

So...

Two things...

1) Pool hoppers would be fucked. (their margins would be reduced to tatters.  If they happend to hop in on a 2 pool that closed in 2 minutes, their share would be super miniscule due to the loyalty shares.

2) It would ease attrition on long length blocks because folks wouldn't get the loyalty shares if they bailed.

This way... instead of your most loyal folks getting shafted in short rounds, we'd end up doing the best.

Sargasm, things is more complicated that it seems to be. I never said that there aren't pool hoppers. There are a lot of calculations for various pool models for pool hopping and it's known that score method used on my pool have some minor flaw from the view of pool hopping. Actually only PPS (requires higher fee) and double geometric (very complicated) methods are supposed to be fully hop resistant, but I don't want to open ANY discussion about this now, because everything has been discussed before.

FYI I'm working on rewriting the pool to double geometric method, to satisfy all people who're complaining about even very minor chance of extra gains for pool hoppers. Unfortunately double geometric is _really_ complex method and it does not scale well for large pools. Btw I discussed scalable algorithm of DGM with Meni Rosenfeld on Prague conference...

Back to topic. Although the variance for short rounds is done by pool hoppers, it does not mean it's your loss. It's because you forgot that thanks to pool hoppers, there's higher hashspeed in shorter rounds. Actually the hashrate for long rounds (so hashrate average cleaned from pool hoppers) is around 1350-1400 Ghash, on the beginning of the round there's hashrate slightly over 1500 Ghash, which fits your number pretty well. Don't forget that it's even more complicated, because pool hoppers don't disconnect at same time, but they use various methods and are following various pools. The pool hopping benefit is *teoretically* around 5% of pool hopper profit, BUT hoppers are working on the pool just for very short period of time (depends on selected algorithm, but less than 5 minutes?), which means that their average block reward in absolute numbers is very small comparing with full-time mining. So only 5% of this tiny profit is the real loss for others.

I'm not talking that it isn't a problem. But the real loss done by pool hoppers is insignificant in the global view (it's much lower than natural variance in bitcoin mining itself) and it's better to wait to correct implementation of DGM than hurry and break the reward calculations in some strange way.

Whatever it is... it is raping us.

I have found some interesting data that seems to point at pretty substantial losses due to pool hopping in early parts of rounds.

Basically I ran a bunch of numbers and I'm looking at some anomalies that would be highly unlikely to be caused by chance.

Since I was seeing what seemed to be much lower numbers than I should have seen on short rounds, I had to do some data analysis with small sample set that had some progressive variance caused by systems going down from time to time.

So, my analysis is off a somewhat normalized figure of 5 chronologically continuous blocks average.  I compared the 5 block normalized average to a percentage figure for individual payouts over or under the mean for all payouts.

It shows that in blocks that move faster, payouts deviate from running averages to the tune of 85.34% against averages.

Larger blocks have a mean average of 104.47%.

You can see the analysis here:

https://docs.google.com/spreadsheet/pub?key=0AhhejNMzWwx8dGpYZE9FYXk3d05MQjVDNUxLcHNXZkE&output=html

If it is pool jumping, it is killing our profits by potentially more than 5%.  The only real other thing it could be is slush.

If it is pool jumping, the solution seems simple.  Distribute an initial set of shares each round based upon the percentage of total shares by user in the round preceding.  The initial set of shares should be determined by estimated shares at current hash rate in the first 5 minutes.

This will suck the piss out of pool jumpers and give the loyal folk here their hard earned full return.

Thoughts?

Newest poclbm miner (git version only, will be released as new version in following days) has nice support for Tor mining. Thank you m0mchil!

1. Install Tor on mining computer. No special configuration is needed, client mode (default) is enough.
2. Example command to run poclbm over Tor:


That's all! poclbm over Tor supports long polling and ntime rolling and our testing computers achieved ~1% stale ratio, which is pretty good result for mining over high latency network like Tor.

Tor mining have some benefits. Not only that mining is purely anonymous then, but it's also DDoS resilient, because Tor service on the pool is running over secret IP...

As you can see on stats page, there are already some miners connected over the Tor. Happy mining!

Yep, I was thinking about it too and I pretty like your proposal. I'll do it soon.

sadpandatech: Thanks for doing mining support! I don't have such experience to help members with hardware...

Found me a block! woohoo!

If you are running the latest phatk, try removing the 'FASTLOOP=FALSE' from your arguments.
If that does not change anything try with the normal vectors, aggr, etc. i.e, 'VECTORS AGGRESSION=8 WORKSIZE=256'
That memory sounds awfully high for running vectors2 as well. Though if it worked for you in the past then it may not be the issue. I would try lowering it to about 800 if using vectors2