Large Blocks Incite More Full Nodes Than Small Blocks (Or The Irony of 0-Conf Opposition)

You can think of the blockchain security vs. usability debate as the tension between two forces. Security is defense against potential attackers. It could be maintaining control of your private keys, keeping your transactions private from a competitor analyzing the blockchain to determine your transactions, or trying to not invoke the attention of the kleptocracy that you live in. Ultimately security is about loss prevention.

Dao: The path between yin and yang

Usability on the other hand is about taking advantage of opportunities. Ease of use ensures that transferring money between parties happens more frequently. Low fees and quick reliable transactions also ensure that time and energy can be spent on things other than insurance and security. Ultimately usability is about creating profit.

Profit and Loss. Yin and Yang. So then, what is Bitcoin’s path between the two? Bitcoin Core developers have argued that:

  1. In order to keep the network secure, it must be decentralized
  2. In order to keep it decentralized, consensus must be watched and enforced by many different economically significant parties.
  3. In order for consensus to be watched by many different economically significant parties, it must be inexpensive to run a full node.
  4. In order for it to be inexpensive to run a full node, block size must be capped.
Too secure?

Most opposition to this train of reasoning has been focused on attacking the first car, that only so much decentralization is required for security, or that only miners are actually securing the network; Full nodes are just security theater. But the weakness in this train extends to the other cars as well.

My previous articles have accepted the first car but went on to undermine the second car by demonstrating that merely being inexpensive is insufficient to compel many parties to run a node. The relative uselessness of running a full node combined with less expensive near perfect substitutes ensures that users can free ride on others to watch the network with their full nodes. But now my attention is turned to the third and fourth cars. It turns out that the weakness of this pair is in the same unwillingness to account for anything other than security/protection from loss.

Running full nodes is useless for standard users, but it is very useful for a specific type of user: Merchants. Because of the way the bitcoin protocol works, the lag time between a transaction being broadcast and it being included in a block makes it profitable for merchants to run full nodes. It enables them to accept 0-confirmation transactions by providing validation for any incoming transactions, and the ability to spot any attempts at a double spend because they can see all outstanding transactions in the mempool.

It turns out, that behind ensuring the block you mine is valid, accepting 0-confirmation transactions is one of the most useful functions of running a full node. The great irony of this is that Bitcoin Core, who’s so adamantly argued that running full nodes secures the network, and that security is paramount, has completely undermined this use case by adding in replace-by-fee to their implementation of the protocol. Regardless of the opt-in flag on the initial transaction, malicious miners and nodes now have simple access to code which simply ignores this flag and replaces these 0-conf transactions. Admittedly, this was likely inevitable, but it still harms the use case.

But let’s ignore that. Even if they hadn’t undermined the #2 use case earlier than was inevitable, for running a full node, they vastly narrowed the number of merchants who would run a full node when they made low value transactions infeasible. The unreliability of transactions being included in blocks and high fees due to the 1 MB block size limit, counter to the security focused arguments, has the effect of reducing the number of full nodes rather than increasing it. By looking only at one side of the equation, costs, they neglected creating even greater opportunity for running full nodes.

It is at this moment where it becomes clear that the emperor truly has no clothes if you’ve read the entirety of my series on full nodes.

For Bitcoin Core to have any case for prioritizing limiting block-size for the purpose of adding more full nodes, and thereby improving security, four independent counters to their arguments must be refuted.

  1. Non-mining nodes are unable to secure the network.
  2. There’s a public good’s problem running full nodes.
  3. Replace-by-fee harms the ability to validate 0-conf with a full node, and therefore eliminates the need for merchants to run them.
  4. Even without Replace-by-fee, block size limits reduce the blockchain’s reliability and makes it more expensive, and therefore removes the need to run a full node to validate 0-conf transactions for small transaction value merchants.

The standard response to this is that 0-conf transactions are not consensus secure, that first seen first included was mere convention, and that double-spends can be automated by simple scripts. Peter Todd’s famous double spend against Coinbase using scripts he wrote is the prime example of this. I actually acknowledge the weakness of 0-conf for the long term if future miners decide to re-enable replace by fee covertly. Here I depart with those on the big block side of the argument, even though for the time being 0-conf can be reasonably secure for small transactions without Nakamoto Consensus security.

I do have a solution for this however. With a protocol hardfork, by modifying the ability and incentives of miners to punish double-spenders, we can make 0-conf transactions consensus secure, even with universal replace-by-fee, can be achieved. This will be the subject of my next article.