A rational argument around nodes

Getting your Trinity Audio player ready...

This article was first published on Dr. Craig Wright’s blog, and we republished with permission from the author.

There is a strange belief that non-mining systems can be nodes in Bitcoin (and, by extension, on the BTC¹ network)—without creating blocks. Then there are arguments that they help with ‘routing’ and distributing transactions. Let us imagine now that there are four mining pools called Alice. I will refer to them as Alice(i) to represent each of the nodes (miners/pools) as Alice(0), Alice(1), etc. As the BTC network derives many of its characteristics from Bitcoin, I will not seek to differentiate between the two networks in any depth for this post. But, I will note that the BTC network is merely a copy being passed off as Bitcoin. Equivalently, we will allow a set of other systems, that are not mining blocks, to be called Bob(j). A potentially unlimited number of such systems can connect to the network.

While there may be around 15 to 16 nodes, only four nodes, and sometimes as few as three, control the BTC network from a mining perspective. It is important to remember that consensus is formed when nodes build upon a block discovered by another node. Likewise, the only way to reject a block is to not build upon it. Importantly, for a miner to be paid, it is essential for the block discovered by the miner to be built upon to the extent or depth of 100 further blocks.

Whilst the scenario is hardly in dispute, there are rather spurious arguments concerning the structure of nodes. Some authors have gone as far as to argue that attacks on the network could be conducted by ‘isolating nodes’ (Apostolaki et al., 2017). To this end, the authors’ creation of blocks within the network has led to highly convoluted avoidance strategies (Apostolaki et al., 2018) that are designed to protect systems such as internet-based networks that operate in a more traditional distributed form of connectivity and that do not have any relevance to Bitcoin or the nature of the network. The presumption is that an attacker altering the BGP tables could isolate nodes. The error with such a concept lies in assuming that Bitcoin nodes are anything other than commercial server farms.

The mining pools operating on the BTC network are the entities that create blocks. The assertion is simple to verify. The creation of blocks is published, and it is possible for any member of the public to easily validate the creation of blocks by any entity. As all blocks are displayed, and the payment to miners is recorded within the hash header, whilst it may be possible to stay private for some time, it becomes possible to validate the existence of any miner over time. As a result, I will not spend too much time debating the creation of blocks. Rather, I will focus on some of the spurious side arguments, including how home nodes would be necessary for routing Bitcoin transactions.

Routing

It has been demonstrated that Bitcoin forms a small-world network in all its forms (Javarone & Wright, 2018). The same concept includes any copied instantiation of the Bitcoin system, such as the BTC system or even an altered system such as Litecoin. While some scholars have claimed to have discovered up to 359 mining nodes (Saad et al., 2021), the reality is that each of the systems would be owned by the same network operator or company. Here, the original definition of a Bitcoin mining node or farm, as provided in 2008, must apply, and although there are multiple systems comprising the node, the node is controlled by a single entity. The node structure of multiple systems also demonstrates the problems with claims that thousands of nodes would exist.

Researchers such as Park et al. (2019) failed to note that many of the systems they referenced as nodes were using a version of BTC software that could not process existing transactions or blocks. A system that will not verify blocks cannot be considered a node. Taking a single entity for a single node no matter how many servers it runs is analogous to noting that each instance of Bitcoin can be run on a single thread in the multithreaded processor or CPU. The distribution of servers adds resilience and power, but it is not changing the nature of control of the node.

Consequently, we can measure the distribution of systems whether they create blocks or not. As Tao et al. (2021) have done, it becomes possible to measure the degree of connectivity between Bitcoin nodes (also BTC nodes) and systems that act without creating blocks. Such an analysis makes it possible to measure the network distance between each node (miner) and between other systems and nodes. What matters is that connectivity reaches a node that is defined as a miner. The reason is simple: if a system does not receive a transactional block that is engaged in building more blocks, there will be no consensus within the BTC network. As such, the nodes commonly referred to as miners must receive a transaction or block. The only purpose or argument that could be made in favour of other systems would lie in routing.

Mining nodes can, as Baumann, Fabian, and Lischke (2014) have done, be demonstrated to have a highly connected structure with a very low-degree distribution for the network. Alternatively, the distribution of nodes that do not create blocks is of a relatively high degree. Mining nodes have an average of 14,000 connections to other systems. Every mining node is densely connected with other mining nodes through at least one connection. Every mining node has at least 11,000 edges. Conversely, the so-called ‘routing nodes’ have an average of slightly over eight edges. The ‘routing nodes’ do not even connect to all mining nodes, let alone exchanges.

