<p>Your question doesn't actually provide enough context even with the proviso that you don't care about which machine specifically.</p>

<p>Do you mean cold-cache during initial block download or do you mean at the tip of the chain on a running node? The difference on this point is probably two orders of magnitude in speed.</p>

<p>Usually, at the tip almost no transaction validation is done at all except for double-spend consistency at the time a block is accepted: all the transactions have already been received and validated.</p>

<p>Do you want a time for processing just a single block without the necessary database writing that is usually batched across many blocks? The difference here is perhaps a factor of two in speed in the uncached case, much more in the cached case.</p>

<p>You can run bitcoin core with -debug=bench to cause it to log detailed timings for the various parts of validation to see validation on your own system.</p>

<p>Order of magnitude numbers are on the order of a couple milliseconds for the common at-tip fully cached case to a couple seconds for cold caches and flushing. Potentially minutes if the block were adversarially constructed.</p>

CC BY-SA 4.0
2018-11-07T15:58:09.630Z
Thank you for the answer, I will be more specific:
I'm running a rough simulation that calculates the time it takes to propagate a block. For simplicity reasons, I would like to make all nodes identical. Meaning equal bandwidth and equal propagation delay between every two nodes. I would also want to use a rough estimation for the time it takes to validate a block. I know that some of the transactions were already approved, but others were not. That's why I'm interested in the estimation, which takes into account: average new transactions per block, computational power etc.
MORTAL9
CC BY-SA 4.0
2018-11-07T23:01:29.980Z
In Bitcoin blocks aren't validated before being propagated the vast majority of the time. (With BIP152 they're propagated before validation if all the data is known in advance, with [FIBRE](https://bitcoin.stackexchange.com/questions/56485/can-someone-please-explain-fibre-to-me-like-im-5-and-why-is-it-useful) they're always propagated before validation)

In a recent range of 288 blocks, I see 11 blocks where there was 1 or more unknown transaction with an average rate of 0.059 unknown transactions per-block. As an aside, the Bitcoin network exploits unequal delays to get faster propagation.
G. Maxwell
CC BY-SA 4.0
2018-10-30T16:43:52.023Z
2018-10-30T19:03:12.423Z
2018-10-30T19:03:12.423Z
G. Maxwell
<p>I'm interested to know how long does it take to validate a Bitcoin block on average home pc. 
I'm less interested in a precise number. I'm fully aware that it can be different between different machines. 
I'm more interested in an estimation.
Previous answers didn't provide a number or even rough calculation.</p>

<client><validation><block-validity>
How long does it take to validate a full block?
MORTAL9
# How long does it take to validate a full block?

(Asked by: username_0 on 2018-10-30)

I'm interested to know how long does it take to validate a Bitcoin block on average home pc.
I'm less interested in a precise number. I'm fully aware that it can be different between different machines.
I'm more interested in an estimation.
Previous answers didn't provide a number or even rough calculation.

**Tags:** client, validation, block-validity


---

## 1 answers

### Answer by username_1 on 2018-10-30. Score: 3

Your question doesn't actually provide enough context even with the proviso that you don't care about which machine specifically.

Do you mean cold-cache during initial block download or do you mean at the tip of the chain on a running node? The difference on this point is probably two orders of magnitude in speed.

Usually, at the tip almost no transaction validation is done at all except for double-spend consistency at the time a block is accepted: all the transactions have already been received and validated.

Do you want a time for processing just a single block without the necessary database writing that is usually batched across many blocks? The difference here is perhaps a factor of two in speed in the uncached case, much more in the cached case.

You can run bitcoin core with -debug=bench to cause it to log detailed timings for the various parts of validation to see validation on your own system.

Order of magnitude numbers are on the order of a couple milliseconds for the common at-tip fully cached case to a couple seconds for cold caches and flushing. Potentially minutes if the block were adversarially constructed.

> **Comments:**
> **username_0**: Thank you for the answer, I will be more specific: I'm running a rough simulation that calculates the time it takes to propagate a block. For simplicity reasons, I would like to make all nodes identical. Meaning equal bandwidth and equal propagation delay between every two nodes. I would also want to use a rough estimation for the time it takes to validate a block. I know that some of the transactions were already approved, but others were not. That's why I'm interested in the estimation, which takes into account: average new transactions per block, computational power etc.  
> **username_1**: In Bitcoin blocks aren't validated before being propagated the vast majority of the time. (With BIP152 they're propagated before validation if all the data is known in advance, with [FIBRE](https://bitcoin.stackexchange.com/questions/56485/can-someone-please-explain-fibre-to-me-like-im-5-and-why-is-it-useful) they're always propagated before validation)  In a recent range of 288 blocks, I see 11 blocks where there was 1 or more unknown transaction with an average rate of 0.059 unknown transactions per-block. As an aside, the Bitcoin network exploits unequal delays to get faster propagation.  

---

