<p>It depends significantly if you're asking about the average, N-th percentile time, or a worst case including the possibility of maliciously constructed blocks.</p>

<p>Nodes use the first copy of a block they receive, obviously. A consequence of this is that block propagation along a slower path will be outpaced by block propagation on a faster path.  As a result, overall propagation time depends mostly on the behavior of fastest paths and there are many optimizations in the Bitcoin network to make the fastest paths usually quite fast.</p>

<p>On the vast majority of blocks >99% of the transactions in the block are known in advance and already validated. With validation already cached the only further validation required are trivial tests such as preventing double-spends within a block and verifying that block time/height are consistent with transaction lock-times.</p>

<p>On blocks consisting of known transactions relay among <a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki" rel="noreferrer">BIP152</a> HB-mode peers occurs without most of the validation (only POW and the hash root are checked, which takes under 1ms on a typical fast host). Similarly, <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> forwarding doesn't need to wait for validation (or complete reception, for that matter) even when many transactions aren't known in advance.</p>

<p>As a result on <em>average</em> the amount of time used for validation in propagation in the network today is probably closer to 0% than to 1%. I would expect based on <a href="http://bitcoinfibre.org/stats.html" rel="noreferrer">data from matt's relay network</a> that the 99.9th percentile would have a couple percent in validation.</p>

<p>In the worst case, however, no transactions would be known or already validated and, also in the worst case, a block could require minutes of processing to validate.  Fibre would still forward fairly quickly though still several times slower than typical due to the additional data needed.  In such a worst case situation the vast majority of the propagation time would be spent on validation, even where Fibre propagation is used (which doesn't need to wait for validation even when the data is unknown), just due the final receiving node's own validation.</p>

<p>This other answer may be of interest to you: <a href="https://bitcoin.stackexchange.com/a/80928/52021">https://bitcoin.stackexchange.com/a/80928/52021</a></p>

<p>The community has spent a fair amount of effort optimizing the non-malicious block case both because it was clear what needed to be done there and because providing equitable access to very fast propagation is essential to avoiding creating an advantage for larger miners.  Arguably, however, for many concerns the worst case performance is more critical.  Fibre makes some advance on the non-validation related worst case performance, and not making the worst case worse was a major design goal in segwit but the worst case remains a more difficult and somewhat less well addressed problem.</p>

CC BY-SA 4.0
2019-01-28T10:05:58.097Z
Thanks for this great answer. What is a maliciously constructed block?
James C.
CC BY-SA 4.0
2019-01-28T10:12:01.063Z
A block that instead of processing normal transactions is stuffed full of transactions which are specifically created to be expensive for the network to deal with. For example, by containing transactions which were not previously relayed to eliminate caching gains, expensive script operations, or quadratic sig-hashing.
G. Maxwell
CC BY-SA 4.0
2019-01-29T01:32:26.080Z
Maybe one advantage of having an optimal average case is that it makes the adversarial case stand out that much more? Everybody will very quickly know that something is up and take their precautions. There's no hiding in the noise or plausible deniability for the adversary. Even if he's still anonymous.
Jannes
CC BY-SA 4.0
2019-01-29T09:27:58.683Z
Great answer.  ">99% of the transactions in the block are known in advance and already validated." You mean they are already known by nodes that received them earlier? But a node that just received the block still need to validate all tx on it, right?  BTW, isn't it often claimed that blockchain scalability issue arises because all nodes need to verify all tx?
Danny
CC BY-SA 4.0
2019-01-29T10:04:02.777Z
Most transactions are relayed on the network, received, and validated on most nodes before they end up in blocks. They don't need to be validated again except for trivial consistency checks. They all have to validate them, but usually they are no longer on the critical path for block validation.  Security depends on the worst case, however, which would be when they are not known in advance, so processing delays are still important but they're important even though on average they don't take any time during propagation.
G. Maxwell
CC BY-SA 4.0
2019-01-30T09:12:46.803Z
@G.Maxwell, A rough idea to increase scalability, not sure if it will work: let the number of nodes to verify a tx depend on the number of past transactions between the two addresses within that tx. If the two addresses transacted a lot in the past (all verified transactions), the less number of nodes is required to verify their mutual transactions in the future.
Danny
CC BY-SA 4.0
2019-01-30T09:20:35.023Z
@G.Maxwell, Let's say two addresses transacted a lot in the past, their next tx will only be verified by 20% of the nodes (or, for each node, their probability of verifying the tx is 20%). If this time their tx become malicious, the protocol will ask the 20% verifying nodes (after finding out the tx is indeed malicious) to send msg to the remaining 80% nodes to start verifying on that tx.  They will drop that tx or blocks containing that tx, thus ensuring security.
Danny
CC BY-SA 4.0
2019-02-14T08:49:26.017Z
@G.Maxwell Do you think the idea will work? I think it will and Bitcoin should implement it. If not, I might create a startup doing that. :)
Danny
CC BY-SA 4.0
2019-02-15T03:39:52.577Z
Attacker spins up 1,000,000 'nodes', and as a result any 20% you select will almost always be attacker nodes.  If that sort of thing worked there would be no reason for mining in Bitcoin at all.
G. Maxwell
CC BY-SA 4.0
2019-02-20T07:29:17.827Z
@G.Maxwell The PoW mining part still exists and remain the same, only the subsequent process of transaction verification is modified. The problem you mention also exist in other layer-1 scalability solution such as Sharding. It is highly unlikely that ALL 20% is malicious. Even if there is one non-malicious node checking it and found fault it will tell to others to verify it (if they not done it before), spreading throughout the network.
Danny
CC BY-SA 4.0
2019-02-20T07:33:17.590Z
@G.Maxwell Also, if an address is involved in one malicious behaviour the next time they appear in another transaction, the number of nodes required to verify it quickly escalates to, say 95%.
Danny
CC BY-SA 4.0
2019-01-28T09:35:57.467Z
2019-01-28T09:59:53.580Z
2019-01-28T09:59:53.580Z
G. Maxwell
<p>Does block verification time (by all nodes in the network) takes up a large portion of the total block propagation time?
What is the percentage, on average?</p>

