Topic: Neighbourhood Pool Watch - page 12. (Read 49925 times)

The whole discussion about SMPPS is based on:

The assumption that this is true:
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?

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.

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.

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.

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

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:

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

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

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

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.

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?

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%

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

From the post:


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

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

Some of these "distrust" votes do look fishy.

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

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.

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.

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

Nicely done.
Except for


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