Bitcoin Was Never Designed To Be Censorship-Resistant

Date: 2020-12-06

Source: https://craigwright.net/blog/bitcoin-blockchain-tech/bitcoin-was-never-designed-to-be-censorship-resistant

---

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](https://www.eff.org/deeplinks/2011/01/Bitcoin-step-toward-censorship-resistant). 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](https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52),

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](https://bitcoinmagazine.com/articles/bip-324-a-message-transport-protocol-that-could-protect-Bitcoin-peers). 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](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3440802):

• *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](https://arxiv.org/pdf/1605.07524v2.pdf) 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](https://s3.amazonaws.com/nakamotoinstitute/code/Bitcoin-0.1.3.rar) 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](https://bitcoinmagazine.com/articles/bip-324-a-message-transport-protocol-that-could-protect-Bitcoin-peers), 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](https://www.mail-archive.com/cryptography@metzdowd.com/msg09964.html).

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](https://www.mail-archive.com/cryptography@metzdowd.com/msg09964.html):

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

---

← Back to archive