Blog > Bitcoin & Blockchain Tech

Security, the Blockchain, and Hashed Headers…

By Craig Wright | 03 Jun 2021 | Bitcoin & Blockchain Tech

The false mythology has been created and propagated that you need to run a ‘full node’ to secure blockchain networks. The deception has been promoted by individuals associated with BTC Core seeking to maintain control of the respective system. Such individuals tell you that you help run the network by holding blocks. They fail to point out that the consensus mechanism in Bitcoin is entirely based on the creation and distribution of blocks. Nodes were defined in section 5 of my white paper:

  1. New transactions are broadcast to all nodes.
  2. Each node collects new transactions into a block.
  3. Each node works on finding a difficult proof-of-work for its block.
  4. When a node finds a proof-of-work, it broadcasts the block to all nodes.
  5. Nodes accept the block only if all transactions in it are valid and not already spent.
  6. Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.

For systems that are not nodes, there is no need to propagate blocks. All nodes must do it. There is a single consensus mechanism within Bitcoin: it is the creation of a valid block. It is required that nodes not only create a block, but maintain it for 100 blocks past the validation of the block. That is, if at time T(0) a node n(i) discovers a block, the node only receives payment and the block is only considered settled at time T(100). In other words, the maturity period of 100 blocks is part of the Bitcoin consensus mechanism. It is not merely discovering a block but building upon all the available blocks that forms consensus within Bitcoin.

Consequently, it can easily be seen that the only way to have any participation in the consensus methodology is to build a new block. Nodes that have not followed the exact same process to create blocks do not form part of the consensus. The matter should be simple. Yet, a few dishonest individuals have sought to promote the concept that Bitcoin and blockchains generally require lots of users running machines that do nothing. The equivalent scenario may be one where individuals don’t vote in political elections.

Imagine that Alice and Bob and Charles are voting in an election. Each year, the result will depend on whether Alice, Bob, and Charles vote for option one or option two. Now, Edgar comes into play. Edgar walks in and says, “I’m not going to vote.” Edgar now brings in a thousand friends, who all don’t vote. The result remains entirely based on the decision of Alice, Bob, and Charles. Edgar can say that he has the majority of people behind him, but none of the individuals vote—so none of them matter in the process. Which is how Bitcoin works.

There can only be a few nodes that are active within Bitcoin. Bitcoin is distributed as a Pareto system, with a maximum of 2016 blocks discovered in any difficulty-adjustment period. Consequently, as the system is not equal, and as it cannot be designed to be equal, there will always be a few large corporations finding solutions for the majority of blocks. The result is that only somewhere between 25 and 200 nodes will exist at any time.

But What about the Security of the System?

So, we know that nodes only matter when they are creating blocks. As explained, it is the only consensus methodology in Bitcoin. The argument against it is that ‘full network nodes’, as they have been falsely described, are said to be important in holding full copies of blocks. It is argued that only with full copies of blocks can individuals know whether a change has occurred on the network. The argument can be demonstrated as false.

Bitcoin utilises a binary tree structure to collapse what could be an incredibly large set of transactions into an easily searchable path. Such a structure is only necessary when there are many transactions included in a block. By ‘many’, we are talking about millions of transactions as a minimum—and potentially billions.

In analysing the structure of the block header, the reader will notice that the Merkle root (the highest-level hash structure and a binary tree algorithm) is contained within the block header.

Image source:

The Bitcoin block structure incorporates the binary tree or Merkle root, which is added to the previous block hash and other information. The information in the block header is concatenated and hashed. Consequently, if the Merkle root or any information in the block header changes in any way, the entire block will be invalid.

So, when we consider that the Merkle root captures the information within the entire block, and that if the order of transactions or any information within them is altered in any way, the entire system is rejected, it becomes easy to understand that you don’t need to transmit the entire block. A copy of the Merkle root gives you everything you need to prove the integrity of the block over time. Here lies the purpose of hash algorithms. And, if SHA-256 is not secure, then it doesn’t matter whether you have the whole block or not.

Next, if your system manifests that you don’t like the contents of the block, you can’t do anything about it unless your system happens to be a node. As a node operator, you need to be a miner. The consensus mechanism, as noted before, lies solely and exclusively in the creation of blocks that the other nodes agree are valid.

So, the irony is that the argument for distributing an entire block to all systems on the Bitcoin network, rather than using simplified payment verification (SPV), presents a mistrust of the integrity algorithm and hence a mistrust of the entire system. Logically, if you consider that a change to any transaction in a block leads to a completely different Merkle root and thus a completely different hash header for the block, it is easy to understand that holding only the hash header provides you with just as much information about the integrity of the block over time as does holding the entire block.


Bitcoin Full Node Explained. (2019, August 19).

Full node. (2020, June 23).

Consensus. (2016, May 28).