Bitcoin Forum
December 11, 2016, 06:13:53 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 [407] 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2035555 times)
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
March 25, 2014, 06:42:56 AM
 #8121

By MPPS do you mean eligius? Eligius is not in credit,

Since you're discussing the expected value and infinite time

Actually my statement was about finite time, not infinite time.

As far as eligius having a credit in the future, that's all well and good, but it doesn't have one right now and won't have one any time soon. For all we know eligius may change its payout method at some point in time.

My statement was correct at the time it was made and will almost certainly be correct in a year. I make no promises about some arbitrary time in the future when eligius has a 200+ block buffer.

When exactly was the last time eligius had a buffer btw?

EDIT:
Quote
If you are specifically referring to Eligius at this point in time, then of course the expected value of a share for the next round could less than B/D (although the 'filo' reward order makes that tricky to describe exactly)

The filo order doesn't matter. As long as there is a positive probability that the share won't be paid on this block (which there is), and  a positive probability that it still won't be paid on each successive block (which there also is), then it follows that the expected value is less than B/D in finite time.

Even in your cherry picked example of a large buffer this is still mathematically true, though the difference is obviously negligible.
1481436833
Hero Member
*
Offline Offline

Posts: 1481436833

View Profile Personal Message (Offline)

Ignore
1481436833
Reply with quote  #2

1481436833
Report to moderator
1481436833
Hero Member
*
Offline Offline

Posts: 1481436833

View Profile Personal Message (Offline)

Ignore
1481436833
Reply with quote  #2

1481436833
Report to moderator
1481436833
Hero Member
*
Offline Offline

Posts: 1481436833

View Profile Personal Message (Offline)

Ignore
1481436833
Reply with quote  #2

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

Posts: 1481436833

View Profile Personal Message (Offline)

Ignore
1481436833
Reply with quote  #2

1481436833
Report to moderator
1481436833
Hero Member
*
Offline Offline

Posts: 1481436833

View Profile Personal Message (Offline)

Ignore
1481436833
Reply with quote  #2

1481436833
Report to moderator
1481436833
Hero Member
*
Offline Offline

Posts: 1481436833

View Profile Personal Message (Offline)

Ignore
1481436833
Reply with quote  #2

1481436833
Report to moderator
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
March 25, 2014, 06:58:37 AM
 #8122

By MPPS do you mean eligius? Eligius is not in credit,

Since you're discussing the expected value and infinite time

Actually my statement was about finite time, not infinite time.

As far as eligius having a credit in the future, that's all well and good, but it doesn't have one right now and won't have one any time soon. For all we know eligius may change its payout method at some point in time.

My statement was correct at the time it was made and will almost certainly be correct in a year. I make no promises about some arbitrary time in the future when eligius has a 200+ block buffer.

When exactly was the last time eligius had a buffer btw?


My mistake. I thought that generalising the discussion (MPPS vs PPLNS) would be more interesting. Maybe should should make it clear (because it wasn't to me) that you meant "at this point in time" and that you don't know how long this statement might be true?

How can you be certain that this will be correct in one year? You don't know what the pool's hashrate will average over that time, and it has increased significantly recently. You need to specify the number of blocks over which your estimate takes place.

"Almost certainly correct" is a strong assumption. At the moment Eligius has a 48 block queue, and there's a thirty percent chance of that becoming a positive buffer in the next twelve months if Eligius maintains it's current fraction of the network (assuming 0.14 of the network for the next 52 weeks and average weekly block rate is the current 1150 blocks). I'd say "probably correct" or "has a 70% chance of being correct" but I would almost certainly not say "almost certainly correct".





Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
March 25, 2014, 07:04:20 AM
 #8123

At the moment Eligius has a 48 block queue,

Are you confusing the payout queue with the shelved share log? I don't think the latter is public, but I'd be interested if it were.

The payout queue has nothing to do with the expected payout for shares, as far as I know.

Also, I'm also interested in thinking about MPPS compared to p2pool's PPLNS if you define what MPPS is. Is that the Eligius payout method? They call it CPPSRB. Is that the same thing you are calling MPPS?
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
March 25, 2014, 07:25:11 AM
 #8124

At the moment Eligius has a 48 block queue,

Are you confusing the payout queue with the shelved share log? I don't think the latter is public, but I'd be interested if it were.

The payout queue has nothing to do with the expected payout for shares, as far as I know.

The payout queue doesn't include shelved shares? How the hell are you supposed to keep track of the pool's progress then? Piecemeal payout functions annoy me, which is partly why I'm trying to goad you into providing a formal description of it (so I don't have to). Unfortunately it looks like I've failed. However my statement is probably true for *MPPS, but the order of payment varies between variants so I'm not sure. It is certainly true for SMPPS. Given your statement above, I'm now not sure if it's true for CPPSRB.


