<blockquote>
<p>The fact that a miner found such a nonce does not guarantee that it
will become part of the consensus blockchain though.</p>
</blockquote>
<p>this is true because there might be multiple miners who find the correct nonce at the same time. the one who quickly propagates wins.</p>
<p>there is a term called <a href="https://www.nicehash.com/blog/post/blockchain-basics-orphan-blocks" rel="nofollow noreferrer">orphan block</a>:</p>
<blockquote>
<p>Orphan block is a term used by the general public, but in technical
documents it is described as a stale block. An Orphan block is created
when two miners (or more) find the solution at the same time.</p>
<p>Since each miner will broadcast the solution to the network and the
network requires a couple of moments to synchronize, there will be two
blockchains for a brief period of time. Each part of the blockchain
will think that their solution was found first and is the solution
that should be used primarily. In reality, both solutions are valid.</p>
<p>Once the new blockchain is active, the “race” between both chains
begins. Whichever chain will have the longer chain will be the main
chain.</p>
</blockquote>

CC BY-SA 4.0
2023-11-12T17:19:54.317Z
Thanks! That's helpful, but I cannot accept the answer in the current state, since I specifically asked about a percentage.
MWB
CC BY-SA 4.0
2023-11-12T03:49:28.883Z
2023-11-12T03:49:28.883Z
Yilmaz
<p>You should say Bitcoin, not just blockchain: Bitcoin is the basic reference model for all blockchains, but there may be protocol variations with other blockchains.</p>
<blockquote>
<p>The fact that a miner found such a nonce does not guarantee that it
will become part of the consensus blockchain though. What percentage
of them fail to join the consensus blockchain?</p>
</blockquote>
<p>The short answer is <strong>a vanishingly small percentage</strong>, i.e. almost zero, but not for the reasons you seem to imply.  Here is schematically how it goes:</p>
<ul>
<li><p>a Bitcoin miner is associated (talks) to a Bitcoin node: it's the node that keeps track of the blockchain as well as, among other things, of the list of pending transaction (that it knows about at any moment: typically wallets and exchanges submit transactions to a node, to be then replicated to the entire network);</p>
</li>
<li><p>based on the list of pending transaction, a job is submitted to the miner in order to search for a new block;</p>
</li>
</ul>
<p>At this point one of two things can happen:</p>
<ol>
<li><p>the node receives a new block before the miner is done: in this case the miner's job is aborted and, possibly, a new job gets started with the updated list of pending transactions; otherwise:</p>
</li>
<li><p>the miner finds a block before any new block has arrived to the node: in this case the miner submits the block to the node, and at this point <strong>the block <em>is</em> part of the blockchain</strong>, which just means it has been accepted by the immediate node and will be progressively propagated to the rest of the network.</p>
</li>
</ol>
<p>Propagation entails latency: time is needed for a new block to reach all nodes of the network.  Hence, when two miners find a new block almost at the same time, they both transmit it to their nodes, which accept the block since they don't yet know another block was created somewhere else.  In that case what is happening is called a &quot;network fork&quot;: these are quite frequent but usually resolve themselves in a matter of minutes, rarely more, by the rule that the longest chain wins. (I am not getting into too many details for simplicity: more technical details can be found online.)</p>
<p>So, now back to your initial question: <strong>there is one and only one possibility for a valid block to literally not make it to the blockchain</strong>, and that is if the miner finds the block almost exactly at the same time the node receives a new block, in which case the miner might indeed try to submit its block to the node and the node would have to refuse the request.  And this is the event that I am dubbing vanishingly probable: based on my competence and experience, I am not aware of public statistics about this.</p>
<p>Incidentally, nonces are <em>not</em> the only element in a block that a miner can play with in order to vary the block content and get different hashes, indeed nonces are uint32 numbers, so there would not be nearly enough.  There is also the timestamp, as well as the coinbase attribute of the so called generation transaction, i.e. the one in which miners rewards themselves: plus a miner decides which of the pending transactions to actually include in the block and in which order.</p>