In any modelling of connectivity between exchanges, mining nodes, and other commercial entities, it is noted that there is a very small hop count between systems. On average, every transaction arrives at every mining node from any exchange on the network in one hop. More importantly, the chances of even randomly connecting a Raspberry Pi ‘routing node’ and not directly connecting to one of the mining nodes or interconnected systems are under 1.1% at any particular time.

The scenario is derived from the large number of edges presented by such systems. The mining systems maintain connectivity across the entire BTC network. Let us now assume Alice(i) to be the set of mining nodes and, equivalently, Bob(j) to represent an alternative ‘full node’ or ‘routing node’, that is not in the business of creating blocks. If Bob(j) wishes to send a transaction to Bob(not_j), the chances are that the first-instance hop will lead to at least one Alice(i) system. After the second hop, every single mining node will have had the transaction. When it comes to creating a block, note it will never come from Bob(j), by definition; in a single hop, there is a more than 99.8% probability that every single mining node will have the block. At the same time, in the same single hop, the transmission will account for over 99.999997% of the network.

Any mining node will quickly seek to connect to every other mining node and thereby help maintain the high interconnectivity between the systems. Next, if we look at what happens when any Alice node releases a block, only a fraction of the home-user Raspberry Pi ‘nodes’ will have the same block in a single hop, and others, even for that hop, will be slow to process it. Then, as the interconnectivity between all Alice nodes is high, every single mining node will have received the block before a single Bob node.

If Bob nodes are to be considered to rout anything on the network, it must be noted that an Alice node will have already received any transactions any Bob nodes make to the Alice node. Once a transaction has been received, it is not received a second time. Consequently, any activity conducted by a Bob node is rejected by any consensus-forming node. The simple answer is that no nodes other than those creating blocks have any relevance in the Bitcoin network (or the BTC network for that matter). Whilst it is possible that a Bob node may be acting as an exchange or another economic entity that wants to monitor network activity, they do so for their purposes. They offer no benefit to the security or distribution functions of the network.

Conclusion

The only purpose of running a ‘node’ that does not create blocks is to monitor and receive transactions slightly faster and to validate the receipt of your transaction faster. There is no benefit to the network overall. Yet, there are promotions in the name of Bitcoin as a system that are completely detached from the reality and design of the system. The idea is simple: to mislead individuals and regulators about the nature and distribution form of the network. There is no purpose or benefit in having any number of ‘routing nodes’ on the network. They offer no benefit outside the false information being spread concerning how ‘routing nodes’ would be essential. They are, in fact, as demonstrated, simply superfluous.

Footnote

[1] Note, BTC is not Bitcoin. It is a ticker symbol associated with a system that is emulating components of Bitcoin and being passed off as Bitcoin.

References:

Amaral, L. A. N., Scala, A., Barthelemy, M., & Stanley, H. E. (2000). Classes of small-world networks. Proceedings of the national academy of sciences, 97(21), 11149-11152. https://doi.org/10.1073/pnas.200327197

Apostolaki, M., Zohar, A., & Vanbever, L. (2017, May). Hijacking bitcoin: Routing attacks on cryptocurrencies. 2017 IEEE symposium on security and privacy (SP), 375-392.

Apostolaki, M., Marti, G., Müller, J., & Vanbever, L. (2018). SABRE: Protecting bitcoin against routing attacks. arXiv preprint arXiv:1808.06254

Baumann, A., Fabian, B., & Lischke, M. (2014). Exploring the Bitcoin Network. WEBIST (1), 2014, 369-374.

Javarone, M. A., & Wright, C. S. (2018, June). From Bitcoin to Bitcoin Cash: a network analysis. Proceedings of the 1st Workshop on Cryptocurrencies and Blockchains for Distributed Systems, 77-81.

Park, S., Im, S., Seol, Y., & Paek, J. (2019). Nodes in the bitcoin network: Comparative measurement study and survey. IEEE Access, 7, 57009-57022.

Saad, M., Anwar, A., Ravi, S., & Mohaisen, D. (2021, November). Revisiting Nakamoto Consensus in Asynchronous Networks: A Comprehensive Analysis of Bitcoin Safety and ChainQuality. Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, 988-1005.

Tao, B., Dai, H. N., Wu, J., Ho, I. W. H., Zheng, Z., & Cheang, C. F. (2021). Complex Network Analysis of the Bitcoin Transaction Network. IEEE Transactions on Circuits and Systems II: Express Briefs.