Bitcoin rules vs. Consensus rules

Getting your Trinity Audio player ready...

In a recent YouTube interview between Ryan X. Charles and nChain CTO Steve Shadders, specific details around the upcoming Genesis protocol upgrade of the Bitcoin SV (BSV) network in February were discussed. A topic of the interview was around the differences between the Bitcoin rules and consensus rules. This article serves to clarify those and provide some perspective on how the Bitcoin SV network will be maintained moving forward.

What are Bitcoin rules?

Bitcoin rules are defined as a ruleset that all nodes must adhere to without exception. An example of this is the inflation schedule (50 -> 25 -> 12.5 -> 6.25…) and when coins can be minted (only when a block is found, the coinbase transaction).

What are Consensus rules?

Consensus rules are defined as what nodes must agree to what is valid at a given point in time. For example, in the Quasar upgrade, the default block size was 2GB. Nodes can change this at will and it appears that miners have mostly set a 512MB cap since we have not seen a block mined greater than that.

What is the difference?

Shadders explains this @4:19 as Bitcoin rules being immutable (cannot be changed) and Consensus rules being mutable. I would add that going forward Consensus rules will be guided by market forces as opposed to being set in stone.

The Genesis upgrade’s true purpose is to remove the central planning from the protocol developers and enable the miners to take control of the network, manage their own settings based on market forces and allow them to scale indefinitely.

By removing all the limits imposed by Bitcoin Core and optimizing the software, the Bitcoin SV node team have given the miners a good jumping off point to start owning this network.

Relationship between miners and protocol developers

In the past the default settings have dictated how the miners manage the node. Defaults would not be changed since there was no incentive to do so. The block reward was largely fixed; fees are relatively low and a miner’s profit margin mostly correlates with their relative hashrate. As the block reward diminishes, transaction fees must be the replacement for the lost miner revenue in order to steady an incentive to mine. Thus, miners must be able to process massive amounts of transactions in order to be able to reap the fees moving forward, which means the node software must be able to scale.

In BTC, BCH and mostly in BSV up to this point, miners have taken an economic plan and allowed protocol developers who they do not employ instruct them on how to run their business. This is absurd.

Only in the last year have we seen BSV miners take more control of the network, mostly because the protocol developers have become more loose with their definitions of the rulesets.

In the Quasar upgrade, the software was unlikely able to handle 2GB blocks. Even if a miner attempted to mine a block this large, it would have been rejected by the other nodes as they may have set their cap lower. A miner does not want to run the risk of jumping out ahead and potentially lose money, so they cooperate with other miners to agree on a setting.

The difference here is key; miners worked together to establish this 512 MB cap vs. being told what to set it to. This is a function of supply and demand for transactions, as well as what is known as coopetition.

OP_Codes must be immutable

By making op_codes mutable and disabling some because they are ‘too hard’ to fix, many potential use cases have been limited. A dramatic consequence of disagreements around op_codes was even a factor in the split of Bitcoin Cash from Bitcoin SV.

Locking down the programming language of Bitcoin is extremely important because of its consistency with respect to spendable and unspendable coins. If codes are arbitrarily disabled, the old coins can be rendered useless. Also, by adding complexity in how these are evaluated, coins can potentially be stolen – which is exactly what Core have done by adding P2SH and Segwit.

Establishing a protocol spec

Shadders points out @13:12 that in the past, the Bitcoin spec was how the Bitcoin Core reference client operated. As an experienced software developer this concept is ludicrous as it implies that documentation is code, so only those that can read the code can understand what it does!

This has the insidious side effect of placing the Core developers in a constant position of power, as they are the only ones who truly understand the complex modifications they have added. It is natural that a Bitcoin spec was never published as it would take some power away from these developers, and route that power back to the users and miners.

By making the Consensus rules more transparent in the Genesis spec (and via Miner ID which will be touched on later) establishing a Bitcoin spec is more feasible. A locked down protocol is easy to document because it does not change.

Conflation of implementation detail and the protocol

The Mempool is widely known as a node’s unconfirmed transactions stored in memory. This is not a requirement as nodes could store these anywhere (on disk, even paper!). Shadders discusses @20:20 why this naming should be changed to something like the ‘unconfirmed transaction set’. This set can be implemented in any way a miner chooses as it is not part of the Bitcoin protocol. A miner will not fork the chain because they found a better means of optimizing the node software.

The negative implication in this way of thinking is that it creates a false restriction; a perception of how something customizable must be done. By removing the conflation of these concepts more freedom is established for miners to take control.

A new Consensus rule

A new consensus rule has been implemented named ‘Maximum script memory usage’ as a consequence of unrestricting the scripting language. This configuration allows miners to manage the max amount of memory consumed for a single script. This setting will be uncapped initially forcing miners to own their node. If miners do not set this, then their node will crash when inevitably someone writes an extremely complex script.

Miners can cooperate on this value leveraging the new Miner ID API (which is now in beta testing) enabling them to query other nodes’ settings in order to collaborate on managing the network such that they do not fork off yet still compete at the same time.

This rule should help push this value higher, as the ability to process more complex scripts results in higher potential revenue as fees and creating a stronger incentive to optimize script processing in the node.

Deprecation of P2SH

@25:21 Shadders talks about how this is a controversial change because it is the primary mechanism for multi-signature transactions. The only reason this is controversial in the first place is because the Bitcoin Core developers disabled script such that multi-signature transactions were infeasible, creating an incentive to use P2SH as that mechanism. This is yet another example of unintended consequences of central planning.

To highlight the controversy and immaturity of the space, custodial wallet service BitGo claimed that implementing this change to their wallet for BSV would cost $3 million.

My above Twetch should highlight how asinine this claim is. nChain even offered to do the development for BitGo, for which they increased their price to $15 million.

Somehow nChain should pay Bitgo $15 million to do their development for them.

The deprecation of the hack that is P2SH is a necessary step forward to maturing the space and routing out these childish market participants.

Finally, the ancestor limit

@33:30 the controversial ancestor limit which prevent users from creating 26 or more chained transactions before they are mined in a block. Shadders provides an update that the limit could be raised to 50 ‘in a few days’, and potentially 100 before Genesis. The long-term plan is to uncap this entirely, but nonetheless is great news.

Shadders emphasizes that if Merchant API is leveraged to broadcast transactions directly to miners, then this limit can potentially be raised much higher. This creates further incentives to use the Bitcoin network as designed, where nodes are miners manifesting a strong, robust small-world network.