Formula for calculating odds of blockchain reorg?

The following is wrong:

[quote=“pillow, post:66, topic:2518”]To calculate the odds of an attacker finding one block we first need to know something about what the attacker is up against:
coindaysOnMainChain = 4294901760 x proofOfStakeDifficulty / ( 60 * 600 )

Then if we know how many coins attacker has, we can calculate the maximum amount of coin days the attacker can use:
coindaysOfAttacker = coinsAttacker*90

Now we can calculate the odds of an attack successfully minting a new block:
attackerOddsOfSuccess = coindaysOfAttacker / ( coindaysOfAttacker + coindaysOnMainChain )

Now we can approximate the probability (see whitepaper for more details) of a deep reorganization like so:
deepReorgProbability = attackerOddsOfSuccess ^ ( z-1 )

Let’s plug in some numbers and see what happens. Given that the difficulty is 12.2, we get 4294901760 * 12.2 / ( 60 * 600) = 1455494.48533 coin days on the main chain. Suppose the attacker has 1% of the total supply of coins 21552942 * 0.01 = 215529.42, then given that the attacker has accumulated as much coin age as possible ( 90*215529.42 = 19397647.8 ), the odds of the attacker minting a block is 19397647.8 / ( 19397647.8 + 1455494.48533 ) = 0.93020263011. So, now we know that the attacker need 1% of all peercoins to mint a block with almost 100% certainty. At current market price of $1.48 it would cost about $318 983. It isn’t certain that the attacker will be able to find that many coins for sale at that price, but let’s say the attacker has those coins then what? As mentioned earlier, after the block has been minted the attacker now have to wait 30 days before the protocol allows those coins to be used to mint a new block. Meanwhile the attacker has 1% of all the coins locked in a stake and will be exposed to exchange risk for a period of time.

Obviosly we are still far from an attack. So what the attacker has to do, is to divide his coins into as many stakes as he want to mint blocks. Let’s say the attacker want to do a 6 deep block reorganization and divides the coin days used in the attack equally ( 90 * 215529.42 ) / 6 = 3232941.3 then all other things being equal the odds of finding a block is 3232941.3 / ( 3232941.3 + 1455494.48533 ) = 0.68955648494. It’s still fairly high, but remember that this is the odds of finding one block and the attacker need to find 6 consecutive blocks.

Accordingly to the formula the odds of this happening is 0.68955648494 ^ ( 6-1 ) = 0.1559011202. Since the coins in the stakes have to mature 30 days, the attacker can attempt this attack 2 times a year.[/quote]

Can you help me with the formula? I’ve studied many threads about this, but honestly I don’t trust that I’ve got a deep enough understanding to figure this out by myself.

Why?

coindaysOnMainChain = 4294901760 x proofOfStakeDifficulty / ( 60 * 600 )

I have been wondering where the above formula is from.

Why?

coindaysOnMainChain = 4294901760 x proofOfStakeDifficulty / ( 60 * 600 )

I have been wondering where the above formula is from.[/quote]

In some places I accidentally used “90” as max coin days ceiling, when it should be 60:

I got some help from josojo yesterday in the chat, who suggested that we should get some more eyes on it. The formula is from “a thread somewhere” but josojo has a spread cheat and when doing a little bit of verification, josojo found that when using 6 deep reorg (z = 6) the approximation is not good enough. Since its a formula, I guess it has to be kind of exact since we don’t know how its going to be used:

Great to see you participating in this thread!

The formulas below are for a simpler model than what would happen in reality (POW and chain trust not taken in consideration, POS block considered to be found exactly every 10 minutes…), however, I hope it will be useful anyway.

So, what is the probability for a minting attacker to reorganize the blockchain and change the last n blocks ?

The probability for some coins to pass the minting hash test is:

p = (coins * dayWeight) / (difficulty * 2^32)

When the coins have reached max age (90 days), dayWeight is 60:

p = (coins * 60) / (difficulty * 2^32)

