In my last newsletter, I revisited something I wrote in 2021.
At the time, I described Bitcoin as a new set of rules and a system that was almost impossible to corrupt. Five years later, the controversy surrounding Bitcoin Core 30 has forced me to look more carefully at what those rules can – and cannot – protect.
I explained that Core 30 troubles me for two main reasons.
The first concerns arbitrary data and the possibility that material many people would regard as illegal or morally abhorrent can become part of a blockchain whose history is designed to persist.
The second is less dramatic, but perhaps just as important.
It concerns the cost of decentralisation.
To understand why, I need to return to my own experience of running a Bitcoin node.
What it actually takes to run a node
When I first became interested in accepting Bitcoin payments in my business, I discovered that doing so independently meant learning to run my own Bitcoin infrastructure.
My background was dentistry, not software development, so this became a steep learning curve.
I began with a Bitcoin node in the cloud and eventually moved on to my own hardware. Later I added Lightning channels and connected the system to BTCPay Server so that I could accept small payments through my website.
One of the things that surprised me most was how long it could take to establish a node from scratch.
A new node performing its initial block download has to obtain Bitcoin’s blockchain history and independently verify it. Today that historical download is already measured in hundreds of gigabytes. Bitcoin.org currently describes an initial download of roughly 740 GB, and notes that it can take a considerable amount of time while using significant network and CPU resources.
When I built and filmed nodes with Darren, this wasn’t theoretical. We experienced it.
And it made me wonder:
If establishing an independently verifying node already requires this much data after less than twenty years, what will the experience look like in fifty years? Or one hundred?
Why nodes matter
This matters because a node is not simply another computer connected to Bitcoin.
A fully validating node checks the blocks and transactions it receives against the consensus rules it has chosen to enforce.
That is what gave me the insight I explored in my recent newsletter – Who Actually Governs Bitcoin?
Running my node gives me the power to refuse rules I don’t accept. It doesn’t give me the power to make everybody else accept mine.
But that statement hides an assumption.
I have to be able to run the node in the first place.
If independent verification becomes prohibitively expensive, technically demanding or time-consuming, then the right to verify may still exist in theory while becoming less accessible in practice.
And that raises a question that extends far beyond Bitcoin:
What is a right worth if fewer and fewer people can realistically exercise it?
What Core 30 actually changed
This is where I want to be careful, because the technical distinction matters.
Bitcoin Core 30 did not increase Bitcoin’s overall block-weight limit. It did not simply make Bitcoin blocks larger than the consensus rules previously allowed.
It changed Bitcoin Core’s default policy for relaying and mining certain data-carrying transactions.
The default data carrier size was increased to 100,000 bytes, effectively removing the previous 83-byte default limit within the other transaction-size constraints, and multiple OP_RETURN outputs became permitted for relay and mining. Node operators can still configure the previous limit themselves.
Bitcoin Core contributors have argued that restrictive relay policies do not necessarily prevent arbitrary data from reaching the blockchain. People can use other methods to embed it, sometimes in forms that are harder for nodes to identify or prune from the UTXO set. Their stated position is that relay policy should reflect transactions miners have an incentive to mine rather than attempt to impose a form of content control that users can circumvent.
I can understand the technical logic of that position.
But it doesn’t completely answer my concern.
Blockspace is not free
Bitcoin’s capacity is deliberately constrained.
That scarcity is part of the system. Users compete through fees for the limited block space available.
So the question isn’t simply whether arbitrary data can technically be included.
It is also what we want a monetary network’s scarce blockspace to be used for.
If people pay sufficient fees to place non-monetary data into valid Bitcoin transactions, miners may have an economic incentive to include those transactions.
From a market perspective, that’s the system working.
But every byte included in a confirmed block becomes part of Bitcoin’s historical record.
Future full nodes that obtain and verify that history still have to process those blocks.
That doesn’t mean Core 30 automatically causes the blockchain to grow faster. Blocks remain subject to the same consensus limits, and demand for blockspace varies.
But it does mean that the argument over arbitrary data is also an argument about how Bitcoin’s finite capacity is used – and about who bears the long-term cost of that use.
Does technology solve the problem?
An obvious response to the storage problem is pruning.
Bitcoin Core allows a node to verify the blockchain and then discard older raw block data once it has been validated. In that important sense, a pruned node remains a fully validating node.
But this distinction can also obscure the practical problem I am concerned about.
A pruned node no longer possesses the complete historical blockchain. Once old block data is discarded, it can no longer independently provide all the historical information an archival node can. Pruning is also incompatible with Bitcoin Core’s full transaction index.
This became particularly relevant when I wanted my node to do something useful beyond simply validating Bitcoin’s current state.
To connect wallets and services to my own infrastructure, I used Electrs, which creates an index that lets me efficiently query transactions associated with addresses. The standard Electrs implementation requires pruning to be disabled because it needs access to the historical blockchain to construct and maintain that index.
So there is an important distinction between saying:
“An ordinary person can still validate Bitcoin with relatively modest storage.”
and:
“An ordinary person can maintain an independent, fully indexed historical copy of Bitcoin and use it to provide the services they expect from their own Bitcoin infrastructure.”
Those aren’t quite the same proposition.
And this is where my concern about blockchain growth becomes more significant.
If we want ordinary participants not merely to trust that Bitcoin’s rules are being followed, but to retain the ability to interrogate its history and operate useful independent infrastructure without relying upon somebody else’s servers, then the resource requirements of an archival node matter.
The blockchain’s history is part of the decentralisation equation.
Every additional byte permanently incorporated into that history must ultimately be stored somewhere by the participants who choose to preserve the complete record.
Pruning redistributes that burden. It doesn’t make the historical data disappear.
That doesn’t make pruning a bad solution. It is an important engineering trade-off that lets people with limited storage keep enforcing Bitcoin’s consensus rules independently.
But trade-off is the important word.
Validation is not the same as self-sufficiency.
If I discard historical information and later need to rely on somebody else’s infrastructure to retrieve or index it, I have reintroduced a dependency.
That leads me to a more practical test of decentralisation:
How much infrastructure does an ordinary person actually need to operate before they can participate independently in the Bitcoin economy they are being promised?
Computers improve. Storage becomes cheaper. Internet connections become faster. Software becomes more efficient. Those developments may offset some of the growing burden.
But if the resource requirements of useful, independently operated Bitcoin infrastructure grow faster than those improvements, fewer ordinary people may be willing or able to maintain it.
I don’t know which path Bitcoin will take over the next century.
Dismissing the question because hard drives are getting bigger would be a mistake.
Decentralisation is not a switch
I used to think of decentralisation almost as a binary property.
A system was centralised or decentralised.
I no longer think that is a useful way to understand it.
Decentralisation exists in degrees and across different dimensions.
Bitcoin can have decentralised consensus rules while software development is concentrated among a relatively small number of technically sophisticated people.
It can have thousands of independently operated nodes while mining power is concentrated among a smaller number of large pools.
It can let anyone run a node, while the knowledge, hardware, bandwidth, and patience required discourage most people from ever trying.
None of those observations proves that Bitcoin is centralised.
They tell us that decentralisation must be examined in practice, not merely asserted from the design.
And that changes the question.
Instead of asking, ‘Is Bitcoin decentralised?’ perhaps we should
ask:
Where is power concentrated, what constrains it, and how easy is it for an ordinary participant to exercise an independent choice?
Rights on paper and power in practice
This problem predates Bitcoin.
A legal system can declare that everybody is equal before the law while access to skilled legal representation remains expensive.
A democracy can give every adult one vote while some participants have vastly greater resources to influence the political conversation.
A market can be formally open to everybody while information, capital and connections remain unevenly distributed.
The formal rule may distribute power equally.
The practical reality may not.
This doesn’t make the rule meaningless. Equal legal rights, votes and open markets can still be enormously important.
But it reminds us that we cannot understand a system simply by reading its rules.
We also have to observe what people can realistically do within them.
Bitcoin presents us with the same challenge.
The protocol may give me the right to verify the rules independently.
But preserving decentralisation requires that exercising that right remains practical enough for a meaningful number of independent people to keep doing it.
The question Core 30 has left me with
This is why my concern about Core 30 isn’t about an 83-byte setting becoming 100,000 bytes.
The deeper issue is what Bitcoin is optimising for.
Should its policies make it as neutral as technically possible about how people purchase blockspace?
Should they discourage uses that some participants believe impose unnecessary long-term costs on the network?
Who gets to decide what counts as unnecessary?
And if nobody has the authority to decide for everybody else, how does the system preserve the conditions that make decentralisation possible in the first place?
I don’t yet have satisfactory answers.
But I have become increasingly convinced of one thing:
Decentralisation isn’t protected simply because a protocol says everybody is free to participate.
It is protected when enough independent people remain practically capable of exercising that freedom.
That is a much harder standard.
And once again, it brings me back to the broader question that has started to emerge from this series.
Human beings are very good at writing rights, rules and principles.
The more difficult task is building systems in which those principles continue to operate in the real world.
Perhaps that is where we need to go next
Until next time, enthusiasts!
Victoria
The Eve of a Bitcoin Soft Fork
To address the challenges of excess data on Bitcoin, BIP 110 initiated a ‘Soft Fork’ that eventually failed. Here, we discuss the issues the night before and reflect on the ColdCard hack.
Be First to Comment