<verification><block-propagation-time>
Block verification time
Danny
# Block verification time

(Asked by: username_0 on 2019-01-28)

Does block verification time (by all nodes in the network) takes up a large portion of the total block propagation time?
What is the percentage, on average?

**Tags:** verification, block-propagation-time


---

## 1 answers

### Answer by username_1 on 2019-01-28. Score: 7 | Accepted answer

It depends significantly if you're asking about the average, N-th percentile time, or a worst case including the possibility of maliciously constructed blocks.

Nodes use the first copy of a block they receive, obviously. A consequence of this is that block propagation along a slower path will be outpaced by block propagation on a faster path. As a result, overall propagation time depends mostly on the behavior of fastest paths and there are many optimizations in the Bitcoin network to make the fastest paths usually quite fast.

On the vast majority of blocks >99% of the transactions in the block are known in advance and already validated. With validation already cached the only further validation required are trivial tests such as preventing double-spends within a block and verifying that block time/height are consistent with transaction lock-times.

On blocks consisting of known transactions relay among [BIP152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) HB-mode peers occurs without most of the validation (only POW and the hash root are checked, which takes under 1ms on a typical fast host). Similarly, [fibre](https://bitcoin.stackexchange.com/questions/56485/can-someone-please-explain-fibre-to-me-like-im-5-and-why-is-it-useful) forwarding doesn't need to wait for validation (or complete reception, for that matter) even when many transactions aren't known in advance.

As a result on *average* the amount of time used for validation in propagation in the network today is probably closer to 0% than to 1%. I would expect based on [data from matt's relay network](http://bitcoinfibre.org/stats.html) that the 99.9th percentile would have a couple percent in validation.

In the worst case, however, no transactions would be known or already validated and, also in the worst case, a block could require minutes of processing to validate. Fibre would still forward fairly quickly though still several times slower than typical due to the additional data needed. In such a worst case situation the vast majority of the propagation time would be spent on validation, even where Fibre propagation is used (which doesn't need to wait for validation even when the data is unknown), just due the final receiving node's own validation.

This other answer may be of interest to you: <https://bitcoin.stackexchange.com/a/80928/52021>

The community has spent a fair amount of effort optimizing the non-malicious block case both because it was clear what needed to be done there and because providing equitable access to very fast propagation is essential to avoiding creating an advantage for larger miners. Arguably, however, for many concerns the worst case performance is more critical. Fibre makes some advance on the non-validation related worst case performance, and not making the worst case worse was a major design goal in segwit but the worst case remains a more difficult and somewhat less well addressed problem.

> **Comments:**
> **username_2**: Thanks for this great answer. What is a maliciously constructed block?  
> **username_1**: A block that instead of processing normal transactions is stuffed full of transactions which are specifically created to be expensive for the network to deal with. For example, by containing transactions which were not previously relayed to eliminate caching gains, expensive script operations, or quadratic sig-hashing.  
> **username_3**: Maybe one advantage of having an optimal average case is that it makes the adversarial case stand out that much more? Everybody will very quickly know that something is up and take their precautions. There's no hiding in the noise or plausible deniability for the adversary. Even if he's still anonymous.  
> **username_0**: Great answer.  ">99% of the transactions in the block are known in advance and already validated." You mean they are already known by nodes that received them earlier? But a node that just received the block still need to validate all tx on it, right?  BTW, isn't it often claimed that blockchain scalability issue arises because all nodes need to verify all tx?  
> **username_1**: Most transactions are relayed on the network, received, and validated on most nodes before they end up in blocks. They don't need to be validated again except for trivial consistency checks. They all have to validate them, but usually they are no longer on the critical path for block validation.  Security depends on the worst case, however, which would be when they are not known in advance, so processing delays are still important but they're important even though on average they don't take any time during propagation.  
> **username_0**: @G.username_1, A rough idea to increase scalability, not sure if it will work: let the number of nodes to verify a tx depend on the number of past transactions between the two addresses within that tx. If the two addresses transacted a lot in the past (all verified transactions), the less number of nodes is required to verify their mutual transactions in the future.  
> **username_0**: @G.username_1, Let's say two addresses transacted a lot in the past, their next tx will only be verified by 20% of the nodes (or, for each node, their probability of verifying the tx is 20%). If this time their tx become malicious, the protocol will ask the 20% verifying nodes (after finding out the tx is indeed malicious) to send msg to the remaining 80% nodes to start verifying on that tx.  They will drop that tx or blocks containing that tx, thus ensuring security.  
> **username_0**: @G.username_1 Do you think the idea will work? I think it will and Bitcoin should implement it. If not, I might create a startup doing that. :)  
> **username_1**: Attacker spins up 1,000,000 'nodes', and as a result any 20% you select will almost always be attacker nodes.  If that sort of thing worked there would be no reason for mining in Bitcoin at all.  
> **username_0**: @G.username_1 The PoW mining part still exists and remain the same, only the subsequent process of transaction verification is modified. The problem you mention also exist in other layer-1 scalability solution such as Sharding. It is highly unlikely that ALL 20% is malicious. Even if there is one non-malicious node checking it and found fault it will tell to others to verify it (if they not done it before), spreading throughout the network.  
> **username_0**: @G.username_1 Also, if an address is involved in one malicious behaviour the next time they appear in another transaction, the number of nodes required to verify it quickly escalates to, say 95%.  

---

