3

From Wikipedia:

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?

3
  • Successfully mined nonces?
    – Shayan
    Commented Nov 11, 2023 at 18:56
  • 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. Commented Nov 18, 2023 at 23:27
  • @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
    Commented Nov 18, 2023 at 23:35

4 Answers 4

4
+50

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

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, 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 compact blocks helped reduce latency between miners, and the public FIBRE network while it was still operational helped more).

1
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:

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.

2
  • 1
    Thanks! That's helpful, but I cannot accept the answer in the current state, since I specifically asked about a percentage.
    – MWB
    Commented Nov 12, 2023 at 17:19
  • There is no specific percentage. But it is very very litte
    – Yilmaz
    Commented Nov 12, 2023 at 17:21
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.

3
  • 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
    Commented Nov 13, 2023 at 19:55
  • @MWB You asked for the probability that a mined block "does not make it to the blockchain": the probability that a "network fork" occurs is altogether a different question, as my explanation should have made clear. Also, asking such a very concrete question about "the blockchain in general" is simply meaningless: I explained Bitcoin because that is basic, and if you had something else in mind, you should/would have said so. Last but not least, "the consensus blockchain" is redundant, it's "the blockchain", period: "consensus" is an underlying mechanisms. Hope that clarifies.
    – Julio Di Egidio
    Commented Nov 13, 2023 at 22:49
  • 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
    Commented Nov 13, 2023 at 23:25
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. 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:

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

11
  • 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. Commented Nov 21, 2023 at 13:42
  • @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
    Commented Nov 21, 2023 at 13:55
  • 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. Commented Nov 21, 2023 at 16:55
  • 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. Commented Nov 22, 2023 at 14:31
  • 2
    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
    Commented Nov 23, 2023 at 6:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.