CC BY-SA 4.0
2023-11-13T19:55:20.203Z
My question used the term "consensus blockchain". I hope the meaning was clear - it's the blockchain that everyone eventually agrees on, not some ephemeral data structure that exists for a second. You are saying *"these are quite frequent but usually resolve themselves in a matter of minutes"* - it would be nice to have a numerical estimate. What percentage? (the topic of the question).
MWB
CC BY-SA 4.0
2023-11-13T23:25:21.547Z
A blockchain, by definition, is just a data structure - a (particular) singly-linked list of blocks. Different nodes can hold on to different lists. The product of the consensus mechanism is a list that everyone agrees on. That's what I call a "consensus blockchain". The nonce that the miner found may or may not end up in it. The question asked about the probability of it not making it there.
MWB
CC BY-SA 4.0
2023-11-12T23:07:39.237Z
2023-11-12T23:17:19.333Z
Julio Di Egidio
<p>Imagine that all of the Bitcoin network's hashing is being done on a single giant imaginary computer, that doesn't stop if it finds a successful block.</p>
<p>We can perform a calculation of the probability that it finds two valid blocks in one second using public estimates of the hashrate as well as the known target.</p>
<p><code>two_valid_blocks_in_1sec_probability ~= 100% * (hash_rate_per_sec * target  / 2**256 ) ^ 2</code></p>
<p>Now imagine that the hash rate is distributed across the network of miners. Whether a valid block fails is dependent on the time it takes a valid block to reach, and be accepted by, rival miners. As an estimate, we can use the time it takes a block to reach nodes covering half of network hashrate; the <a href="https://bitcoin.stackexchange.com/a/114196/34190">block propagation time</a>. Adjusting the above formula, it becomes:</p>
<p><code>valid_block_failure_probability ~= 100% * (hash_rate_per_sec * mean_block_propagation_time * target  / 2**256 ) ^ 2</code></p>
<p><sub>Note this assumes terms for ^3, ^4, ^5 ... (which, strictly, should be added on) are not significant. This also assumes that the time it takes nodes to validate and accept valid headers is &lt;&lt; the mean propagation time. </sub></p>
<p>Here's a python script to do that:</p>
<pre class="lang-python prettyprint-override"><code>    # Block 809295
    
    hash_rate_per_sec = 405000000.0 * 10**12 
    # approximated from https://www.blockchain.com/explorer/charts/hash-rate
    
    target = 0x00000000000000000004ed7f0000000000000000000000000000000000000000 
    # from https://learnmeabitcoin.com/technical/target
    
    period_secs = 0.5
    # from https://bitcoin.stackexchange.com/a/114196/34190
    # mean block propagation time (a block will reach nodes responsible for half of network hashrate in this time).
    
    prob_per_period = hash_rate_per_sec * period_secs * target  / 2**256
    
    N = 2
    
    prob_N_hashes_in_period = prob_per_period**N
    
    print('The probability that the bitcoin network will produce',N,'valid blocks in', period_secs, 'seconds is ', prob_N_hashes_in_period, ' Based on hashrate and target at block 809295.')
</code></pre>
<p>Which gives the following printout:</p>
<pre><code>The probability that the bitcoin network will produce 2 valid blocks in 0.5 seconds is  6.81306666296744e-07  Based on hashrate and target at block 809295.
</code></pre>
<hr />
<p>Using this, in answer to your question, we can say that, if the mean block propagation time is 0.5s, at block height 809295:</p>
<p><em>If a miner has found a successful block, there is a <strong>0.00007%</strong> (1 sig fig) chance that it will not reach the consensus Bitcoin blockchain</em></p>
<hr />
<p>The probability is sensitive to the estimated propagation delay:</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th><code>mean_block_propagation_time</code> [s]</th>
<th><code>valid_block_failure_probability</code>  [%, 1 sig fig]</th>
</tr>
</thead>
<tbody>
<tr>
<td>0.5</td>
<td>0.00007</td>
</tr>
<tr>
<td>1</td>
<td>0.0003</td>
</tr>
<tr>
<td>1.5</td>
<td>0.0006</td>
</tr>
<tr>
<td>2</td>
<td>0.001</td>
</tr>
<tr>
<td>2.5</td>
<td>0.002</td>
</tr>
<tr>
<td>5</td>
<td>0.007</td>
</tr>
<tr>
<td>10</td>
<td>0.03</td>
</tr>
<tr>
<td>20</td>
<td>0.1</td>
</tr>
</tbody>
</table>
</div>
<p>The idea of collusion amongst miners (tacit or overt gatekeeping) slowing acceptance was not considered.</p>

