Block hash collisions could break most Bitcoin implementations in horribly and unexpected ways, but they won’t happen unless you harness all the energy in the observable world and then some of it for the sole purpose of finding a collision, or discover a cryptographic weakness in SHA-256. Granted, block hash collisions are theoretically more likely to occur as difficulty increases, but not enough to be a problem.
I was wondering why the block ID is not defined as a hash of the entire block instead of the header
The header contains the transaction Merkle tree root, so it is indirectly committed to the entire contents of the block anyway. This method is more elegant and efficient.
- When a node receives a new block, it first downloads and verifies its header to perform proof of work. This prevents other nodes from cheaply spamming out entire fake blocks that waste time validating, and may also ensure that only blocks with valid proof of work are downloaded.
- Similarly, during the download of the first block, the node uses a “header-first” synchronization strategy. This allows you to know the block hash of every block in most proof-of-work chains by simply downloading and verifying the header. This prevents some types of DoS attacks, facilitates parallel block downloads, and probably provides other benefits as well.
- SPV wallets and other light clients can use headers to verify the inclusion of transactions in the chain. (Their limitation is that they can only verify proof of work and not other consensus rules. The assumption is that miners will not waste hashing power mining invalid blocks.)
Discover more from Earlybirds Invest
Subscribe to get the latest posts sent to your email.