Also, I'm also interested in thinking about MPPS compared to p2pool's PPLNS if you define what MPPS is. Is that the Eligius payout method? They call it CPPSRB. Is that the same thing you are calling MPPS?

Ah well, there I'm on firmer ground. Also much lazier ground since the some of the work has been done. MPPS reward methods are described quite clearly in Chapter 4 here: https://bitcoil.co.il/pool_analysis.pdf

You'll immediately see the similarity and why CPPSRB could be considered an MPPS variant reward method. You'll probably be able to explain to me better why my explanations are incorrect, if they are.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
March 25, 2014, 07:28:14 AM
 #8125

The payout queue doesn't include shelved shares?

There is no transparency with respect to shelved shares as far as I know.

Quote
How the hell are you supposed to keep track of the pool's progress then?

Good question but why are you asking me? I'm not an operator of Eligius. At this point I'm only just barely a user.

Quote
Also, I'm also interested in thinking about MPPS compared to p2pool's PPLNS if you define what MPPS is. Is that the Eligius payout method? They call it CPPSRB. Is that the same thing you are calling MPPS?
Ah well, there I'm on firmer ground. Also much lazier ground since the some of the work has been done. MPPS reward methods are described quite clearly in Chapter 4 here: https://bitcoil.co.il/pool_analysis.pdf

You'll immediately see the similarity and why CPPSRB could be considered an MPPS variant reward method. You'll probably be able to explain to me better why my explanations are incorrect, if they are.

I'll take look, sounds interesting.
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
March 25, 2014, 07:45:37 AM
 #8126

The payout queue doesn't include shelved shares?

There is no transparency with respect to shelved shares as far as I know.

Quote
How the hell are you supposed to keep track of the pool's progress then?

Good question but why are you asking me? I'm not an operator of Eligius. At this point I'm only just barely a user.

http://en.wikipedia.org/wiki/Rhetorical_question

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
March 25, 2014, 07:50:36 AM
 #8127

The payout queue doesn't include shelved shares?

There is no transparency with respect to shelved shares as far as I know.

Quote
How the hell are you supposed to keep track of the pool's progress then?

Good question but why are you asking me? I'm not an operator of Eligius. At this point I'm only just barely a user.

http://en.wikipedia.org/wiki/Rhetorical_question

Fair enough, but I'm not sure what formal description you want. It seems fairly clear to me from the description on their web site.

Also, I do agree that it is similar in some ways to MPPS. I can't remember what the point of that was supposed to be though.

With respect to SMPPS, Meni agreed with my statement in the document you linked:

Quote from: Meni
While the expected payout per share is, in theory, fixed, the maturity time is not.

My position has been, and continues to be, that this applies to CPPSRB as well.

roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
March 25, 2014, 02:05:27 PM
 #8128

I managed to dig up a comment I remember Meni making on CPPSRB here:

https://bitcointalk.org/index.php?topic=32814.msg3419057#msg3419057

Since it's hoppable ("broken") and similar to other PPS methods, he'll likely never go back to address it directly in his analysis paper.

RoyalMiningCo: Pools retired. Was fun!
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
March 25, 2014, 04:50:54 PM
 #8129