The hash test is done every second, so the probability to mint a block within 10 minutes is:

p10 = 1 - (1 - p)^(60 * 10)
p10 = 1 - (1 - (coins * 60) / (difficulty * 2^32))^600

To reorganize the blockchain and change the last n blocks, an attacker will have to find n consecutive blocks. Let’s imagine that the attacker has c coins at least 90 days old distributed evenly in n transaction outputs of c/n coins each.
The probability of success is:

pn = p10^n
pn = (1 - (1 - p)^600)^n
pn = (1 - (1 - ((c / n) * 60) / (difficulty * 2^32))^600)^n
pn = (1 - (1 - (c * 60) / (n * difficulty * 2^32))^600)^n

Let’s take a few examples at current difficulty (12) with coins at least 90 days old.

[ul][li]3 blocks deep reorganization with 100000 coins: probability = 0.00122%[/li]
[li]3 blocks deep reorganization with 1000000 coins: probability = 0.897%[/li]
[li]3 blocks deep reorganization with 10000000 coins: probability = 73.6%[/li]
[li]6 blocks deep reorganization with 100000 coins: probability = 0.00000000024%[/li]
[li]6 blocks deep reorganization with 1000000 coins: probability = 0.000176%[/li]
[li]6 blocks deep reorganization with 10000000 coins: probability = 10.6%[/li]
[li]9 blocks deep reorganization with 100000 coins: probability = 0.00000000000000000987%[/li]
[li]9 blocks deep reorganization with 1000000 coins: probability = 0.00000000722%[/li]
[li]9 blocks deep reorganization with 10000000 coins: probability = 0.391%[/li][/ul]

If the attacker mints at least one block but not all the blocks he wanted, he will have to wait 90 days to try the attack again.

Hey, that’s excellent. I’ll just copy and paste that one into the myth thread. Thank you for really walking it through!

I guess the attacker could do the minting on a “hidden chain” and broadcast all blocks at once, thereby not exhausting coin days before he knows the attack is likely to be successfull. I also guess that this would also “sound the alarm” though (at least I know that Bitcoin have some kind of reorg listening thing that warns the user if the reorg is deep)?!

Thanks for the analysis. It’s in the right direction. I didn’t find apparent problem but from my measurement on Apr 27 an address with many mostly 100 - 1000 PPC unspent outputs was able to find 6 3-consecutive blocks in 5 days. The POS diff in the previous 5 days varied from 10.7 to 11.4 according to https://peerchain.co/charts . I plug the numbers to your formular for c=1000 and find that the probablity of finding a 3-chain is 10^-8 in the 5-day window, way smaller than the measured probablity ~3% (including one 4-chain counted as one 3-chain).

As explained in the post the address had enough small outputs of this kind so, even it mints 24 hours a day, it never uses up its mature outputs. Its queue of minting stakes is always much longer than 30 days, at the rate it finds blocks. so with its half million PPCs it finds blocks all the time.

So I am wondering in your model where does the total number of minting stakes on the network come in? Is it all encoded in the diff ?

Maybe you could parameterize the number of piles one can split his coins in your model so let’s see what the optimum way to accumulate POS reward is.

[quote=“mhps, post:6, topic:2668”]Thanks for the analysis. It’s in the right direction. I didn’t find apparent problem but from my measurement on Apr 27 an address with many mostly 100 - 1000 PPC unspent outputs was able to find 6 3-consecutive blocks in 5 days. The POS diff in the previous 5 days varied from 10.7 to 11.4 according to https://peerchain.co/charts . I plug the numbers to your formular for c=1000 and find that the probablity of finding a 3-chain is 10^-8 in the 5-day window, way smaller than the measured probablity ~3% (including one 4-chain counted as one 3-chain).

As explained in the post the address had enough small outputs of this kind so, even it mints 24 hours a day, it never uses up its mature outputs. Its queue of minting stakes is always much longer than 30 days, at the rate it finds blocks. so with its half million PPCs it finds blocks all the time.[/quote]

