Neighbourhood Pool Watch

[m3ta]

Previous posts:
Neighbourhood Pool Watch 2.1 Deepbit

Nicely done.
Except for

being honest with it's statistics

But because more than 90% of the universe is illiterate on the difference between "it's" and its", thumbs up anyway.

[organofcorti]

Previous posts:
Neighbourhood Pool Watch 2.1 Deepbit

Nicely done.
Except for

being honest with it's statistics

But because more than 90% of the universe is illiterate on the difference between "it's" and its", thumbs up anyway.

Fixed! Thanks for reading so carefully. Feeling like being a proof reader, m3ta? I hate hassling Mobius all the time.

[organofcorti]

Hey so who are the six that don't trust EMC?  I'd certainly like to address any issues with that, as I try to be as open as possible with everything I do with regards to the pool.  If there's something that is questionable, I will certainly address it.

Odds on it's just disgruntled miners with an axe to grind, or as Goat suggested other pool ops who can't DDOS anymore. I wouldn't worry about it - you and Ozcoin have great reps for openness and reliability.

[organofcorti]

Hey so who are the six that don't trust EMC?  I'd certainly like to address any issues with that, as I try to be as open as possible with everything I do with regards to the pool.  If there's something that is questionable, I will certainly address it.

Also, realise, as I mentioned further up and you can read elsewhere on the forum, P2Pools advocacy of saying that non-P2Pool pools are not trustworthy will obviously imply that those who agree with that will not trust any pool but P2Pool and thus any of them could choose any pool to list as untrustworthy.