I managed to dig up a comment I remember Meni making on CPPSRB here:

https://bitcointalk.org/index.php?topic=32814.msg3419057#msg3419057

Since it's hoppable ("broken") and similar to other PPS methods, he'll likely never go back to address it directly in his analysis paper.

I hadn't seen that but you and I both made the same point here.

Having said that I don't think Eligius is really hopable in practice (except maybe by just hopping away and staying away) because it has not had a buffer in recent memory and will very likely not have one in the foreseeable future.

I have largely shifted my mining away from eligius (I guess I'm a pool hopper!), I now use it only as part of a mix to reduce variance.
roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
March 28, 2014, 01:49:07 AM
 #8130

So I was working on one of my nodes this evening. I noticed the share targets were massively too high on my Uno node. Turns out dust threshold was set too high for a coin with a (currently) .25 block reward. I tweaked that around some so it was working better, and noticed some other things. This is my node:

http://us-east.royalminingco.com:9655/static/

I'm mining with about 1/4 of the pool power, I have my diff set to /64000 to help keep minimum diff low for smaller miners. The smaller guys on there at the moment as I post, from my debugging related to the dust issue, have their share targets set to hit a share every 30 minutes. I've seen from other alt coins that the networks.py settings basically end up where miners all get set (if they have the hash power to avoid dust issues) to the same time per share. I've never researched what formula feeds that yet though.

With the 30x diff cap, my target drops to a small fraction of the /64000. I'm finding, at the moment, 1 share per 1.5 minutes. The pool will find a block once per hour. So I'll have about 40 shares in the time we find a block. The other guys will have about 2 shares.

I'm wondering a couple things. Is there any problems if I just up or remove the 30x cap on my node? I honestly wouldn't mind averaging 2-3 shares per block like the other smaller miners, which would reduce the minimum share diff even further. In fact, if I remove the cap totally, I bet the vardiff would target me to 30 minutes per share just like the other 2 miners, meaning I'd be about 20x higher diff target than I am right now (which is 30x cap, so about 600x the minimum difficulty). I'm curious why that cap was put into place originally.

Also, when the expected value is generated for the dust calculations, is that based on the expected value of a single share or the expected value of the average # of shares a miners will have at any given time in the share chain? I assume the latter, just want to be sure without reverse engineering how the math is calculated in that function. Wink

RoyalMiningCo: Pools retired. Was fun!
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
March 28, 2014, 01:58:26 AM
 #8131

So I was working on one of my nodes this evening. I noticed the share targets were massively too high on my Uno node. Turns out dust threshold was set too high for a coin with a (currently) .25 block reward. I tweaked that around some so it was working better, and noticed some other things. This is my node:

http://us-east.royalminingco.com:9655/static/

I'm mining with about 1/4 of the pool power, I have my diff set to /64000 to help keep minimum diff low for smaller miners. The smaller guys on there at the moment as I post, from my debugging related to the dust issue, have their share targets set to hit a share every 30 minutes. I've seen from other alt coins that the networks.py settings basically end up where miners all get set (if they have the hash power to avoid dust issues) to the same time per share. I've never researched what formula feeds that yet though.

With the 30x diff cap, my target drops to a small fraction of the /64000. I'm finding, at the moment, 1 share per 1.5 minutes. The pool will find a block once per hour. So I'll have about 40 shares in the time we find a block. The other guys will have about 2 shares.

I'm wondering a couple things. Is there any problems if I just up or remove the 30x cap on my node? I honestly wouldn't find averaging 2-3 shares per block like the other smaller miners, which would reduce the minimum share diff even further. In fact, if I remove the cap totally, I bet the vardiff would target me to 30 minutes per share just like the other 2 miners, meaning I'd be about 20x higher diff target than I am right now (which is 30x cap, so about 600x the minimum difficulty). I'm curious why that cap was put into place originally.

Also, when the expected value is generated for the dust calculations, is that based on the expected value of a single share or the expected value of the average # of shares a miners will have at any given time in the share chain? I assume the latter, just want to be sure without reverse engineering how the math is calculated in that function. Wink

I don't see a reason to use any parms to control the pseudo difficulty sent to your miner.  I'm pretty sure that has zero affect on the pool share difficulty, that is, the minimum share difficulty required to get on the p2pool altchain.  I agree with you, with vardiff, chances are you'll get bumped up to a decent pseudo share size pretty quickly.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
March 28, 2014, 02:09:59 AM
 #8132

I don't see a reason to use any parms to control the pseudo difficulty sent to your miner.  I'm pretty sure that has zero affect on the pool share difficulty, that is, the minimum share difficulty required to get on the p2pool altchain.  I agree with you, with vardiff, chances are you'll get bumped up to a decent pseudo share size pretty quickly.

M

I'm talking about using / which adjusts actual share difficulty to find shares on the sharechain, not + which are the pseudo shares. It does have a rather huge impact on small networks. If I go the opposite way and mine with /1 so I'm always at the minimum, I can skyrocket the minimum share difficulty for the network. Noticing my impact on it when I first set the node up is what prompted me to always max out when I join in.

RoyalMiningCo: Pools retired. Was fun!
roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
March 28, 2014, 03:28:00 AM
 #8133

So a followup to my earlier questions. From IRC forrestv mentioned the 30x cap is a hard coded limit that other nodes will enforce, so I can't raise it on my own node without the other nodes rejecting my shares. Also, the dust threshold works so that each share you find will be above the dust threshold, not based on the average actual payout you'll receive based on average # of shares in chain.

RoyalMiningCo: Pools retired. Was fun!
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
March 28, 2014, 05:45:55 AM
 #8134

I don't see a reason to use any parms to control the pseudo difficulty sent to your miner.  I'm pretty sure that has zero affect on the pool share difficulty, that is, the minimum share difficulty required to get on the p2pool altchain.  I agree with you, with vardiff, chances are you'll get bumped up to a decent pseudo share size pretty quickly.

M

I'm talking about using / which adjusts actual share difficulty to find shares on the sharechain, not + which are the pseudo shares. It does have a rather huge impact on small networks. If I go the opposite way and mine with /1 so I'm always at the minimum, I can skyrocket the minimum share difficulty for the network. Noticing my impact on it when I first set the node up is what prompted me to always max out when I join in.

really?  that's interesting.  I would think the min sharechain difficulty is based on bandwidth or size of shares.. not time of shares. 

that's a bit illogical imho.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
GrapeApe
Sr. Member
****
Offline Offline

Activity: 477



View Profile
March 28, 2014, 06:04:47 AM
 #8135

Hey how long are the p2pool shares valid for?
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
March 28, 2014, 09:48:50 AM
 #8136

I don't see a reason to use any parms to control the pseudo difficulty sent to your miner.  I'm pretty sure that has zero affect on the pool share difficulty, that is, the minimum share difficulty required to get on the p2pool altchain.  I agree with you, with vardiff, chances are you'll get bumped up to a decent pseudo share size pretty quickly.

I'm talking about using / which adjusts actual share difficulty to find shares on the sharechain, not + which are the pseudo shares. It does have a rather huge impact on small networks. If I go the opposite way and mine with /1 so I'm always at the minimum, I can skyrocket the minimum share difficulty for the network. Noticing my impact on it when I first set the node up is what prompted me to always max out when I join in.

really?  that's interesting.  I would think the min sharechain difficulty is based on bandwidth or size of shares.. not time of shares. 

that's a bit illogical imho.

To elaborate on my illogical response...

things that don't make sense to me:

- You adjust your pseudo share size to adjust the share difficulty on the pool.  That means you get less shares, which means you keep less payout.  Why do that?  Wouldn't you be better off pointing 10% of your hashrate to the pool and the other 90% somewhere else?
- Unless sharesize matters when you adjust your pseudo share size.  If sharesize does matter, then how can it not affect the share difficulty if 6 small shares an hour or one large share every hour has the same result?
- If the time between shares affects share difficulty, that means it's based entirely on luck!  If the pool hashrate remains constant, and luck goes sour and people start getting less shares, does the share difficulty suddenly decrease?  Likewise, if luck increases, does share difficulty increase?

It makes more sense for it to be based on pool hashrate.

Maybe I'm missing something...

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
PatMan
Hero Member
*****
Offline Offline

Activity: 924


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
March 28, 2014, 11:50:07 AM
 #8137

Hey how long are the p2pool shares valid for?

3 days I think  Smiley

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
March 28, 2014, 02:49:25 PM
 #8138

To elaborate on my illogical response...

things that don't make sense to me:

- You adjust your pseudo share size to adjust the share difficulty on the pool.  That means you get less shares, which means you keep less payout.  Why do that?  Wouldn't you be better off pointing 10% of your hashrate to the pool and the other 90% somewhere else?

Pseudo share size has nothing to do with share difficulty on the pool or payouts. Those are the little Accept X/Y your miner prints every few seconds or so. It just lets the pool know you are alive and plot graphs, etc. To actually get paid you need to submit a share where the difficulty is higher than the minimum share difficulty for the pool (or higher than your share difficulty target if it's higher than the minimum).

To get more or less pseudo shares you use +. For instance, if you run a local node you could spam it with tiny shares by adding +1 to your payment address. Has no effect on income.

To get more or less real shares you use /. Any /DIFF set below the network minimum is ignored, and your target diff to get on share chain is the minimum. Any /DIFF higher than the network minimum means you'll get on the share chain less often, but the shares are more valuable (your target share difficulty is the value stored to calculate your payout, all shares on share chain do not have equal value, maybe this is your confusion?). The maximum target diff you can set is 30x the network minimum. If you set it higher, it'll adjust every time the minimum target adjusts.

- Unless sharesize matters when you adjust your pseudo share size.  If sharesize does matter, then how can it not affect the share difficulty if 6 small shares an hour or one large share every hour has the same result?

In a normal PPLNS pool, the payment window is all of the shares of work submitted (what p2pool calls pseudo shares), and there is only one type of share. All work submitted is logged and is in the payment window for a certain amount of work N. N is usually some multiple of the coin's difficulty.

In p2pool, the shares a normal pool would count are ignored and only shares of a certain difficulty target are counted. This is because there's no central database to record all of the info. We're decentralized and nodes can't trust each other. So the payment database, instead of being MySQL or similar, becomes a bitcoin style block chain, we call it the share chain. The share chain contents are the PPLNS payment database for p2pool. It has a specific target speed just like bitcoin. The share chain target is 30 seconds. The minimum difficulty to get a share onto the share chain is adjusted similar to bitcoin's difficulty algorithm, so the share chain grows by one share (block) every 30 seconds.

So the minimum difficulty for shares to get on the share chain is soley a factor of time. How long is it taking to add shares to the share chain? Just like bitcoin itself, the diff adjusts so the target rate is hit. The contents of the shares on the share chain don't matter.

(Side note: It's endlessly confusing that "share" might be a pseudo share, a real paying share that is recorded on share chain, or a "block" on the p2pool sharechain.)

So your question above, if you are talking about pseudo shares, it doesn't matter.

The issue is that the share chain has a finite number of "shares" (blocks) available. When it's full the older ones are expired. Even if the luck has been bad pool hash rate has dropped to where we aren't finding N work before the share chain length maximum is hit, opposed to the PPLNS window on a normal pool would still be counting those shares. This is a separate issue/concern of mine.

To even get on the share chain at all, you need to find a share (in your client) with a difficulty that is higher than your target share difficulty. I'll give an example below.

- If the time between shares affects share difficulty, that means it's based entirely on luck!  If the pool hashrate remains constant, and luck goes sour and people start getting less shares, does the share difficulty suddenly decrease?  Likewise, if luck increases, does share difficulty increase?

Yes, and this is exactly how bitcoin works as well. Difficulty is set based on actual shares found. Real hash rate doesn't matter, it's only the observed hash rate from actual found blocks that changes the difficulty target.

So why bother with /DIFF and using a higher one than you need to? Take a small coin with a p2pool share chain target of 1 minute, and two miners:

If Miner A has speed S and miner B has speed 99*S and are both mining on the p2pool node with the same difficulty targets (for simplicity ignore there being a vardiff, say both miners use /1, and the minimum share diff is a tiny number like on a scrypt coin) then A will find 1 out of every 100 shares and B will find 99 out of every 100 shares in some period of time. We want to find one share per minute for the share chain, so the minimum network difficulty will adjust so that shares come in once a minute. Thus, miner A finds 1 share every 100 minutes and miner B finds 99 shares every 100 minutes. As the p2pool network speed (or just miner B's speed) grows, miner A's rate of finding shares will get slower and slower. These shares all have a value of "1" for our example.

If a paying block is found when we have these 100 shares in the share chain:
Miner A is paid 1 * 1 / 100 of the block reward = 1%
Miner B is paid 99 * 1 / 100 of the block reward = 99%

(The math is # of shares * value of shares / total share chain value, assuming each of a miner's shares have same value, it's actually a sum of each individual share value in practice.)

Now let's say miner B feels bad for miner A and wants to help reduce his variance on when he gets paid. So whereas miner A might be mining diff 1 shares, miner B is going to change over to ADDR/99 to mine diff 99 shares. There is a 30x cap, so p2pool will actually make /30 the maximum it will use.

Now, in a specific period of time, miner A will find S shares  and miner B will find 3.3*S shares (since his diff target is 30 times higher vs his 99x faster speed). With the network difficulty from up above, A is still finding 1 share every 100 minutes but now B is only finding 3.3 shares every 100 minutes instead of slightly less than 1 per minute. This means the share chain is way too slow. Network minimum difficulty will drop until both miners combined average 1 share per minute. Once adjusted, in this 100 minutes of much lower minimum difficulty, miner A will find about 23.25 shares for every 76.75 shares miner B finds (please pretend we can have fractional shares to make the math clean).

The advantage is that miner A now finds shares on the share chain every 4.3 minutes (100/23.25) instead of one every 100 minutes. You can see that's a massive drop in his wait time. Miner B only goes up to about 1.3 minutes per paying share. What happens to the payouts?

The total value of shares on the share chain are 23.25 * 1 + 76.75 * 30 = 2325.75

Miner A is paid 23.25 * 1 / 2325.75 of the block reward = 1%
Miner B is paid 76.75 * 30 / 2325.75 of the block reward = 99%

So the end result is that Miner B can increase his time per share from 1.01 minutes to 1.3 minutes in order to let Miner A drop his time per share from about 100 minutes to 4.3 minutes. The miners still make the same average income over time.

You can imagine how big this effect becomes between a large mining farm and a single 180GH Antminer S1 miner.

TLDR: Sorry.

RoyalMiningCo: Pools retired. Was fun!
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
March 29, 2014, 12:50:39 AM
 #8139

You can imagine how big this effect becomes between a large mining farm and a single 180GH Antminer S1 miner.

TLDR: Sorry.

Thanks for the detailed explanation.  I knew most of it already.  The part I definitely didn't know what that share size on the alt chain does matter.  That was one of the conclusions I'd reached when thinking about how changing your pseudo share size could help things.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
smoothrunnings
Hero Member
*****
Offline Offline

Activity: 546


View Profile
March 29, 2014, 03:07:48 AM
 #8140

Is anyone having issues with Bitcoind/Bitcoin-QT v0.9.0?

I updated my P2Pool to v0.9.0 and I am getting an error now after restarting the server that it's lost connection with Bitcoind. Yet up until this point, I upgraded it a day after v0.9.0 came out its been running fine and transactions have been flowing.

 

Pages: « 1 ... 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 [407] 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 ... 744 »
  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!