Blog > Bitcoin & Blockchain Tech

A Discourse on Nodes

By Craig Wright | 27 May 2020 | Alternative Coins & Systems

The definition that has propagated around the description of a Bitcoin node has led to a rather cultish ‘quasi-religion’. I will call it a religious belief as it is clearly one not based on rational thought. Unfortunately, there is a lot of vested interest and investment associated with promoting a false concept of Bitcoin. There are two aspects to the Bitcoin network, formed by network nodes and clients. In the distant past, I have tried to explain difficult concepts in a manner that is as simple as possible, and I have used the term “client nodes”.

In the mathematical discipline of graph theory, there is the concept of a vertex or node. The same concept is represented in computer science. The mathematical origins of the corresponding part of computer science linked the two descriptions seamlessly. Nodes of vertices would be connected through edges. The distinction, here, people do not seem to understand is that the peer-to-peer network of Bitcoin nodes is defined by the miners. The clients or users of the system are not nodes, as they are not producing blocks. Any ‘node’ that does not produce a block does not engage with the consensus mechanism of the network in any manner.

In a flooded, near-complete network, the actions of client systems are irrelevant. Client systems do not aid in the verification or propagation of blocks in any format. At present, there are under 10 nodes that control any blockchain, blockchain-like, or ‘cryptocurrency’ system in existence. People like to make the assertion that there are thousands of Bitcoin nodes, which is propagated as an idea throughout the BTC community. The idea is false. The computational power fluctuates between five groups at any time. At present, only three groups control the network consensus. Anything past 20 nodes is irrelevant and an anomaly at best. At present, once you get past 10 nodes, anything else becomes an anomalous rounding error. Every one of the 10 nodes is densely connected. Removing 99.999% of client connectivity would do nothing to the propagation of transactions. At most, a transmission by a client will be propagated to over 95% of the network in two hops.

If we look at the corresponding original description, on the original website, we can see my badly (alpha) written explanation, which yet exceeds what many people understand today:

There are two ways to send money. If the recipient is online, you can enter their IP address and it will connect, get a new public key and send the transaction with comments. If the recipient is not online, it is possible to send to their Bitcoin address, which is a hash of their public key that they give you. They’ll receive the transaction the next time they connect and get the block it’s in. This method has the disadvantage that no comment information is sent, and a bit of privacy may be lost if the address is used multiple times, but it is a useful alternative if both users can’t be online at the same time or the recipient can’t receive incoming connections.

The primary network is a peer-to-peer (P2P) network, in the true and most used sense. The definition of a P2P network is really skewed in the sense that it is referring to a non-server-based system. In other words, it is a distributed system. The notion of miners refers to the only real nodes in the Bitcoin network. As such, users would be separate to the actual Bitcoin network. Users interact with the system.

Contrary to the false information that is spread about Bitcoin, users have no say in the network. The consensus mechanism is purely derived from network nodes creating blocks. So that nodes cannot simply cheat, there is a maturity period of 100 blocks. The maturity component means that blocks that are created can be analysed such that, if needed, actions can be taken by the network nodes. Actions could even include legislative actions or criminal sanctions against dishonest actors. Having said so, there is no connectivity effect between client systems.

As explained, the primary nodes are all highly connected in a near-complete graph. Here, we see that over 98% of the network CPU power is directly connected. That is, it is connected by a single hop. As such, any transaction sent by a user to even a single node will be with almost every other network node in one further hop. Such commercial servers pay for high bandwidth, high-capacity routers, and network equipment. In all events, the connectivity between network nodes exceeds the connectivity of all client nodes.

Let us look at an example of what occurs when a block is distributed on the network or a transaction is propagated by nodes (again, note that I am referring to network nodes and not clients any time I say “nodes”).

If client A sends a transaction to a single network node and seven other clients, at a time T=1, even as it gets nowhere but to a single network node and many client nodes, the next hop will make any action by any number of client nodes irrelevant.

After T=1, the transaction will be received by a network node that is incentivised, through commercial means, to install fast hardware that will validate and propagate the transaction faster than any client can. The network nodes are also incentivised to get transactions to other network nodes very quickly. As such, when we come into a time T=2 or the next period, all the network nodes will have received the validated transaction, that they can now validate, too, before receiving it from any client node.

The result is that the hash of the transaction being received from a client will match that which is already in memory at each of the network nodes. On the second hop, every single network node will have received the validated transaction, that it will now revalidate. Any communication from users or clients is then rejected. Consequently, the only time that any communication from a client system matters at all is when they initially send a transaction. In other words, any communication between one client system and another is wasted bandwidth, making no difference to any consensus process on the network.

