Bitcoin Forum
December 06, 2024, 01:02:35 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 ... 1154 »
  Print  
Author Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool  (Read 4382698 times)
crazydownloaded
Full Member
***
Offline Offline

Activity: 148
Merit: 100

Crazy!


View Profile
May 22, 2012, 07:16:46 AM
 #5181

Hi Slush, Hi Everyone,

Is waiting 100 confirmations really necessary? Did you ever saw a block with 10 or even 5 confirmations to be invalid?
Like many, I don't like waiting for confirmations... Blocks get confirmed ~20 hours after being discovered, I think this is way too much waiting...

Also, I hope DGM will come soon, because I don't like hoppers (but I like slush's pool, don't want to switch to ozcoin...)

Est. February 2012
ajstar
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
May 22, 2012, 11:53:51 AM
 #5182

Hi Slush, Hi Everyone,

Is waiting 100 confirmations really necessary? Did you ever saw a block with 10 or even 5 confirmations to be invalid?
Like many, I don't like waiting for confirmations... Blocks get confirmed ~20 hours after being discovered, I think this is way too much waiting...

Also, I hope DGM will come soon, because I don't like hoppers (but I like slush's pool, don't want to switch to ozcoin...)

What's the big deal? Mining is longterm business, couple of hours won't kill you.

Yes, there are pools that pay right after block discovery, but they are doing it at their own risk. Slush's pool is in this way very conservative (and this is IMHO good).

Maybe 50 would be enough, but that makes no difference though - 10 or 20 hours vs. weeks or months of mining....
crazydownloaded
Full Member
***
Offline Offline

Activity: 148
Merit: 100

Crazy!


View Profile
May 22, 2012, 12:00:25 PM
 #5183

What's the big deal? Mining is longterm business, couple of hours won't kill you.

Yes, there are pools that pay right after block discovery, but they are doing it at their own risk. Slush's pool is in this way very conservative (and this is IMHO good).

Maybe 50 would be enough, but that makes no difference though - 10 or 20 hours vs. weeks or months of mining....

No big deal, but comfort... It's useless to wait that much, even 10 confirmations (<2 hours !) is more than enough.
I guess a lot of people don't like to wait either, I've read some that don't mine at Slush because of this and the more hashing power Slush get, the better for us (less variance for everybody...).

Est. February 2012
slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
May 23, 2012, 09:58:14 AM
 #5184

No big deal, but comfort... It's useless to wait that much, even 10 confirmations (<2 hours !) is more than enough.

Well, then ask Satoshi why he defined 100 blocks for validation in Bitcoin protocol :-).

My original idea was to implement pooled mining with the same rules as original Bitcoin network, which I'm still keeping. But I agree that it has some PR drawbacks. I'll think about paying blocks faster...

CheezWiz
Newbie
*
Offline Offline

Activity: 31
Merit: 0



View Profile
May 24, 2012, 01:15:58 AM
 #5185

I like the wait... Something Zen about it I suppose...

I would imagine that is a built-in safety to better allow for the detection of fraud or manipulation.
Boognish
Newbie
*
Offline Offline

Activity: 55
Merit: 0



View Profile
May 24, 2012, 01:33:05 AM
 #5186

Can anyone explain the benefit of DGM over PPLNS?  Pool hopping is also prevented by PPLNS and seems like it would be much easier to implement.  From what I gather, DGM helps 'absorb' a little bit of variation but I would imagine that isn't as big a deal on a larger pool like Slush's. 
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1007


Poor impulse control.


View Profile WWW
May 24, 2012, 01:39:00 AM
 #5187

Can anyone explain the benefit of DGM over PPLNS?  Pool hopping is also prevented by PPLNS and seems like it would be much easier to implement.  From what I gather, DGM helps 'absorb' a little bit of variation but I would imagine that isn't as big a deal on a larger pool like Slush's. 

PPLNS is a subset of DGM solutions. DGM has much more flexibility than PPLNS: variance and maturity time can be tuned to the miners' and pool op's needs and wants. PPLNS cannot.

All of the info (not just my interpretation of it) is here.

Btw there are a number of DGM pools now, so it can't be too much harder than PPLNS to implement here - especially when Slush has more experience than anyone at running a pool using exponential scoring).

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
May 24, 2012, 05:55:14 AM
 #5188

...so it can't be too much harder than PPLNS to implement here - especially when Slush has more experience than anyone at running a pool using exponential scoring).

The main difference between current score implementation is that score equation needs only time as an input, but proper implementation of DGM need to know also count of already submitted shares (across all backends). Pool core is designed quite scalable, there's no online synchronization between backends necessary, but it goes against DGM requirements. And it's the pain and the reason why it takes so much time. Originally I expect that it won't be so hard, but I felt into solving strange threading issues (cause framework which I'm currently using doesn't natively support user's threads).

organofcorti
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1007


Poor impulse control.


View Profile WWW
May 24, 2012, 06:36:26 AM
 #5189

