<blockquote>
  <p>Do full-nodes process all txs before broadcasting the new blockheader?</p>
</blockquote>

<p>It depends. For nodes having protocol version 70015 and higher, the peer will announce the compact block even before full validation of the transactions contained in the block. However, the header has to be conform with the difficulty requirement. For nodes using protocol version 70015 and lower, the blocks are fully processed before broadcast.</p>

<blockquote>
  <p>Since the node would still validate the PoW and the previousblockhash, it would not be possible to DoS the network with invalid headers</p>
</blockquote>

<p>Yes, that is exactly what Bitcoin full nodes do. Whenever you come online, or receive a new block header, the block headers will be verified first to see that it has the required PoW. As you mentioned this does help prevent DoS attacks.</p>

<blockquote>
  <p>Miners could begin processing the candidate block from its header and the list of transaction hashes since they already likely have > 90% of those txs.</p>
</blockquote>

<p>Miners actually do that. Most of them will build and start processing the new block before even verifying the old one so as to not waste any time mining. However, there will be some transactions in that previous block that the miner hadn't seen in the past. Although those transactions will be very few, the miner would not know which UTXOs have been consumed by those transactions.</p>

<p>Thus miners would start building an empty block (containing only the coinbase transaction) on top of the block that they have just received which hasn't been fully verified. After the previous block gets verified in parallel, the miners will then add the unconfirmed valid transactions from the mempool to the block that they are currently mining.</p>

<blockquote>
  <p>Miners could determine how much time (=money) they are losing by comparing the time they receive the header and the last tx.</p>
</blockquote>

<p>As I mentioned above, it is not only the time but also the uncertainty related to what UTXOs have been consumed by the block that had transactions that the miner did not see in the past. As a result miners have to start building an empty block before fully verifying its parent. </p>

<p>However, it is important to note an incident that happened when blocks does not get fully verified. When <a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki" rel="nofollow noreferrer">BIP 66</a> (strict DER encoding of signatures) was implemented, some miners running the BIP 66 enabled Bitcoin Core versions were listening to pre-BIP 66 pools. One of the pool running a pre-BIP 66 version produced a block that had an incorrect block version number. The miner with BIP 66 started working on top of that unverified block by processing an empty block.</p>

<p>However, their <code>bitcoind</code> never accepted the full block as it was invalid. The result was <a href="https://bitcointalk.org/index.php?topic=958036.40" rel="nofollow noreferrer">building a series of empty blocks</a> on top of the other that were ultimately not accepted by the network.</p>

CC BY-SA 4.0
2019-10-27T16:57:28.153Z
2019-10-28T16:06:00.040Z
2019-10-28T16:06:00.040Z
Ugam Kamat
<p>If so, why not do it <em>after</em> (re)broadcast? I think it would cut down on lag time.</p>

<ul>
<li>Since the node would still validate the PoW and the <code>previousblockhash</code>, it would not be possible to DoS the network with invalid headers</li>
<li>Miners could begin processing the candidate block from its header and the list of transaction hashes since they already likely have > 90% of those txs.</li>
<li>Miners and full-nodes would still only update their head once all the txs are validated.</li>
<li>Miners could determine how much time (=money) they are losing by comparing the time they receive the header and the last tx.</li>
</ul>

<transactions><protocol><p2p>
Do full-nodes process all transactions before broadcasting the new block header?
ZMitton
# Do full-nodes process all transactions before broadcasting the new block header?

(Asked by: username_0 on 2019-10-27)

If so, why not do it *after* (re)broadcast? I think it would cut down on lag time.

* Since the node would still validate the PoW and the `previousblockhash`, it would not be possible to DoS the network with invalid headers
* Miners could begin processing the candidate block from its header and the list of transaction hashes since they already likely have > 90% of those txs.
* Miners and full-nodes would still only update their head once all the txs are validated.
* Miners could determine how much time (=money) they are losing by comparing the time they receive the header and the last tx.

**Tags:** transactions, protocol, p2p


---

## 1 answers

### Answer by username_1 on 2019-10-27. Score: 3 | Accepted answer

> Do full-nodes process all txs before broadcasting the new blockheader?

It depends. For nodes having protocol version 70015 and higher, the peer will announce the compact block even before full validation of the transactions contained in the block. However, the header has to be conform with the difficulty requirement. For nodes using protocol version 70015 and lower, the blocks are fully processed before broadcast.

> Since the node would still validate the PoW and the previousblockhash, it would not be possible to DoS the network with invalid headers

Yes, that is exactly what Bitcoin full nodes do. Whenever you come online, or receive a new block header, the block headers will be verified first to see that it has the required PoW. As you mentioned this does help prevent DoS attacks.

> Miners could begin processing the candidate block from its header and the list of transaction hashes since they already likely have > 90% of those txs.

Miners actually do that. Most of them will build and start processing the new block before even verifying the old one so as to not waste any time mining. However, there will be some transactions in that previous block that the miner hadn't seen in the past. Although those transactions will be very few, the miner would not know which UTXOs have been consumed by those transactions.

Thus miners would start building an empty block (containing only the coinbase transaction) on top of the block that they have just received which hasn't been fully verified. After the previous block gets verified in parallel, the miners will then add the unconfirmed valid transactions from the mempool to the block that they are currently mining.

> Miners could determine how much time (=money) they are losing by comparing the time they receive the header and the last tx.

As I mentioned above, it is not only the time but also the uncertainty related to what UTXOs have been consumed by the block that had transactions that the miner did not see in the past. As a result miners have to start building an empty block before fully verifying its parent.

However, it is important to note an incident that happened when blocks does not get fully verified. When [BIP 66](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki) (strict DER encoding of signatures) was implemented, some miners running the BIP 66 enabled Bitcoin Core versions were listening to pre-BIP 66 pools. One of the pool running a pre-BIP 66 version produced a block that had an incorrect block version number. The miner with BIP 66 started working on top of that unverified block by processing an empty block.

However, their `bitcoind` never accepted the full block as it was invalid. The result was [building a series of empty blocks](https://bitcointalk.org/index.php?topic=958036.40) on top of the other that were ultimately not accepted by the network.


---