As it is right now, the “pn” formula considers that the attacker has a total of c coins spread evenly in n transactions.
So for an address having 500000 PPC, the probability of finding 3 consecutive blocks is 0.17%, and the probability of finding 3 consecutive blocks in 5 days is 71% (with a POS difficulty at 11, and supposing that the attacker doesn’t broadcast his found blocks if they are not consecutive).

Yes, the POS difficulty is mainly related to the total number of minting coins.

I will try to improve the formula to make it work with a number of minting transaction outputs different from the number of blocks the attacker is trying to find…

Let’s suppose that an attacker trying to do a n blocks deep blockchain reorganization has a total of c coins evenly spread in t transactions (t > n), and that all the coins have reached maximum coin age.

The probability for one of the transaction outputs to mint a block within 10 minutes is:

p10 = 1 - (1 - ((c / t) * 60) / (difficulty * 2^32))^600

The attacker will try every combination of n of his t transactions, and check if they can mint blocks.
If one of the combinations works, the attacker can broadcast his n newly minted blocks to reorganize the blockchain (if his chain has a higher trust).
The number of possible combinations is:

comb(n, t) = t! / (n! * (t - n)!)

The probability for n transactions to be able to mint is:

pn = (p10)^n
pn = (1 - (1 - ((c / t) * 60) / (difficulty * 2^32))^600)^n

The probability for at least one of the combinations to work is then:

p = 1 - (1 - pn)^comb(n, t)
p = 1 - (1 - (1 - (1 - ((c / t) * 60) / (difficulty * 2^32))^600)^n)^(t! / (n! * (t - n)!))

I tried this new formula with 500000 PPC spread in 500 transactions with POS difficulty at 11:

[ul][li]Probability of 3 blocks deep reorganization: 0.911%[/li]
[li]Probability of 3 blocks deep reorganization in 5 days: 99.9%[/li]
[li]Probability of 6 blocks deep reorganization: 0.000411%[/li]
[li]Probability of 6 blocks deep reorganization in 5 days: 0.296%[/li][/ul]

If I’m ever turned into a zombie, I will eat your brain first glv.

Thanks for the detailed revision of the formula. Apparently the odds has changed some and if I’m not mistaken it better fits the empirical findings of mphs.

I think it is permutation instead of combination because order of the n stakes matters?

To step through the process, the attacker (or just an innocent address/wallet that has t stakes) will try all stakes every second, the probability for one stake to find a block in 10min is 1-(1-p10)^t which is ~ p10t for p10 << 1. If one is found the rest will be tried, with a probability of being successful at ~ p10(t-1), if another block is found the rest be tried, with a probability of being successful at ~ p10*(t-2) … until n block is found, with the grand probability of ~ p10^n*(t(t-1)(t-2)…(t-n-1)) which is p10^n*(t!/(t-n)!) .

Taking all the permutations into considerations, the formula becomes:

p = 1 - (1 - pn)^(t! / (t - n)!)
p = 1 - (1 - (1 - (1 - ((c / t) * 60) / (difficulty * 2^32))^600)^n)^(t! / (t - n)!)

For the values of the previous attack example (500000 PPC, 500 transactions, difficulty 11), we get:

[ul][li]Probability of 3 blocks deep reorganization: 5.34%[/li]
[li]Probability of 3 blocks deep reorganization in 5 days: 99.999%[/li]
[li]Probability of 6 blocks deep reorganization: 0.296%[/li]
[li]Probability of 6 blocks deep reorganization in 5 days: 88.1%[/li]
[li]Probability of 9 blocks deep reorganization: 0.0157%[/li]
[li]Probability of 9 blocks deep reorganization in 5 days: 10.7%[/li][/ul]

[quote=“glv, post:11, topic:2668”]For the values of the previous attack example (500000 PPC, 500 transactions, difficulty 11), we get:

[ul][li]Probability of 3 blocks deep reorganization: 5.34%[/li]
[li]Probability of 3 blocks deep reorganization in 5 days: 99.999%[/li]
[li]Probability of 6 blocks deep reorganization: 0.296%[/li]
[li]Probability of 6 blocks deep reorganization in 5 days: 88.1%[/li]
[li]Probability of 9 blocks deep reorganization: 0.0157%[/li]
[li]Probability of 9 blocks deep reorganization in 5 days: 10.7%[/li][/ul][/quote]
There are still three addresses, right now, that could be split up to attack in this way, and this doesn’t even consider one entity owning multiple wallets. http://ppc.blockr.io/trivia/address

[quote=“Chronos, post:12, topic:2668”][quote=“glv, post:11, topic:2668”]For the values of the previous attack example (500000 PPC, 500 transactions, difficulty 11), we get:

[ul][li]Probability of 3 blocks deep reorganization: 5.34%[/li]
[li]Probability of 3 blocks deep reorganization in 5 days: 99.999%[/li]
[li]Probability of 6 blocks deep reorganization: 0.296%[/li]
[li]Probability of 6 blocks deep reorganization in 5 days: 88.1%[/li]
[li]Probability of 9 blocks deep reorganization: 0.0157%[/li]
[li]Probability of 9 blocks deep reorganization in 5 days: 10.7%[/li][/ul][/quote]
There are still three addresses, right now, that could be split up to attack in this way, and this doesn’t even consider one entity owning multiple wallets. http://ppc.blockr.io/trivia/address[/quote]

When I thought about this, I came up with the following (excerpt from Cryptoblog - notícias sobre bitcoin e criptomoedas!):

Besides the massive amount of coin days consumed, the mere fact that 6 blocks have been replaced, is an inescapable symptom of an attack taking place. This in-itself would be enough for the receiving end of all of those peercoins sold, to wait more then 6 confirmations.

Yes, protecting oneself against this attack is just that easy. When the alarm bells goes of, one simply just wait a few more confirmations (the receiver can actually calculate how many confirmations he should wait, since it is known how many coin days have been consumed) thereby decreasing the odds of the attacker successfully pulling off the attack considerably. Its also noteworthy that the attacker can’t possibly know with certainty how many confirmations the receiving end of the transaction will wait under such conditions, which complicates and increases the cost of the attack even further.

Now, if its an entity that cares little about the purchasing power tied up in those huge wallets and they decide to do this attack and instead of selling the coins, they could double-spend to themselves so that can do the attack again. But they will have to wait a long time before its possible to do so again.

EDIT: It’s also worth noticing that the synchronized checkpoints can prevent this from happening and help the network recuperate if an attack takes place. At the birth of Peercoin, this kind of attack was a very big threat, that’s why we have the checkpoints. If these wallets are interested in seeing the value of their coins grow and they understand that phasing out synchronized checkpoints will help increase the value of their coins, they might just decide to split up their coins in smaller wallets (they would have to do it in such a way that blockchain analysis can not show they they are still all controlled by same owner). If they don’t do that and price is kept low, more people will be able to buy more peercoins making the supply even more distributed which is good for the future.

Hey,
I would prefer a competitive mathematical model, since we have two competing blockchains.

Here is my attempt:

I am working under the assumption that the probability to find the next block is proportional to the number of coindays.

Then we need to know the following facts:

How many coindays are minting on the mainchain?
Irigi gave a good estimate in his post http://www.peercointalk.org/index.php?topic=2515.msg26006#msg26006. He concludes that the number of coindays available for the mainchain is given by:
NumberOfCoinsMintingMainchain = 4294901760 x POSdiff / ( 600)

How many coindays does the attacker has?
We assume the attacker has NumberOfCoinsParticipatingInAttack coins and they matured for 90 days. Thus he has NumberOfCoinsParticipatingInAttack*60 coindays.

What is the probability for the attacker to find the next block:
p=NumberOfCoinsParticipatingInAttack60/(NumberOfCoinsParticipatingInAttack60+NumberOfCoinsMintingMainchain);

