Broadcasting the Block

Now that there is a correct solution to the hash puzzle for the block, it is of paramount importance that this solution and the block is broadcast to as many other nodes on the network as soon as possible so that they can make sure that none of the transactions that are included contradict their ruleset for validity. When they successfully validate the block, the other nodes will use the double SHA256 hash of this newly found block's header as the PrevBlockHash input for their next block template.

If a node detects invalid transactions or rule-set violations within this block they will reject the block and continue with their proof of work process for their current transaction set. It is because of this duty for nodes to check each other's proof of work, that each node is incentivised to share their transaction sets and Merkle trees with all other nodes on the network. If you are handling a set of many millions of transactions and the respective Merkle tree, there is a risk that although you may have indeed found a correct proof of work solution, if another node takes a long time to validate the block, they may receive another block proposal in the interim for a block where they have already been provided all the transactions to validate and therefore, they will use that block's hash to reference in their new block template first. The bitcoin system is designed with these kinds of incentives for many of the activities that a node undertakes whereby it is always more favourable to be honest and fully disclose all the transactions you are processing, as soon as you have validated them, to as many nodes on the network as possible. In that way when they receive the hash of the header, they will have already validated every indexed transaction, the TXIDs of them and the respective Merkle tree for that chronological ordering. In this way, each node may hold numerous different Merkle trees concurrently as they also want to get to working on the next proof of work puzzle as soon as possible to maintain their competitiveness with the other nodes. Each node is incentivised to provide their Merkle trees to one another as well as incentivised to request the details of the Merkle tree making the openness mutually beneficial.

The above animation shows nodes A and B mutually sharing their transactions and Merkle tree arrangements in real time while node C only maintains this data from node B. We can see node C is then at a distinct disadvantage when node A produces a block that it then needs to download, validate all the transactions within it and calculate the Merkle root to check the Proof of Work. In the animation we can see node A ends up 5 or so incrementations of the nonce ahead of node B and 15 ahead of C. These values are there simply to illustrate the dynamics of the arrangement, however in reality with blocks containing millions of transactions and even a single S19 ASIC unit capable of executing 110 000 000 000 000 hashes per second, even a delay of 10s to download the announced block, validate the transactions and construct the Merkle root puts node C quadrillions of attempts behind at finding a solution for the next block.

Assuming all other nodes did not detect any invalid transactions or rule-set violations, we will continue as if the hash puzzle solution is approved of by the majority of nodes on the network and each node will now commence the proof of work process anew on the transactions that have occurred since those that were included in the Merkle root for the previous block.