Bitcoin Forum
December 02, 2016, 06:34:40 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: What type of pool payouts do you prefer?
Bitcoins - 3160 (80.5%)
Bank transfer / USD - 407 (10.4%)
Gold/silver coins and bars - 359 (9.1%)
Total Voters: 3924

Pages: « 1 ... 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 [240] 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 ... 1105 »
  Print  
Author Topic: [40+ PH] SlushPool (slushpool.com); World's First Mining Pool  (Read 3924737 times)
gijs007
Newbie
*
Offline Offline

Activity: 17


View Profile
January 18, 2012, 11:44:33 PM
 #4781

Hmm I'm having issues again, using phoenix and phatk modified kernel: https://bitcointalk.org/index.php?topic=25135.0
 -k phatk DEVICE=0 VECTORS2 AGGRESSION=16 WORKSIZE=64 FASTLOOP=false
On a unlocked 6950, running at 930 mhz core and 1430 mhz memory.

It was working perfectly but yesterday my isp did some maintenance and now the program will only mine 9 shares and after that it "hangs"
I tried disabling long polling, went back to phoenix 1.7.2 and tried 2 different modified kernels.

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
I rebooted my pc, got a bsod, rebooted again and now its working fine again... odd Huh
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 19, 2012, 10:32:32 AM
 #4782

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

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 19, 2012, 10:34:28 AM
 #4783

feature request: payout time intervall

my problem is that i want a daily payout, i am doing this right now by setting payout_limit to 7day average, but i am a little unhappy that the intervall in which my payments get send is so variable

i would like somethink like
Quote
if last_payment_time + payment_timeintervall < actual_time && payout_limit > btc_balance then
PAYOUTTIME

i think that is the easiest way to explane about what i think, no language problems in code Cheesy
i think payment_timeintervall should be in days and the payout_limit which already can't be set under 0.01 afaik will secure that there aren't to tiny payouts

what do you think?

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

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 20, 2012, 03:37:51 PM
 #4784

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:

Code:
./poclbm.py --verbose -d 0 --proxy=localhost:9050 http://username.worker:password@pool57wkuu5yuhzb.onion:8332

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!

Sargasm
Member
**
Offline Offline

Activity: 112


View Profile
January 21, 2012, 02:58:19 AM
 #4785

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?
Sargasm
Member
**
Offline Offline

Activity: 112


View Profile
January 21, 2012, 03:04:10 AM
 #4786

Whatever it is... it is raping us.
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 21, 2012, 09:49:44 AM
 #4787

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

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.

Sargasm
Member
**
Offline Offline

Activity: 112


View Profile
January 21, 2012, 10:24:49 AM
 #4788

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
Member
**
Offline Offline

Activity: 112


View Profile
January 21, 2012, 10:30:40 AM
 #4789


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.

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.
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 21, 2012, 10:32:25 AM
 #4790

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.

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

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.

Sargasm
Member
**
Offline Offline

Activity: 112


View Profile
January 21, 2012, 10:35:59 AM
 #4791

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.

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?
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 21, 2012, 10:39:29 AM
 #4792

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

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

Sargasm
Member
**
Offline Offline

Activity: 112


View Profile
January 21, 2012, 10:52:24 AM
 #4793

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

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

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.
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 21, 2012, 11:40:34 AM
 #4794

Let's wait to DGM, ok?

rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
January 21, 2012, 08:43:28 PM
 #4795

Also... people that bail on long blocks would be penalized a bit.
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.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
Sargasm
Member
**
Offline Offline

Activity: 112


View Profile
January 21, 2012, 08:56:42 PM
 #4796

Also... people that bail on long blocks would be penalized a bit.
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.

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.
Sargasm
Member
**
Offline Offline

Activity: 112


View Profile
January 21, 2012, 08:59:54 PM
 #4797

Let's wait to DGM, ok?

Alrighty Smiley

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

Activity: 1988



View Profile
January 21, 2012, 10:26:24 PM
 #4798

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

allinvain
Legendary
*
Offline Offline

Activity: 1988



View Profile
January 21, 2012, 11:20:28 PM
 #4799

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.


martychubbs
Hero Member
*****
Offline Offline

Activity: 476



View Profile
January 22, 2012, 01:19:59 AM
 #4800

Let's wait to DGM, ok?

Alrighty Smiley

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

I take it you are not a hopper and don't really understand how it works.  However, slush's scored rewards are calculated differently than a straight up prop pool   So, Hopping rewards less in this pool.  Plus, hoppers like to mine at the highest efficiency possible, so the opportunity cost is higher for this pool than other prop (not scored) pools.  Also, the larger the pool is, the less variance hoppers can benefit from...and this is a large pool.

Reward methods like PPLNS and  DGM do a better job at fairness for the miners than something you just thought of...  Loyalty shares...does that mean I will get emails and a special card to shop with?  Will you get a bumper sticker, too?  I am not sure I understood you proposal, but I feel like we would have to wear some sort of name tag.  You should open up a new thread, explain it better and see if a pool will adopt it...?  You will get mega credit!!!
Pages: « 1 ... 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 [240] 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 ... 1105 »
  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!