[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[BG4]

I run a very stable node... It runs on a Duel Quad core Xeon U1 server with 24gigs of RAM...SSD hard drive... that is a pull from data center and bought from Ebay for $190....It checks for P2pool updates and automaticly pulls from git hub. that is the only time it reboots.....also with Battery backup ....I tryed to run on Atom duel processor. That build was a major fail....also tryed an i3 low power board...also was not up to the task...So I bit the bullit and went Big...I have not regretted it ...Props to Polrpaul for the build setup..... I also have a team speak server always running on  Amazon E2C ....for live chat...Any ones welcome .. just install team speak client... and point to

174.129.116.53    teamspeak server, We dont use voice ,just typing so no mic required

StangerG.mine.nu:9332    P2pool node... its in US, east coast......

[1714328651]

1714328651

[1714328651]

1714328651

[1714328651]

1714328651

[organofcorti]

Let's posit that both pools have the same expected value for a share given infinite time.

Let's further posit that shares are proportional to time. This is not exactly true, but it is close. If you do not like this equivalence, then you may modify my original statement to be that the payout for p2pool is greater over a finite number of shares.

The payout for a share is made over at most N shares for p2pool. Once N is reached your expected payout is equal to the expected value of the share. The payout for that same share on Eligius is made over a potentially infinite number of shares (blocks). Thus for any future share > N, e(p2pool) has an expected payout value of 0 and Eligius has some expected payout value > 0. Sp when we reach N (and for any finite number of shares >=N), the expected value paid out by p2pool is greater than the expected value paid out by Eligius, because Eligius still has some remaining expected payments > 0 while p2pool does not.

For shares < N it isn't as clear. I'm ignoring that case. If your window is less than N your expected payout for Eligius may in fact be higher, I'm not sure.

I'm really not sure if this is not clear to you or if you would just like to see it stated more formally.

I think if you're assessing the expected value over time for an MPPS variant reward method then you need to formally describe the state of the pool at the time the share is assessed. If the pool is in credit, then the expected value of the share will be 1.0 in finite time. If you are assuming the pool has no credit and no debit (starting state for this type of reward method) then you need to make that an explicit assumption.

[smooth]

Let's posit that both pools have the same expected value for a share given infinite time.

Let's further posit that shares are proportional to time. This is not exactly true, but it is close. If you do not like this equivalence, then you may modify my original statement to be that the payout for p2pool is greater over a finite number of shares.

The payout for a share is made over at most N shares for p2pool. Once N is reached your expected payout is equal to the expected value of the share. The payout for that same share on Eligius is made over a potentially infinite number of shares (blocks). Thus for any future share > N, e(p2pool) has an expected payout value of 0 and Eligius has some expected payout value > 0. Sp when we reach N (and for any finite number of shares >=N), the expected value paid out by p2pool is greater than the expected value paid out by Eligius, because Eligius still has some remaining expected payments > 0 while p2pool does not.

For shares < N it isn't as clear. I'm ignoring that case. If your window is less than N your expected payout for Eligius may in fact be higher, I'm not sure.

I'm really not sure if this is not clear to you or if you would just like to see it stated more formally.

I think if you're assessing the expected value over time for an MPPS variant reward method then you need to formally describe the state of the pool at the time the share is assessed. If the pool is in credit, then the expected value of the share will be 1.0 in finite time. If you are assuming the pool has no credit and no debit (starting state for this type of reward method) then you need to make that an explicit assumption.

By MPPS do you mean eligius? Eligius is not in credit, and even if it were I don't think the expected value would be 100% because the round may go on longer than the credit.

[organofcorti]

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

Since you're discussing the expected value and infinite time, I thought it would be better to refer to reward methods rather than specific pools - I would prefer it that a statement I make which is true now continues to be true later. 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). However your statement will not be true at some point in the future if the pool has a significant positive buffer.

and even if it were I don't think the expected value would be 100% because the round may go on longer than the credit.

It depends on how long the pool has been running. For example if the pool has solved ten thousand blocks, then there's a 1% chance that the average shares per round / mining difficulty = 0.9768837. In this case the pool is 231 block (or 5775 btc) in credit. The probability of the next block requiring 231*D shares to solve is 1 - exp(-231).

So in that case, the probability of a share not having an expected value of B/D is 0.00000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000004. A very small number you'll agree.

None of this proves you are wrong, but I don't think you have proved you are correct, either. I freely admit I'm cherry picking examples, but you're doing much the same if you're not deriving a formal result.

[smooth]

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:

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.

[organofcorti]

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".

[smooth]

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]

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.

[smooth]

The payout queue doesn't include shelved shares?

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

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.

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]

The payout queue doesn't include shelved shares?

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

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

[smooth]

The payout queue doesn't include shelved shares?

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

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:

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]

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.

[smooth]

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]

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.

[mdude77]

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.

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

[roy7]

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.

[roy7]

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.

[mdude77]

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

[GrapeApe]

Hey how long are the p2pool shares valid for?

[mdude77]

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