To contradict the common myth, there is no such thing as a candidate block that is sent across the network. A candidate block is the node’s own block solution that it is working on. As soon as the valid proof-of-work has been discovered, it is no longer a candidate block. As only completed blocks are propagated, other nodes do not decide on the validity of candidate blocks. Effectively, the most efficient method for sending transactions is to send directly to network nodes. Doing so will reduce wasted bandwidth on the network. It cannot increase network bandwidth among network nodes as at no point will the nodes not receive the transaction. Network nodes need only check the initial hash of a transaction, and can reject a second copy immediately—as soon as a hash has been matched.

James Donald, as he is involved with several nefarious activities such as promoting child pornography, sought a system different to Bitcoin. Unfortunately, I did not realise his intentions at the time, and it was well after 2008 that I would come to understand what sort of person he was. Having said so, Bitcoin is designed in a way which cannot be changed towards the system that people like James Donald would like. When James Donald said that Bitcoin did not seem to scale to the required size, it was because he wanted a system where users of the network voted. Yet, Bitcoin is not designed in such a manner. In fact, it is designed so that it cannot be redesigned as such.

When James Donald was saying that the bandwidth would not scale because of the requirement to send transactions to every single person, he was assuming, in error, that each node on the network must receive every transaction, having failed to read and understand section 8 of the white paper, on simplified payment verification (SPV). Most of the ‘nodes’ (here, in the mathematical sense of the ‘edge nodes’ or user/client systems) on the network require merely the block headers, which are to be distributed to them and processed. It is only when they receive a transaction that they require any extra information. I pointed the following out to James, in 2008, but again, I failed to understand that he did not want a system like Bitcoin:

Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node [emphasis added].

We have already achieved specialist server farms. Certain mining pools and corporations, as they see value in not having to build systems that fully scale, simply promote a myth that limits the use of Bitcoin, allowing a few monopolistic actors to mislead those seeking investment in the system. Although Bitcoin is not based on a single monopolistic entity, at present, the major mining pools act as a cartel. Without regulations, a scenario that has come about through the misinformation being spread by people within the community, such companies have been able to maintain dominance without developing and expanding the system.

Something else people do not understand, in contrast to what was promoted by people like James Donald, is that Bitcoin is not a system of continuous issue. All coins were issued at the instant I launched Bitcoin in 2009. The coins are distributed under a unilateral contract. There is a big distinction between distribution and issuance that people do not seem to grasp. Just under 21 million coins (bitcoin) have existed from the first discovered block in 2009. There are no new bitcoin being created; they are tokens that already exist and that I could have decided to keep, in part, for myself—not as a ‘pre-mine’, but as a payment. I did not do so. In the creation of Bitcoin, I allocated and issued 100% of the created tokens to those who would support the network.

In effect, the unilateral contract that I created allows agents, under a set of predefined rules or contractual terms, to come and go at will.

Bitcoin Is a Set of Indivisible, Fungible Tokens

Each normal unit called bitcoin relates to 100 million digital tokens. Each of the tokens can be thought of as a digital grain of rice. All the tokens have the same quality, and are in themselves indivisible, allowing them to be fungible. A token is not the same as an unspent transaction output (UTXO). A UTXO may be analogised as an envelope holding a set of tokens. Imagine each UTXO as a bag or an envelope holding a defined number of grains of rice. Although the UTXO itself is recorded separately, the contents of the UTXO are completely fungible, and it is impossible to distinguish between each of the virtualised grains of rice or digital tokens.

As we look at bitcoin as a set of tokens held in envelopes, when a user exchanges them with another user, such as through the original IP-to-IP protocol, they are simply network clients. They can take the form of an SPV client or a web client or many other forms, including one of a fat client that self-propagates.

Bitcoin was constructed such that people could send transactions whether they were online or not. The primary methodology was to connect directly to the individual you were paying and exchange a transaction with them. Again, I explained it on the original ‘BitCoin’ website:

There are two ways to send money. If the recipient is online, you can enter their IP address and it will connect, get a new public key and send the transaction with comments. If the recipient is not online, it is possible to send to their Bitcoin address, which is a hash of their public key that they give you. They’ll receive the transaction the next time they connect and get the block it’s in. This method has the disadvantage that no comment information is sent, and a bit of privacy may be lost if the address is used multiple times, but it is a useful alternative if both users can’t be online at the same time or the recipient can’t receive incoming connections.

More importantly, I detailed the scenario in the first sentence of my abstract in the white paper. As it says, payments may be sent “directly from one party to another”. To send a direct payment, you do not connect to network nodes and hope that they will send it later. You connect directly to the individual you are seeking to pay. Although it is possible to receive transactions while offline, “[t]his method has the disadvantage that no comment information is sent, and a bit of privacy may be lost”.

