A Discourse on Nodes

Date: 2020-05-27

Source: https://craigwright.net/blog/bitcoin-blockchain-tech/a-discourse-on-nodes

---

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](http:/www.bitcoin.org/):

*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.

---

← Back to archive