Due to the fact that peercoin determines the mainchain in the same manner as bitcoin - both choose the longest chain - we can apply the same calculation as sathoshi did in his whitepaper. Let me summarize his calculation:

-The race between the honest chain and an attacker chain can be characterized as a Binomial
Random Walk. The success event is the honest chain being extended by one block, increasing its
lead by +1, and the failure event is the attacker’s chain being extended by one block, reducing the
gap by -1.

-The probability of an attacker catching up from a given deficit is analogous to a Gambler’s
Ruin problem. Hence, we can calculate the probability the attacker ever catches up with the honest chain from a given deficit is given by:
p_z=probability the attacker will ever catch up from z blocks behind
=> p_z=1, if p<1-p
=>p_z=(p/(1-p))^z

-While the mainchain has found z blocks, attacker’s potential progress will be a Poisson distribution with expected value:
\lambda=z*p/(1-p)

-the probability the attacker can reorganize z blocks is given by
sum_over_k=0_to_infty(lambda^k e^(-lambda)/k!*g(z-k))
where g(x)=1 if x<0
and g(x)=(p/(1-p))^x ifx>=0

Using these calculations one finds that an attacker with 10000 coins, who wants to reorganize 6 blocks at the current difficulity 12.2, has a successprobability of 2.4727e-11

A sophisticated attacker might do the following:
-organize his stack into multiple stacks
-wait 6 hours for the next stakemodifier
-make a good guess about the development of the PoSDifficulity and try to precalculate whether he will have a chance to reorganize z blocks in the next years.
-if he does not have this chance, he can reorganize his stacks and start the procedure again.

The peercoin network can even protect us from this attack:
We assume the following:

  • The attacker has 1% of the total coinsupply
  • The attacker has to reorganize 18 blocks (since the repicient waits this long)
  • The PoSdifficulty is 60 (I think this is realistic if cold minting is enabled.)

Now the chance for an successful reorganization with one timestamp is 2.41475e-21.
The chance for an successful reorganization over the next 20 years is 6.25904e-14.

Thus the attacker is likely to find that he is not able to reorg the blocks and he will reorganize his stacks. The math says that the expected number of times the attacker has to reorg his stacks is 1/ (6.25904e-14). The cost of this attack sums up to 1.5976891e+13 transactionfees and a lot of energy. And beside this, the attacker risks the value of his own coins.

My conclusion is: Most of the time, it is okay to wait for just 6 confirmations, but if you do not want to risk anything you should wait longer. Remember, the security of PoS relies on the law of larges numbers and and it takes its time until you can apply this law.

I calculated all these number with the following code: (It is just a variation of the code from the bitcoinwhitepaper.)

#include <iostream>
#include <iomanip>

#include <math.h>
#include <gmpxx.h>
static int const  PRECISION=1024;
static mpf_class  SMALLEST_UNIT=1;
		
using namespace std;
mpf_class AttackerSuccessProbability(double q, int z);
mpf_class AttackerSuccessProbabilityForPeriod(mpf_class q, long
 days);