I find it unfortunate that people cannot think for themselves even now. The cult that has promoted Bitcoin in order to enable the facilitation of crime and money laundering and the creation of Ponzi schemes, designed to milk the general population, does not seek to educate people; it is rather selling a lie.

So, to recap, I will again say that clients of the network are not nodes. It does not matter whether you are a merchant who is trying to propagate transactions, a full Bitcoin Core protocol client, or anything in between. If you are not validating transactions and creating and winning blocks, you are not a node. Full stop.

Some people want to refer to things that are not involved in the consensus process of Bitcoin as nodes. But, it should be simple: there are nodes, and there are clients. Nodes create blocks. Nodes validate transactions. Nodes do everything that is explained in section 5 of the white paper. It is very simple: if you are not doing every single thing referred to in section 5 of the white paper, you (the computer systems) are not a node in any sense of the word.

So, we should not be trying to come up with arbitrary terms such as ‘transaction nodes’, ‘propagation nodes’, or ‘transaction-processing nodes’. There is no such thing in the Bitcoin network as a node that does not create, validate, propagate, and win blocks.

The main properties noted on the original ‘BitCoin’ webpage tell us how double spending is prevented with a peer-to-peer network. The network of nodes (miners) is a standard broadcast or flood network. It does not present how users are interacting, of course. There was not really much differentiation in 2009 as it was an alpha software project. The main part of it being a peer-to-peer network lies in its resilience: the nodes may come and go at will. There is no requirement to be connected all the time.

Network clients are the users of the network. Being that we are looking at a mandala network, there can be other forms of networks overlaid on top of Bitcoin. Here, you can have autonomous agents, storage entities, and even propagation entities. None of them are nodes on the Bitcoin network. A ‘storage and archive node’ may be a node, but it is not a node on the Bitcoin network unless it is part of a mining operation. A storage and distribution network will have its own nodes. So, a ‘storage node’ is a node on a separate overlay network. It is not a Bitcoin node in any sense. A ‘storage node’ that is not a miner is not a node on the Bitcoin network, but is rather a node on a separate network, which may use the Bitcoin system as an index function.

The problem in trying to distinguish between the two networks (of miners and of clients) is that there are not really two networks in the basic implementation of Bitcoin. Users, network clients, connect to each other. They form a direct connection, which is not truly a network as such. The nodes or miners are in a veritable peer-to-peer network. Other networks can be formed. Again, we are looking at what I have referred to as a mandala network. The other networks are separate, overlay networks—built between the clients of the network. Each client can form a node in a network separate to Bitcoin and that uses Bitcoin’s blockchain both as an economic-incentive and coordination system and as an update and index system.

The system can be created as a fully peer-to-peer network as we saw it in systems such as Mojo Nation two decades ago. The problem with Mojo Nation was the limitation on the economic incentive structure. Bitcoin clients can be nodes in a separate network; there is no limitation on how many functions a computer system can be engaged in, so a system can be both a client of one network and a node in a separate one.

Nodes in the Bitcoin network are what I, at first, called network nodes. When I was referring to them as systems that would end up in data centres, I was not referring to single machines. A node does not need to be an individual computer. Even now, an individual computer is made of multiple cores and separated into a variety of highly linked systems. In effect, even a local desktop computer or a laptop really consists of multiple computers. Having said so, a network node, a node on the Bitcoin network, would be made up of many systems. It will include the routers, the databases, and all the different equipment, systems, and networks necessary for handling the creation and propagation of blocks.

Right now, many people have the false idea that the Bitcoin node needs to run the database on the same machine, which is an asinine and provably illogical concept. The database used from the beginning of Bitcoin is a separate service. It does not matter whether a service such as a database is on the same or a separate machine. So, whether it is a single machine or whether it is split into many machines, a node remains a node.

Early on, in trying to explain the concept, I referred to clients as “client nodes”. In graph theory and science, each of the users could be represented as a node in mathematical terms. The problem with such terminology is that the same word has other connotations. If we do call it anything, it has to be a ‘client node’, but such a term leads people to believe that a ‘node’ as a client would have some representation on the Bitcoin network itself.

My answer to our (so-called) dilemma is very simple…

The Bitcoin network has one form of node. There are separate components that make up a node. The database, for instance, presents only one aspect of a network node.

A client system is not a Bitcoin node. There can be other node structures and node networks built by using Bitcoin; such may be nodes of other, overlay networks. They are not and cannot be considered Bitcoin nodes.

It may be a blow to some of you, but your user-activated soft fork (UASF) system is not a node, has no impact on the Bitcoin protocol, and cannot ever have any impact or relevance within Bitcoin.