Data Integrity of the Block

Below is the raw data for the fields of the block header from block 550204 that we used for Chapter 3.

Let's see what happens to the block hash as we try to add an additional transaction to the block after the proof of work solution has been found and broadcast to the nodes of the network. Perhaps this transaction could be to redistribute coins that have already been spent on the network so that they may be spent again. The TXID seen below is converted to little endian, then double hashed to generate the right-hand branch value. The left-hand branch value which was formerly the Merkle root (converted to little endian) is concatenated with this right-hand branch value and double hashed to generate the new Merkle root.

Now the New Merkle root that has been calculated has been added to the Merkle root data field of the new block header candidate and serialised to generate the 80-byte string.

In the table below after passing the 80-byte string through a double application of the SHA256 function, the new block hash does not even come remotely close to being under the difficulty target. Therefore, to even attempt to promote this as a valid block with a proof of work solution, more attempts at the hash puzzle would have to be made by incrementing the nonce until a valid solution was found.

As can be seen from this exercise, if the hash of the previous block can only be generated using specific inputs for the fields of the block header (including the Merkle root of the transaction set), then it is practically impossible to insert a transaction into a previous block as doing so will generate a completely different Merkle root and therefore a completely different output when hashed with the nonce published for that block (which will be effectively guaranteed to fail to satisfy the hash puzzle). Even if a block hash can be generated which comes in under the target value, this block hash will also be completely different as an input into the subsequent block, and therefore any attempt to verify the subsequent block's proof of work with that nonce value will fail requiring the proof of work for that block to be redone as well.

This means in order for an attacker to introduce a new version of a block's transactions, which may include one that redistributes tokens to them self that they have already spent, they would need to execute the proof of work process until a fresh hash puzzle solution was found. They must then also win the race to solve the next hash puzzle before they could attempt to promote their version as the longest proof of work chain.

If they wish to introduce a double spend transaction from more than one block ago, they must redo the proof of work of all subsequent blocks and then catch up to the legitimate chain tip and win the next block to be successful in their attack. This has the effect of making transactions that occurred deeper than a certain amount of blocks practically impossible to change.

It is the efficiency of the Merkle tree as a data verification process that allows a node to check that the transactions in a block generate the same Merkle root as fast as possible to know whether they should dedicate their resources to building upon the solved block broadcast by another node or continue to execute proof of work on the current block. As the BSV network is completing trillions of hashes per second, every moment counts in creating a node's competitive advantage for finding a solution to the next block's hash puzzle and having that block built upon by other nodes.