mpf_class exp(mpf_class lambda);
mpf_class pow(mpf_class p,int z);
  int main() {
	  double NumberOfCoinsParticipatingInAttack;
	  double PosDifficulty;
	  double NumberOfCoinsMintingMainchain;
	  double HowManyBlocksReorganize;
	 
	  cout << "How many coins does the attacker have?"<<endl;
	  cin >> NumberOfCoinsParticipatingInAttack;
	  NumberOfCoinsParticipatingInAttack*=60;
	  cout << "Now the attacker can " <<  NumberOfCoinsParticipatingInAttack << " coindays"<<endl;
	  cout << "How many blocks does the attacker want to reorganize?"<<endl;
	  cin >>  HowManyBlocksReorganize;
	  cout << "What is the current difficulty?"<<endl;
	  cin >> PosDifficulty;
	
	  NumberOfCoinsMintingMainchain=4294901760 * PosDifficulty / (600.0);

	  mpf_set_default_prec(PRECISION+5);
	  for(int i=1;i<PRECISION;i++){
	    SMALLEST_UNIT=SMALLEST_UNIT/2;
	  }
	double q=NumberOfCoinsParticipatingInAttack/(NumberOfCoinsParticipatingInAttack+NumberOfCoinsMintingMainchain);
	mpf_class ProbabilityForAttackerSuccess=AttackerSuccessProbability(q,HowManyBlocksReorganize);		    
	cout << "The probability to reorganize " << HowManyBlocksReorganize<< " blocks is " <<  ProbabilityForAttackerSuccess << endl;

	 long DuranceOfAttack;
	 cout << "How many days does the attacker try to attack?"<<endl;
	 cin >> DuranceOfAttack;
	mpf_class ProbabilityForSuccessInPeriod=AttackerSuccessProbabilityForPeriod(ProbabilityForAttackerSuccess,DuranceOfAttack);		    
	cout << "The probabibilty to have a chance to reorganize these blocks in " << DuranceOfAttack<< " days is " << ProbabilityForSuccessInPeriod << endl;
		return 0;
	}

mpf_class AttackerSuccessProbability(double qq, int z)
{
mpf_class const  q=qq;
mpf_class const  p = 1.0 - q;
mpf_class const  lambda = z * (q / p);
mpf_class sum = 1.0;
 mpf_class const expOfLambda=exp(-1*lambda);
int i, k;
for (k = 0; k <= z; k++)
{
  mpf_class poisson=expOfLambda;
  for (i = 1; i <= k; i++)
    poisson =poisson* lambda / i;
  sum =sum - poisson * (1 - pow(q / p, z - k));
 }
 return sum;
}

mpf_class exp(mpf_class lambda){
  mpf_class sum=0;
  mpf_class exponent=1;
  for(int i=1;abs(exponent)>SMALLEST_UNIT;i++){
    sum=sum+exponent;
    exponent=exponent*lambda/i;
  }
  return sum;
}
mpf_class pow(mpf_class p,int z){
  mpf_class product=1;
  for(int i=1;i<=z;i++){
    product=product*p;
  }
  return product;
}

mpf_class AttackerSuccessProbabilityForPeriod(mpf_class q, long days)
{
mpf_class p = 1.0 - q;
mpf_class product=1.0;
mpf_class sum = 0.0;
long long

 k;
for (k = 1; k <= days*3600; k++)
{
sum+=product;
product*=p;
}
 sum*=q; 
return sum;
}

This is false. In Bitcoin it is the chain that has the most PoW behind it. In Peercoin the chain that has the most chaintrust is selected as main.

This is false. In Bitcoin it is the chain that has the most PoW behind it. In Peercoin the chain that has the most chaintrust is selected as main.[/quote]
Yes, in Peercoin we have chaintrust, which depends only on the PoSdifficulty and in Bitcoin we have “chaintrust” that depends on PoWdifficulty. I think this does not change the math. Let me think about it again…

[quote=“glv, post:11, topic:2668”]Taking all the permutations into considerations, the formula becomes:

p = 1 - (1 - pn)^(t! / (t - n)!)
p = 1 - (1 - (1 - (1 - ((c / t) * 60) / (difficulty * 2^32))^600)^n)^(t! / (t - n)!)
[/code][/quote]

I think the probability for t transactions for n=1 is 1-(1-p10)^t. for n=2 is (1-(1-p10)^t )*(1-(1-p10)^(t-1)) which is ~ [1-(1-p10)^t]^2 , for n the probability is
[code]p ~[1-(1-p10)^t]^n , [/code]
where 
[code]p10 = 1 - [1 - ((c / t) * 60) / (difficulty * 2^32)]^600

url=http://www.peercointalk.org/index.php?topic=3141.msg29554#msg29554^n[/url] shouldn’t be used because it means minting n blocks in 10 min.

