Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Actually it's a simple CDF calculation that shows how bad it is to limit block sizes to taking an exorbitant 5 minutes to get to 1MB ...
5 minutes is a 50% block on an expected 10 minute network.
So the CDF is 0.39346934028737 or 1 in 1.6 blocks (60.65%) will be over 5 minutes
or reversing that ... 1 in 2.54 blocks (39.3%) will be under 5 minutes ... yeah that's a big % of blocks, not "albeit a small one" at all.
I'm often surprised at how little maths people understand about Bitcoin when they are considered experts in it ... and/or spending money mining on it ...
Note of course, this last comment is directed at someone else not you ...
can you show me the algebraic formula so I can understand it better ....
Hello,
The Bitcoin mining process can be modelled as a Poisson process. From this we can calculate the probabilistic interarrival times (the time between two events, here finding of two blocks), which are exponentially distributed with lambda = 1/600. The probability of getting interarrival times (IAT) larger than 5 min or 300 sec is: Pr{IAT > 300} = e^(-300/600) ≈ 0.60653 = 60.65%. So the probability of getting two blocks less than 300 sec from each other is: Pr{IAT < 300} = 1 - Pr{IAT > 300} ≈ 0.39347 = 39.34%. This is the probability of the Bitcoin network finding a block in less than 300 sec from the previous one.
We can off course do the same for P2pool. The probability that the P2pool network finds a block less than 300 sec from the other is (assuming P2Pool has 0.1% of the total hashing power of the Bitcoin network, which is more than it currently has): lambda is now 1/600000. Pr{IAT < 300} = 1 - e^(-300/600000) ≈ 0.0005 = 0.05%.
(This is an exercise I did for my self. It may contain errors related to how P2pool works. If I made errors please make me aware of them so I can learn from it.). We can also find the expected number of KBs that P2pool can add to the block if P2pool finds a block after 5 min, assuming 100 KB per share, and no difficulty change of the dynamic difficulty adjustment mechanism, and after the last found block by the network, P2Pool had to start again from scratch, meaning 0 KBs). As explained above the finding of shares is also a Poisson process. The probability to find no shares in an interval of length 300 sec is: Pr(N(300) = 0) = (((300/30)^0)/0!)*e^(-300/30) ≈ 0.00005. In this case P2pool will add 0 KBs to a block. We can continue this until an ridiculous and irrelevant number of shares, so I will truncate it at 20 shares:
Pr(N(300) = 1) ≈ 0.00045 100KB
Pr(N(300) = 2) ≈ 0.00227 200KB
Pr(N(300) = 3) ≈ 0.00757 300KB
...
Pr(N(300) = 9) ≈ 0.12511 900KB
Pr(N(300) = 10) ≈ 0.12511 1000KB
Pr(N(300) = 11) ≈ 0.11374 1100KB
...
Pr(N(300) = 19) ≈ 0.00373 1900KB
Pr(N(300) = 20) ≈ 0.00187 2000KB
From these results we can calculate the weighted average: 996.55KB. So if a Bitcoin block is found by P2pool 300 sec after the previous than the expected amount of KBs in that block is 996.55KB.
I hope this clarifies a thing or two. Or if you find errors please make me aware of them so I can learn from it.
If p2pool happens to get two in a row at the moment, well, good to know, the chance of that is simply the size of p2pool over the whole network
The point of the problem is that standard p2pool will only allow to add 100KB per 30 seconds given 30 seconds is the expected time per share-chain share.
That's a simple linear function ... 300s = 30s x 10 = 100KB x 10 = 1MB
Until 300s it's not expected to be a full block, thus the CDF comes into play to simply say that 39.3% of blocks found on p2pool will be 900KB or less.
Most everyone on the bitcoin network itself is expected to use up the same best transactions each block found and thus all pools including p2pool should normally reset back to zero when a block is found, but then again, as before, p2pool will produce, on average, a 100KB block at the first 30s after any previous block, no matter who found it - p2pool or someone else. That's not the case by design of a 'standard' pool, though a lot of pools create empty or partial blocks in the first work generated after a block, but then switch to a full block very shortly after that.
As for the CDF, it's simply the area under the poisson distribution curve - which you normally integrate a function to get the area under a curve, but in the case of the poisson there's simple approximates to calculate it given certain limitations.
The simplest calculation is (1 - e^(-x)) where x is the ratio - e.g. 50% = 0.5
As long as x isn't too small, this gives a good approximate.
i.e. 1 - e^(-0.5) = 0.393... or 39.3%
... thus a simple (and correct) explanation
