You will never find a statement from me in my persona of Satoshi saying that Bitcoin was designed for ‘censorship resistance’. The reason for it is simple: such is not the purpose or design of Bitcoin. Unfortunately, several disingenuous actors, including the Electronic Frontier Foundation (EFF), simply took it upon themselves to change the narrative. Recently, developers of the BTC Core system have started arguing for further radical changes—differentiating the system more and more from Bitcoin. Using BIP 324, Jonas Schnelli has attempted to implement encrypted transport layers, that are designed to hide transactional exchanges from law enforcement and other systems seeking to monitor Bitcoin transactions.
To the same end, the media teams associated with BTC Core are continuing to spread their false propaganda. In an article on BIP 324, Bitcoin Magazine author Tony Sanak wrote:
“Bitcoin: A Peer-to-Peer Electronic Cash System” is the title of the Bitcoin white paper and, as it suggests, the P2P layer is a major component of the Bitcoin network but also the one with significant inefficiencies and existing theoretical attack vectors.
Making false analogies, the publication compares Bitcoin to Napster, so they may support their false claims.
Like developer groups of other systems who have sought to promote crime (as it was the case with the former Napster network), the BTC Core group seek to conceal the criminal activity on their system. To do so, they have to gradually change the BTC Core protocol and move further and further away from the Bitcoin protocol, which they have copied, as they seek to fraudulently pass BTC Core off as Bitcoin. Yet the core protocol of Bitcoin is remarkably resilient. No matter how actively developer groups have sought to alter the copied Bitcoin protocol, they have not managed to remove the primary functionality of Bitcoin. As a result, BTC Core will remain hierarchical in its structure, and the nodes of the system will always be subject to legal enforcement.
In another move to deceive readers, the author goes on to say: “In the ideal configuration, P2P networks shouldn’t have any hierarchy (all nodes are equal), and nodes should share the network load uniformly”. Of course, Bitcoin was not designed in such a way. More importantly, the author is attempting to mislead the non-technical readers of the article by trying to have them believe that ‘nodes’ that do not mine blocks were nodes. Section 5 of my white paper is self-explanatory when it comes to the definition of nodes:
- New transactions are broadcast to all nodes.
- Each node collects new transactions into a block.
- Each node works on finding a difficult proof-of-work for its block.
- When a node finds a proof-of-work, it broadcasts the block to all nodes.
- Nodes accept the block only if all transactions in it are valid and not already spent.
- 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.
The only consensus mechanism within Bitcoin lies in the competitive creation and distribution of validated blocks of transactions. Any system that does not create blocks has no impact on the network. Bitcoin is designed as a small-world system. It is not a mesh. If we have two nodes, A and B, that are not directly connected, it is essential to remember that each node is highly connected otherwise, with some nodes (aka miners) having over a thousand connections (or network edges). In other words, in the rare instance that nodes A and B are not directly connected, as in figure 1, they will not have a single path but many paths to each other through the network. If we assume that the red intermediary nodes seek to block transactions, there will always be other transactions, ones that allow node A to get a transaction through to node B. In figure 1, a small subset of nodes provides direct and simultaneous communications to node A, and connects through to node B.
Figure 1: Nodes A and B are not directly connected.
If the nodes in figure 1 that are coloured red attempt to boycott the transaction, there will be no impact. It is as if they did not exist, but the transaction continues to be propagated. The state is the same as one where the red nodes in the network diagram only validate and do not create blocks. Where an entity does not create blocks, it is irrelevant and is not a node. Remember, the only consensus mechanism in Bitcoin lies in the creation of validated blocks. You cannot obstruct a transaction or a block other than by not creating a block with the transaction. So, the entire concept of “validation nodes” on Bitcoin is a falsehood.
A more accurate representation of how nodes are connected is presented in figure 2. For any node to not be connected would be considered improbable. The investment in becoming a node would generally preclude excluding the construction of adequate network mapping, that will allow the notice to all other nodes. The hash function in Bitcoin presents a de-anonymisation protocol. Any significant node is incentivised to get their blocks and transactions distributed as quickly as possible, to all other nodes. Such systems only care about other nodes; the node owners do not care about so-called “validation systems”.
Figure 2: Nodes A and B are connected.
In the representation of a subset of the Bitcoin network in figure 2, where we represent the green nodes as nodes in accordance with section 5 of my white paper and where the red entities are what many people in the BTC Core community like to call “validation nodes”, we see that the red systems are entirely irrelevant. A path between all of the nodes (aka miners) exists no matter which “validation node” attempts to say that a transaction is not valid. In effect, there is no action that a so-called “validation node” can take that would have any relevance to the Bitcoin network.
So, the circle claims of routing attacks and hijacking Bitcoin have no merit. More critically, the claim that because Bitcoin is not encrypted, it can be hijacked, is false. The README file in the original Bitcoin source code contained the following:
Bitcoin does not use any encryption. If you want to do a no-everything build of OpenSSL to exclude encryption routines, a few patches are required. (OpenSSL v0.9.8h).
Bitcoin was designed not to be encrypted. Bitcoin was designed to operate as a clear-text system.
In the article on BIP 324, the author writes:
In the ideal configuration, P2P networks shouldn’t have any hierarchy (all nodes are equal), and nodes should share the network load uniformly. This basic layer of a mesh of interconnected nodes is what helps Bitcoin to be censorship-resistant.
The problem with such an argument is that Bitcoin is not a mesh, and Bitcoin is not designed to be “censorship-resistant”.
More critically, Bitcoin was never designed to be a flat network, without hierarchy. Bitcoin was intentionally designed such that nodes compete, and hence nodes are not equal. When I released Bitcoin, I explained the nature of the system rather plainly (emphasis added):
- 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. – 2008 (URL)
- At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN. – 2010 (URL)
- The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don’t generate. – 2010 (URL)
Bitcoin was designed with the combination of simplified payment verification (SPV)—for users—and the ability to act as a node—to earn money, to be paid. Bitcoin, at its base level, is hierarchical. Nodes compete to create blocks of validated transactions. In their blocks, they seek to include as many transactions as possible. Also, in 2008, I said that Bitcoin could already scale to the level of Visa back in the same year. With, on average, 144 blocks a day and 100 GB of transactions, the mean size of a transaction block in 2008 would have been 695 MB. Next, the distribution of transactions will not be even. The distribution of transactions in the Visa network follows a Pareto distribution. As a result, we can calculate that it will be necessary for nodes to be able to handle blocks of up to 11 GB in size. A node would have to handle the most significant possible block size that comes in any particular period of time. It is in the node’s interest to do so, because the larger blocks will carry more fees. The node that collects the block with the most fees earns the largest profit. The hierarchical distribution of nodes was the design of Bitcoin when I created it. The hierarchical structure, which I demonstrated, remains the formation even now.
In 2008, when I explained that Bitcoin could scale, I specifically said:
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.
If Bitcoin were designed to remain small and not scale, there would be no need for a binary tree or Merkle tree structure. Such a structure makes Bitcoin less efficient. The model presented in section 4 of the white paper, of ordering transactions without a Merkle tree, is more secure and takes less processing and hence is more efficient where the block size is less than 32 MB. Consequently, the claims that Bitcoin was not designed to scale are easy to discredit. I always said that Bitcoin was designed to scale, and I always said it would end in server farms (or data centres).
Fortunately, none of the proposed “privacy” solutions such as through BIP 324 will work. The only manner of creating consensus in Bitcoin lies in the creation of blocks. Any significantly sized node will lose significant invested sums if the operators of the node attempt to hide their connectivity. To do so would limit the ability for them to disseminate blocks and hence to earn money. Here, proof-of-work acts to consolidate and deanonymise nodes. Nodes are not designed to be private in Bitcoin; only users are. Importantly, privacy is not the same as anonymity.