Let’s see if the above is in agreement with the measurement, where c=547588 . The address had a distribution of stake sizes. From the measurement post, the average stake was of the size ~150 PPC. So the average t = 547588/150 = 3650.
The median POS reward was 0.22 over 5 days (200 blocks found by the address). So the median coin age burnt per block was 0.22/0.01365.24 = 8000 PPC-day. The average coin age consumed is 8000/150 ~54 days. We will use 8000 to substitute (c / t) * 60 in calculation.
The measurement also found that instead of 6
245=720 blocks found by the network in 5 days, 852 were found. The block time will be adjusted from 600 sec to 600(720/852)=507
Taking diff = 11, the above formula gives the probability to find 1 blocks (n=1) per 10 min to be

p10 = 1 - [1 - (     8000   ) / ( 11* 2^32)]^507  = 8.585e-5
p = [1 - (1-p10)^t ]^n
  = 1 - (1-8.585e-5)^3650
  = 0.27

This is in fair agreement with the measured value of 0.235 over 5 days, considering the assumptions and approximations that have been made.

In five days the number of 2, 3, 4 consecutive blocks are predicted to be 62, 17, 4. However the actual numbers were 44, 6, 1. So the formula prediction seems to be too high for larger n. I wonder why. ???

Hey mhps,

it is an excellent idea to check the calculation on these data…

[quote=“mhps, post:17, topic:2668”][quote=“glv, post:11, topic:2668”]Taking all the permutations into considerations, the formula becomes:

p = 1 - (1 - pn)^(t! / (t - n)!) p = 1 - (1 - (1 - (1 - ((c / t) * 60) / (difficulty * 2^32))^600)^n)^(t! / (t - n)!) [/quote]
Taking diff = 11, the above formula gives the probability to find 1 blocks (n=1) per 10 min to be

p10 = 1 - [1 - (     8000   ) / ( 11* 2^32)]^507  = 8.585e-5
p = [1 - (1-p10)^t ]^n
  = 1 - (1-8.585e-5)^3650
  = 0.27

This is in fair agreement with the measured value of 0.235 over 5 days, considering the assumptions and approximations that have been made.[/quote]

Using my model I find that the probability that these stacks find the next block is:

54*547588/(54*547588+4294901760 x11 / ( 600))=0.27

looks quite similar 8)

1-(1-p10)^t is the probability that AT LEAST 1 stack finds the block. Thus, I think, (1-(1-p10)^(t*(t-1))/2 ) or (1-(1-p10)^(t*(t-1)) ) is a better approximation than (1-(1-p10)^t )*(1-(1-p10)^(t-1)). What exactly is the idea behind your calculation? -sorry I know these things are hard to explain

[quote=“josojo, post:18, topic:2668”]Using my model I find that the probability that these stacks find the next block is:

54*547588/(54*547588+4294901760 x11 / ( 600))=0.27

looks quite similar 8)[/quote]

Could you break it down to several steps so others can use your model with new data in the future? I am not sure what the above means although the result looks right :smiley: It’s encouraging that we seem to be converging.

1-(1-p10)^t is the probability that AT LEAST 1 stack finds the block. Thus, I think, (1-(1-p10)^(t*(t-1))/2 ) or (1-(1-p10)^(t*(t-1)) ) is a better approximation than (1-(1-p10)^t )*(1-(1-p10)^(t-1)). What exactly is the idea behind your calculation? -sorry I know these things are hard to explain[/quote]

Because p10 is much smaller than 1, the probability that AT LEAST 1 stake finds a block is a good approximation to the probability that EXACTLY 1 stake finds a block. The error is on the order of p10p10.
I don’t understand the rationale behind (1-(1-p10)^(t
(t-1))/2 ) or (1-(1-p10)^(t*(t-1)) ) Could you explain? On the face of it, t is a very large number, tt is so big it will bring (1-p10)^(tt) almost to zero.

Yes, please. Then I can also update the myth thread.