I don't think trust is a binary concept - you don't only 'completely trust' or 'completely distrust' anything or anyone. So p2Pool not requiring trust (if you've read the code) doesn't automatically mean you 'completely distrust' other options. So p2Pool advocates are being misleading, and if they are selecting random pools to distrust, or have selected 15 pools other than p2Pool to distrust, then they are being disingenuous or have a poor grasp of logic.

I'll normalise to the lowest distrust level anyway, so they won't have an effect unless they're targeting a particular pool out of spite.

[Brunic]

Hey so who are the six that don't trust EMC?  I'd certainly like to address any issues with that, as I try to be as open as possible with everything I do with regards to the pool.  If there's something that is questionable, I will certainly address it.

Don't worry, your pool is great. For my part, I wanted to see the results of the poll, and voted for everybody so to not screw the % of the votes (well, except one pool, since you can only choose 15 on 16).

[Clipse]

Hey so who are the six that don't trust EMC?  I'd certainly like to address any issues with that, as I try to be as open as possible with everything I do with regards to the pool.  If there's something that is questionable, I will certainly address it.

Also, realise, as I mentioned further up and you can read elsewhere on the forum, P2Pools advocacy of saying that non-P2Pool pools are not trustworthy will obviously imply that those who agree with that will not trust any pool but P2Pool and thus any of them could choose any pool to list as untrustworthy.

I don't think trust is a binary concept - you don't only 'completely trust' or 'completely distrust' anything or anyone. So p2Pool not requiring trust (if you've read the code) doesn't automatically mean you 'completely distrust' other options. So p2Pool advocates are being misleading, and if they are selecting random pools to distrust, or have selected 15 pools other than p2Pool to distrust, then they are being disingenuous or have a poor grasp of logic.

I'll normalise to the lowest distrust level anyway, so they won't have an effect unless they're targeting a particular pool out of spite.

Some of these "distrust" votes do look fishy.

[organofcorti]

Hey so who are the six that don't trust EMC?  I'd certainly like to address any issues with that, as I try to be as open as possible with everything I do with regards to the pool.  If there's something that is questionable, I will certainly address it.

Don't worry, your pool is great. For my part, I wanted to see the results of the poll, and voted for everybody so to not screw the % of the votes (well, except one pool, since you can only choose 15 on 16).

Results now available without voting. Hopefully no more donkey votes.

[organofcorti]

Next post available: 3.1 The rise and fall of Arsbitcoin.com

From the post:

6. Conclusions.

• Public perception of the pool operator and the pool is positive and miners there seem to trust the pool operator.
• The pool operator is not publicly identifiable.
• The pool has been very popular in the past with few complaints until problems began to occur in November 2011.
• Arsbitcoin.com has a large negative buffer and a falling hashrate - two very big problems for an SMPPS pool.
• The pool op, Burning Toad, is currently unable to keep the pool running smoothly, as evidenced by the Arsbitcoin.com thread on bitcointalk.org and the round length anomalies described in this post.
• Next post will cover the problems with the SMPPS system.

I'm hoping for some debate on this one, from Arsbitcoin.com partisans and SMPPS fanciers alike.

[kano]

...
I'm hoping for some debate on this one, from Arsbitcoin.com partisans and SMPPS fanciers alike.

So ... what am I missing if I say that a 'zero fee' SMPPS pool should just put 1.5% of each block into the buffer and pay 98.5% ?
i.e. the buffer loses out when you get an orphan, and the 'supposed' expected orphan rate is 1.5%

[organofcorti]

Thanks Kano. That will all be covered in the next post. BTW, Arsbitcoin.com records no orphaned/invalid blocks at all. I don't know if that's accurate or not. Where do you get your 1.5% stat from?

[kano]

Thanks Kano. That will all be covered in the next post. BTW, Arsbitcoin.com records no orphaned/invalid blocks at all. I don't know if that's accurate or not. Where do you get your 1.5% stat from?

Hmm good question
I'm sure I heard it indirectly from a Pool OP or 2 ... but I can't for the life of me remember who
I'll try a forum search ...
OK ABCProxy's web page says 1.5%
MintCondition also said it again in the ARS thread
and I think I remember seeing 1.0% written somewhere also ...
But any pool with a count of orphans can easily determine a % figure.

[organofcorti]

... if you trust their stats. Apparently arsbitcoin have had none at all, and it would be in ABC's interest to inflate orphaned block rates since their miners are paid regardless. Then again being a proxy pool, they'd probably follow all pool stats closely, so maybe its true.

Anyone have a citable source showing the average percentage of rounds orphaned?

[Graet]

173222    
Timestamp    2012-03-28 04:40:16
BTC Sent    9,755.133 BTC
N tx    67
Relayed By    Deepbit
   
Timestamp    2012-03-28 04:43:36
BTC Sent    9,742.691 BTC
N tx    72
Relayed By    Ars bitcoin

http://blockchain.info/orphaned-blocks
Ars had the second to last orphan on this page

was looking to see if they had stats on numbers of orphans

[organofcorti]

Thanks Graeme. At least we know they get orphans. I haven't found a definitive percentage figure yet though.

[organofcorti]

New Neighbourhood Pool Watch : 3.2 The risks of SMPPS

I was going to call it "The failure of SMPPS", but Eligius is still going so I thought that a bit premature. Please note that the post is due in part to Meni Rosenfeld's paper "Analysis of pooled bitcoin mining reward systems".

Here's a bit from the post for the purpose of appetite-whetting:

5. Conclusions

• The amount of time it takes for a miner to be paid is affected by the pool buffer:
  
• • A large negative buffer at will greatly increase the time it takes for a miner to be paid.
• • A buffer greater than zero minimises the time  it takes for a miner to be paid.
• A strategic miner will only mine at an SMPPS pool when it has a positive buffer.
• The probability of large negative buffer (that occurs some time before a a certain number of rounds) can be calculated and in the case of Arsbitcoin.com, a 1000 btc negative buffer before 1700 rounds is quite likely.
• The more blocks a pool solves, the more likely it is for a an SMPPS pool to encounter so large a negative buffer that it will fail, leaving miners with much less than a PPS payout per share.

[Graet]

Ars severs have been down over 24hours now. A lot of  miners joining IRC with questions :/

[kano]

Can the discussion include DGM? ...

I've yet to find a valid reason why DGM, which attempts to be SMPPS, is any better.

With SMPPS you can see the buffer, with DGM, you cannot since there 'apparently is no buffer' (there is no spoon? )

I've had this discussion with Meni in his thread, but been unable to see a valid reason for saying one is better than the other without using jargon to hide something that is effectively the same.

... and as I said above, regarding the issue of the buffer running out, and well, it will run out for what reasons?
The answer seems to be orphans (what other reasons?)
... and that can be solved by having a variation that puts the small % of expected lost BTC per block into the buffer.
A variation of that could even adjust that % based on history.

[Meni Rosenfeld]

Can the discussion include DGM? ...

I've yet to find a valid reason why DGM, which attempts to be SMPPS, is any better.

With SMPPS you can see the buffer, with DGM, you cannot since there 'apparently is no buffer' (there is no spoon? )

I've had this discussion with Meni in his thread, but been unable to see a valid reason for saying one is better than the other without using jargon to hide something that is effectively the same.

WTF???

In SMPPS the buffer affects the attractiveness of mining. Low (highly negative) buffer = miners will leave.

In DGM the "buffer" does not affect the attractiveness of mining. Thus there is no reason to know it, it's a property of the pool operator, not of the pool. I don't tell you how many bitcoins I own either.

In SMPPS there is debt which can go arbitrarily high. If the pool collapses while it is still in debt to you you are screwed (and this will happen when everyone leaves due to low buffer).

In DGM the debt is bounded and so the pool can (and should) pay back the debt if it closes for any reason.

In SMPPS the variance of the buffer is 100%, in DGM it can be controlled with a parameter.

The claim that DGM "attempts to be SMPPS" is outrageous.

As I said before, I'm extremely weary of having to deal with your hostility and explaining the same thing over and over again multiple times.



Anyway, as long as I'm here:

You talk about the maturity time, but it should be emphasized that the value I'm analyzing is the time of average payback, not the time of being paid in full. For example, if you get 50% of the debt back in 1 round and the other 50% in 3 rounds, your maturity time is 2 rounds.

The second chart, giving the PDF of the pool debt after n rounds, looks completely wrong, I have no idea how you got that. The pool debt, assuming constant difficulty, is (X/D - n)*B, where X is the number of shares it took to get n blocks, which is distributed negative binomial. So it's really a shifted negative binomial, which doesn't have the cusp we see.

[organofcorti]

... and as I said above, regarding the issue of the buffer running out, and well, it will run out for what reasons?
The answer seems to be orphans (what other reasons?)
... and that can be solved by having a variation that puts the small % of expected lost BTC per block into the buffer.
A variation of that could even adjust that % based on history.

I don't think you read the post. It explains why large negative buffers are quite likely the longer a pool goes on - without referring to orphaned blocks at all. Read it and get back to me.

[kano]

The whole discussion about SMPPS is based on:

The assumption that this is true:

If the pool stays in a large negative buffer long enough, it is a likely that all miners will leave, and the pool will fail.

Which we ALREADY know to be FALSE.

Is there a reason to suggest to people to consider reading the rest when the reality is that arsbitcoin has proven it false?

If, on the other hand, a modified SMPPS that takes the expected pool loss into consideration (e.g. determine the % of blocks expected to be orphaned and determine that based on history after some period of time) and that % is put back into the buffer, then in the long term the pool will be expected to be even and thus people knowing that rather than listening to the WILD negative false assumptions that even such a modified pool would fail, would not be running and screaming that the sky is falling every time the buffer went negative.

However ...

Meni loves to say that "there is no buffer" so I take that to mean that when I look at a DGM pool that is paying more than 50BTC per block in a bad luck streak, that pool is in fact in serious trouble and about to fail?
Since there is no buffer, how can they pay more than 50BTC per block?