CC BY-SA 4.0
2023-11-21T13:42:39.613Z
You have computed the probability that in a given 1s interval two get computed, but that's not what OP is asking for. You need the frequency of that happening *per block*, not per second. Also, you need to divide by two because the order of the two found hashes within the 1s interval does not matter.
Pieter Wuille
CC BY-SA 4.0
2023-11-21T13:55:42.600Z
@PieterWuille Paraphrasing OP "Given a miner has found a valid block, what is likelihood it fails to reach consensus chain"? The _per second_  value can be modified to any period by multiplying by a number of seconds. I chose the mean block propagation time as a modifier as this approximates the time a rival has to "gazump" the successful block. You could well be right about the factor of 2; I'm thinking on it....
Lee
CC BY-SA 4.0
2023-11-21T14:06:09.460Z
@PieterWuille I'd add that the _per block_ aspect is included via the hashrate estimation and target values.
Lee
CC BY-SA 4.0
2023-11-21T14:09:00.093Z
OP is asking for the percentage of successful PoW hashes that don't get included. You're computing the rate at which successful but discarded hashes happen *per second*, but you need to divide that by the rate of successful hashes per second, to obtain the ratio of discarded hashes per successful ones. 0.000007% is just far too low; with 1s propagation delay and 600s blocks, you expect a number with an order of magnitude close to 1/600.
Pieter Wuille
CC BY-SA 4.0
2023-11-21T14:13:48.620Z
@PieterWuille agree on OP, but forgive me, the `valid_block_failure_probability` value is not per second. The time units drop out on multiplication by the period, in this case the `mean_block_propagation_time` (units of seconds).
Lee
CC BY-SA 4.0
2023-11-21T14:19:51.497Z
Hmm, yes, I'm wrong in my reasoning, sorry. Still, the number you obtain is clearly wildly off. You expect something in the order of 1/600 (or 0.5/600, for half a second propagation time).
Pieter Wuille
CC BY-SA 4.0
2023-11-21T14:32:33.483Z
@PieterWuille thanks, will check for rounding errors etc in the Python code.
Lee
CC BY-SA 4.0
2023-11-21T16:55:08.453Z
The time between blocks is a Poisson process, so follows an exponential distribution (with lambda=1/600s). If latency is L seconds, and every block found within L seconds of an accepted block is discarded, then taking the CDF (*1- exp(-lambda x)*) in x=0 and x=L, we obtain the difference *1 - exp(-lambda L)* discarded blocks per accepted block, or *(exp(lambda L) - 1) / (2 exp(lambda L) - 1)* discarded blocks per total blocks, which is 0.166% for L=1.
Pieter Wuille
CC BY-SA 4.0
2023-11-22T13:48:02.943Z
@PieterWuille neatly done, thank you. Perhaps you should add it onto your answer..
Lee
CC BY-SA 4.0
2023-11-22T14:31:00.870Z
I'm wrong. 1-exp(-lambda L) is the probability that at least one PoW-valid block is found in a window of length L after a given accepted block. But that's not what we want; there could be multiple such blocks in that window, and their expected value is just *lambda L*. Therefore, the percentage of discarded blocks per total PoW-valid blocks is (1 - 1 / (1 + lambda L)). Still 0.166% for L=1 though.
Pieter Wuille
CC BY-SA 4.0
2023-11-23T06:08:09.657Z
You don't need the probability that N=2 are found in 0.5s. You need a conditional probability, that a block will be found within 0.5s, given that another block has just been found. And since they are largely independent, you basically need N=1. 0.5/600 seems like the correct estimate here, or very close to correct.
MWB
CC BY-SA 4.0
2023-11-21T11:40:55.623Z
2023-11-21T15:18:36.850Z
2023-11-21T15:18:36.850Z
Lee
<p>The term for this is &quot;orphan rate&quot; or &quot;fork rate&quot;, as each created block which doesn't make it into the eventually accepted chain is effectively a tiny chain fork that doesn't get extended. Such blocks are sometimes called orphan blocks (though that term is a <a href="https://bitcoin.stackexchange.com/a/5869/208">misnomer</a>).</p>
<p>These forks occur when two blocks are found nearly simultaneously, where the later miner was still working on the previous block. The better the <a href="https://www.dsn.kastel.kit.edu/bitcoin/#propagation" rel="nofollow noreferrer">latency between miners</a>, the shorter the time between the blocks needs to be for this to occur.</p>
<p>It is very hard to get exact statistics on this, for the simple reason that nodes in the network do not relay blocks which aren't considered part of the main chain. If a node receives a block at height H, and then another one at the same height H, the latter will not be considered part of the main chain unless it is extended first. Thus, generally such a fork will involve a condition where one part of the network hears about one block first, and another part of the network that hears about the other one first. Nodes on the boundary between the two will generally hear about both immediately. Nodes that heard the losing block first will eventually hear about both. Nodes that heard about the winning block first - generally the largest subset - will typically not ever hear about the losing block.</p>
<p>Thus, the best we can do is gather statistics from forks that well-connected nodes saw, though even that will be necessarily an underestimate: the &quot;worst&quot; forks don't propagate at all, not even past the mining pool that created them, and thus will not show up in anyone's statistics.</p>
<p>On my own rather well-connected node, I've seen <strong>13 forks in the past 4 months</strong> (since block 800000). The <a href="https://fork.observer" rel="nofollow noreferrer">https://fork.observer</a> website lists forks they see on their nodes, which currently shows a similar number over that timespan. I believe <a href="https://blockchain.info" rel="nofollow noreferrer">https://blockchain.info</a> used to list forks somewhere in the past, but I can't find that anymore.</p>
<p>If we use that number as a lower bound, the answer to your question would be <strong>at least 0.07%</strong>. The number can change wildly over longer time periods though, as it depends on the composition of blocks, the geographic distribution of miners, their connectivity, and the technologies used to connect them (e.g. <a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki" rel="nofollow noreferrer">BIP152</a> compact blocks helped reduce latency between miners, and the public <a href="https://bitcoin.stackexchange.com/questions/56485/can-someone-please-explain-fibre-to-me-like-im-5-and-why-is-it-useful">FIBRE</a> network while it was still operational helped more).</p>

CC BY-SA 4.0
2023-11-21T02:13:33.413Z
One such site is https://fork.observer/.
Vojtěch Strnad
CC BY-SA 4.0
2023-11-21T02:08:28.050Z
2023-11-21T02:44:33.380Z
2023-11-21T02:44:33.380Z
Pieter Wuille
<p>From <a href="https://en.wikipedia.org/wiki/Bitcoin" rel="nofollow noreferrer">Wikipedia</a>:</p>
<blockquote>
<p>The PoW requires miners to find a number called a nonce (a number used just once), such that when the block content is hashed along with the nonce, the result is numerically smaller than the network's difficulty target.</p>
</blockquote>
<p>The fact that a miner found such a nonce does not guarantee that it will become part of the consensus blockchain though. What percentage of them fail to join the consensus blockchain?</p>

CC BY-SA 4.0
2023-11-18T23:27:13.290Z
Are you asking about the percentage of nonces *tried* that don't make it into the eventually-accepted chain, or the percentage of nonces *which satisfy PoW* that don't make it into the chain? And, you are talking about Bitcoin, right, because the numbers will differ wildly for different chains/designs.
Pieter Wuille
CC BY-SA 4.0
2023-11-18T23:35:10.100Z
@PieterWuille (1) The nonces that do NOT make it into the eventually-accepted chain, as a percentage of all nonces that satisfied the PoW (2) Bitcoin, but I'm curious about others also, I guess (optional)
MWB
<mining-theory><mining-profitability><mining-reward><relay><block-propagation-time>
What percentage of mined nonces fail to join the consensus blockchain?
MWB
# What percentage of mined nonces fail to join the consensus blockchain?

(Asked by: username_0 on 2023-11-11)

From [Wikipedia](https://en.wikipedia.org/wiki/Bitcoin):

> The PoW requires miners to find a number called a nonce (a number used just once), such that when the block content is hashed along with the nonce, the result is numerically smaller than the network's difficulty target.

The fact that a miner found such a nonce does not guarantee that it will become part of the consensus blockchain though. What percentage of them fail to join the consensus blockchain?

**Tags:** mining-theory, mining-profitability, mining-reward, relay, block-propagation-time

> **Comments:**
> **username_1**: Are you asking about the percentage of nonces *tried* that don't make it into the eventually-accepted chain, or the percentage of nonces *which satisfy PoW* that don't make it into the chain? And, you are talking about Bitcoin, right, because the numbers will differ wildly for different chains/designs.  
> **username_0**: @username_1 (1) The nonces that do NOT make it into the eventually-accepted chain, as a percentage of all nonces that satisfied the PoW (2) Bitcoin, but I'm curious about others also, I guess (optional)  

---

## 4 answers

### Answer by username_1 on 2023-11-21. Score: 4 | Accepted answer

The term for this is "orphan rate" or "fork rate", as each created block which doesn't make it into the eventually accepted chain is effectively a tiny chain fork that doesn't get extended. Such blocks are sometimes called orphan blocks (though that term is a [misnomer](https://bitcoin.stackexchange.com/a/5869/208)).

These forks occur when two blocks are found nearly simultaneously, where the later miner was still working on the previous block. The better the [latency between miners](https://www.dsn.kastel.kit.edu/bitcoin/#propagation), the shorter the time between the blocks needs to be for this to occur.

It is very hard to get exact statistics on this, for the simple reason that nodes in the network do not relay blocks which aren't considered part of the main chain. If a node receives a block at height H, and then another one at the same height H, the latter will not be considered part of the main chain unless it is extended first. Thus, generally such a fork will involve a condition where one part of the network hears about one block first, and another part of the network that hears about the other one first. Nodes on the boundary between the two will generally hear about both immediately. Nodes that heard the losing block first will eventually hear about both. Nodes that heard about the winning block first - generally the largest subset - will typically not ever hear about the losing block.

Thus, the best we can do is gather statistics from forks that well-connected nodes saw, though even that will be necessarily an underestimate: the "worst" forks don't propagate at all, not even past the mining pool that created them, and thus will not show up in anyone's statistics.

On my own rather well-connected node, I've seen **13 forks in the past 4 months** (since block 800000). The <https://fork.observer> website lists forks they see on their nodes, which currently shows a similar number over that timespan. I believe <https://blockchain.info> used to list forks somewhere in the past, but I can't find that anymore.

If we use that number as a lower bound, the answer to your question would be **at least 0.07%**. The number can change wildly over longer time periods though, as it depends on the composition of blocks, the geographic distribution of miners, their connectivity, and the technologies used to connect them (e.g. [BIP152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) compact blocks helped reduce latency between miners, and the public [FIBRE](https://bitcoin.stackexchange.com/questions/56485/can-someone-please-explain-fibre-to-me-like-im-5-and-why-is-it-useful) network while it was still operational helped more).

> **Comments:**
> **username_5**: One such site is https://fork.observer/.  

---

### Answer by username_2 on 2023-11-12. Score: 4

> The fact that a miner found such a nonce does not guarantee that it
> will become part of the consensus blockchain though.

this is true because there might be multiple miners who find the correct nonce at the same time. the one who quickly propagates wins.

there is a term called [orphan block](https://www.nicehash.com/blog/post/blockchain-basics-orphan-blocks):

> Orphan block is a term used by the general public, but in technical
> documents it is described as a stale block. An Orphan block is created
> when two miners (or more) find the solution at the same time.
>
> Since each miner will broadcast the solution to the network and the
> network requires a couple of moments to synchronize, there will be two
> blockchains for a brief period of time. Each part of the blockchain
> will think that their solution was found first and is the solution
> that should be used primarily. In reality, both solutions are valid.
>
> Once the new blockchain is active, the “race” between both chains
> begins. Whichever chain will have the longer chain will be the main
> chain.

> **Comments:**
> **username_0**: Thanks! That's helpful, but I cannot accept the answer in the current state, since I specifically asked about a percentage.  

---

### Answer by username_3 on 2023-11-12. Score: 3

You should say Bitcoin, not just blockchain: Bitcoin is the basic reference model for all blockchains, but there may be protocol variations with other blockchains.

> The fact that a miner found such a nonce does not guarantee that it
> will become part of the consensus blockchain though. What percentage
> of them fail to join the consensus blockchain?

The short answer is **a vanishingly small percentage**, i.e. almost zero, but not for the reasons you seem to imply. Here is schematically how it goes:

* a Bitcoin miner is associated (talks) to a Bitcoin node: it's the node that keeps track of the blockchain as well as, among other things, of the list of pending transaction (that it knows about at any moment: typically wallets and exchanges submit transactions to a node, to be then replicated to the entire network);
* based on the list of pending transaction, a job is submitted to the miner in order to search for a new block;

At this point one of two things can happen:

1. the node receives a new block before the miner is done: in this case the miner's job is aborted and, possibly, a new job gets started with the updated list of pending transactions; otherwise:
2. the miner finds a block before any new block has arrived to the node: in this case the miner submits the block to the node, and at this point **the block *is* part of the blockchain**, which just means it has been accepted by the immediate node and will be progressively propagated to the rest of the network.

Propagation entails latency: time is needed for a new block to reach all nodes of the network. Hence, when two miners find a new block almost at the same time, they both transmit it to their nodes, which accept the block since they don't yet know another block was created somewhere else. In that case what is happening is called a "network fork": these are quite frequent but usually resolve themselves in a matter of minutes, rarely more, by the rule that the longest chain wins. (I am not getting into too many details for simplicity: more technical details can be found online.)

So, now back to your initial question: **there is one and only one possibility for a valid block to literally not make it to the blockchain**, and that is if the miner finds the block almost exactly at the same time the node receives a new block, in which case the miner might indeed try to submit its block to the node and the node would have to refuse the request. And this is the event that I am dubbing vanishingly probable: based on my competence and experience, I am not aware of public statistics about this.

Incidentally, nonces are *not* the only element in a block that a miner can play with in order to vary the block content and get different hashes, indeed nonces are uint32 numbers, so there would not be nearly enough. There is also the timestamp, as well as the coinbase attribute of the so called generation transaction, i.e. the one in which miners rewards themselves: plus a miner decides which of the pending transactions to actually include in the block and in which order.

> **Comments:**
> **username_0**: My question used the term "consensus blockchain". I hope the meaning was clear - it's the blockchain that everyone eventually agrees on, not some ephemeral data structure that exists for a second. You are saying *"these are quite frequent but usually resolve themselves in a matter of minutes"* - it would be nice to have a numerical estimate. What percentage? (the topic of the question).  
> **username_0**: A blockchain, by definition, is just a data structure - a (particular) singly-linked list of blocks. Different nodes can hold on to different lists. The product of the consensus mechanism is a list that everyone agrees on. That's what I call a "consensus blockchain". The nonce that the miner found may or may not end up in it. The question asked about the probability of it not making it there.  

---

### Answer by username_4 on 2023-11-21. Score: 1

Imagine that all of the Bitcoin network's hashing is being done on a single giant imaginary computer, that doesn't stop if it finds a successful block.

We can perform a calculation of the probability that it finds two valid blocks in one second using public estimates of the hashrate as well as the known target.

`two_valid_blocks_in_1sec_probability ~= 100% * (hash_rate_per_sec * target / 2**256 ) ^ 2`

Now imagine that the hash rate is distributed across the network of miners. Whether a valid block fails is dependent on the time it takes a valid block to reach, and be accepted by, rival miners. As an estimate, we can use the time it takes a block to reach nodes covering half of network hashrate; the [block propagation time](https://bitcoin.stackexchange.com/a/114196/34190). Adjusting the above formula, it becomes:

`valid_block_failure_probability ~= 100% * (hash_rate_per_sec * mean_block_propagation_time * target / 2**256 ) ^ 2`

Note this assumes terms for ^3, ^4, ^5 ... (which, strictly, should be added on) are not significant. This also assumes that the time it takes nodes to validate and accept valid headers is << the mean propagation time.

Here's a python script to do that:

```python
    # Block 809295
    
    hash_rate_per_sec = 405000000.0 * 10**12 
    # approximated from https://www.blockchain.com/explorer/charts/hash-rate
    
    target = 0x00000000000000000004ed7f0000000000000000000000000000000000000000 
    # from https://learnmeabitcoin.com/technical/target
    
    period_secs = 0.5
    # from https://bitcoin.stackexchange.com/a/114196/34190
    # mean block propagation time (a block will reach nodes responsible for half of network hashrate in this time).
    
    prob_per_period = hash_rate_per_sec * period_secs * target  / 2**256
    
    N = 2
    
    prob_N_hashes_in_period = prob_per_period**N
    
    print('The probability that the bitcoin network will produce',N,'valid blocks in', period_secs, 'seconds is ', prob_N_hashes_in_period, ' Based on hashrate and target at block 809295.')

```

Which gives the following printout:

```
The probability that the bitcoin network will produce 2 valid blocks in 0.5 seconds is  6.81306666296744e-07  Based on hashrate and target at block 809295.

```

---

Using this, in answer to your question, we can say that, if the mean block propagation time is 0.5s, at block height 809295:

*If a miner has found a successful block, there is a **0.00007%** (1 sig fig) chance that it will not reach the consensus Bitcoin blockchain*

---

The probability is sensitive to the estimated propagation delay:

| `mean_block_propagation_time` [s] | `valid_block_failure_probability` [%, 1 sig fig] |
| --- | --- |
| 0.5 | 0.00007 |
| 1 | 0.0003 |
| 1.5 | 0.0006 |
| 2 | 0.001 |
| 2.5 | 0.002 |
| 5 | 0.007 |
| 10 | 0.03 |
| 20 | 0.1 |

The idea of collusion amongst miners (tacit or overt gatekeeping) slowing acceptance was not considered.

> **Comments:**
> **username_1**: You have computed the probability that in a given 1s interval two get computed, but that's not what OP is asking for. You need the frequency of that happening *per block*, not per second. Also, you need to divide by two because the order of the two found hashes within the 1s interval does not matter.  
> **username_4**: @username_1 Paraphrasing OP "Given a miner has found a valid block, what is likelihood it fails to reach consensus chain"? The _per second_  value can be modified to any period by multiplying by a number of seconds. I chose the mean block propagation time as a modifier as this approximates the time a rival has to "gazump" the successful block. You could well be right about the factor of 2; I'm thinking on it....  
> **username_4**: @username_1 I'd add that the _per block_ aspect is included via the hashrate estimation and target values.  
> **username_1**: OP is asking for the percentage of successful PoW hashes that don't get included. You're computing the rate at which successful but discarded hashes happen *per second*, but you need to divide that by the rate of successful hashes per second, to obtain the ratio of discarded hashes per successful ones. 0.000007% is just far too low; with 1s propagation delay and 600s blocks, you expect a number with an order of magnitude close to 1/600.  
> **username_4**: @username_1 agree on OP, but forgive me, the `valid_block_failure_probability` value is not per second. The time units drop out on multiplication by the period, in this case the `mean_block_propagation_time` (units of seconds).  
> **username_1**: Hmm, yes, I'm wrong in my reasoning, sorry. Still, the number you obtain is clearly wildly off. You expect something in the order of 1/600 (or 0.5/600, for half a second propagation time).  
> **username_4**: @username_1 thanks, will check for rounding errors etc in the Python code.  
> **username_1**: The time between blocks is a Poisson process, so follows an exponential distribution (with lambda=1/600s). If latency is L seconds, and every block found within L seconds of an accepted block is discarded, then taking the CDF (*1- exp(-lambda x)*) in x=0 and x=L, we obtain the difference *1 - exp(-lambda L)* discarded blocks per accepted block, or *(exp(lambda L) - 1) / (2 exp(lambda L) - 1)* discarded blocks per total blocks, which is 0.166% for L=1.  
> **username_4**: @username_1 neatly done, thank you. Perhaps you should add it onto your answer..  
> **username_1**: I'm wrong. 1-exp(-lambda L) is the probability that at least one PoW-valid block is found in a window of length L after a given accepted block. But that's not what we want; there could be multiple such blocks in that window, and their expected value is just *lambda L*. Therefore, the percentage of discarded blocks per total PoW-valid blocks is (1 - 1 / (1 + lambda L)). Still 0.166% for L=1 though.  
> **username_0**: You don't need the probability that N=2 are found in 0.5s. You need a conditional probability, that a block will be found within 0.5s, given that another block has just been found. And since they are largely independent, you basically need N=1. 0.5/600 seems like the correct estimate here, or very close to correct.  

---