The main difference between current score implementation is that score equation needs only time as an input, but proper implementation of DGM need to know also count of already submitted shares (across all backends). Pool core is designed quite scalable, there's no online synchronization between backends necessary, but it goes against DGM requirements. And it's the pain and the reason why it takes so much time. Originally I expect that it won't be so hard, but I felt into solving strange threading issues (cause framework which I'm currently using doesn't natively support user's threads).

Thanks for your input there - it's interesting to know how the differences in payout implementation affect pool operators.

Would moving to PPLNS temporarily be a possibility? Or would you be changing one difficult to solve problem for another?

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
May 24, 2012, 07:00:09 AM
 #5190

Would moving to PPLNS temporarily be a possibility? Or would you be changing one difficult to solve problem for another?

At this moment is simplier to finish DGM than do all coding and testing for PPLNS and then DGM again...

slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
May 24, 2012, 08:29:08 PM
 #5191

I'll start linux kernel & database update in following 30 minutes. Unfortunately I need to stop application, expected downtime will be 20-30 minutes.

slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
May 24, 2012, 09:41:03 PM
 #5192

Ok, it's back up, downtime was 35 minutes.

jothan
Full Member
***
Offline Offline

Activity: 184
Merit: 100


Feel the coffee, be the coffee.


View Profile
May 25, 2012, 05:29:43 PM
Last edit: May 25, 2012, 07:22:55 PM by jothan
 #5193

...so it can't be too much harder than PPLNS to implement here - especially when Slush has more experience than anyone at running a pool using exponential scoring).

The main difference between current score implementation is that score equation needs only time as an input, but proper implementation of DGM need to know also count of already submitted shares (across all backends). Pool core is designed quite scalable, there's no online synchronization between backends necessary, but it goes against DGM requirements. And it's the pain and the reason why it takes so much time. Originally I expect that it won't be so hard, but I felt into solving strange threading issues (cause framework which I'm currently using doesn't natively support user's threads).

Can't you multiply (or add the logs) of all the "s" variables from all the backend nodes and then do the same for the per-user scores (sk) ?

It might work, but I suck at math, Meni may have an idea on how to algebrize that.

Edit: Just in case I was not clear, the idea would be to have each backend node do DGM independently and then multiply all the backend "s" together and all the backend "sk" together to estimate or compute the payout.

Bitcoin: the only currency you can store directly into your brain.

What this planet needs is a good 0.0005 BTC US nickel.
mem
Hero Member
*****
Offline Offline

Activity: 644
Merit: 501


Herp Derp PTY LTD


View Profile
May 27, 2012, 05:15:55 AM
 #5194

pool appears to be offline atm Sad

still first time Ive ever seen an outage on slush, finally had to configure a failover pool in cgminer.

slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
May 27, 2012, 06:50:52 AM
 #5195

Writing from mobile connection; i was fixing one issue on the server, sorry for short outage. Connection from here was incredibly laggy. I also stopped payouts, they'll be back on the evening UTC.

splitt
Newbie
*
Offline Offline

Activity: 12
Merit: 0


View Profile
May 27, 2012, 08:12:49 PM
 #5196

Hi. I noticed that recently there have been a lot of invalid blocks here on Slush.
Is that normal or just bad luck?
What is the average number of invalid blocks for, say, 30 days?

Thanks!
slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
May 28, 2012, 07:39:02 AM
 #5197

splitt, invalid ratio is slightly under 1% in long term average. Yes, in recent days there were some extra invalids, but as you can trace on blockchain.info, it was really just bad luck, there isn't any obvious mistake. Pool is also directly connected to some well propagated nodes and also to few other pools to minimize latency.

slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
May 28, 2012, 07:39:59 AM
 #5198

Payouts are still disabled, I came at home too late and it's always better to be fresh while handling with coins. I'm working on fix right now and payouts should be enabled very soon.

slush (OP)
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
May 28, 2012, 07:56:10 PM
Last edit: May 29, 2012, 06:19:11 AM by slush
 #5199

OK, BTC payouts working again (I just sent batch of all pending payouts), I'm working on NMC now.

Edit: NMC payouts works as well.

Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1054



View Profile WWW
May 30, 2012, 01:20:27 PM
 #5200

Can anyone explain the benefit of DGM over PPLNS?  Pool hopping is also prevented by PPLNS and seems like it would be much easier to implement.  From what I gather, DGM helps 'absorb' a little bit of variation but I would imagine that isn't as big a deal on a larger pool like Slush's. 
PPLNS can work too, but there are a few differences to consider:
1. What most people refer to as PPLNS is the naive variant which isn't completely hopping-proof. There are correct variants but they're slightly harder to implement.
2. PPLNS is potentially more resource-intensive, as it requires a history of shares - DGM only strictly requires keeping track of the score of every miner.
3. DGM can absorb variance, which may or may not be needed or used but it's nice to have the option.
4. In DGM the decay is gradual rather than abrupt, this can be seen as a pro or a con depending on taste.

There's also shift-PPLNS and shift-DGM which work better with a parallel architecture.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
Pages: « 1 ... 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 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 ... 1154 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!