Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 409. (Read 2591964 times)

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.



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.

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?

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

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:

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.

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.


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.

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.

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.

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

i have my own very stabile and effective node and don't need to look for other one. i just used for testing purposes other public nodes to have comparison to my own node also.
if i look this node than in the first moment it looks as they have to high dead rate and their efficiency is not at this moment very high neither. for my purposes some other nodes were better.

that is exactly what i was saying: one month is not enough to get real overview.
NMC/DVC/IXC amounts are already included to my total. this "extra money" is such marginal that it was for me even not worth to mention. per 1 BTC you usually mine round 2NMC so there it makes difference of 0.01BTC. IXC and DVC bring even less.

Thanks!

I don't know Acejam, but he runs a load balancing cluster of p2pool nodes here:

https://bitcointalksearch.org/topic/--422242

Remember this changes pseudo share difficulty to report to node, but doesn't change the share difficulty for actual shares on the share chain. For that you need to use /DIFF.

everything between 0.2 and 0.5 is OK. even 0.7 is ok if efficiency is round 100%.
going lower is just contra productive: you will get less fees and don't win anything.

Low latency is not the most important thing and tuning it very much down can bring many other problems like low shares, to high memory usage etc.

Thanks man.