In our series of blogs giving you a preview of our introductory course to Bitcoin Infrastructure, Bitcoin Curriculum Specialists, Brendan Lee and Evan Freeman have given you insight into the difference between a node and a miner, the double-spending problem, Bitcoin’s first seen rule, misunderstandings about Bitcoin’s decentralisation, incentive-driven behaviours built into Bitcoin and how Bitcoin nodes benefit from the light-speed propagation of transactions.
The introduction to Bitcoin Infrastructure course is focused on providing students with a solid understanding of the role that nodes and node operators play in the construction of the network. In particular, it will focus on the incentives that drive enterprise operators to spend large sums of money to build and operate their infrastructure.
Today, Brendan gives you an overview of Bitcoin rules and their enforcement
Bitcoin consensus rules
The consensus rules are codified into the Bitcoin node client software system and represent fixed and unchangeable rules applied across the network. These rules must be strictly adhered to in order for a node using the client to actively participate in the Bitcoin network governance process.
The immutable rules are a set of rules that define the format and constraints that transactions and blocks must follow. Making any changes to these rules could cause nodes to disagree on the nature of Bitcoin. All agreements are enforced through application of proof of work by nodes in a process known as Nakamoto Consensus.
Chapter 2 of our introduction to Bitcoin Infrastructure course details the role of nodes in the network and also how nodes resolve any conflicts in agreement on the state of the Ledger. Here is a quick overview of the rules you’ll learn about by doing the course.
Block consensus rules 1
Block Size Rule
When a block is found, there is an economic limit applied to the block size imposed by nodes on the network. This allows nodes to reach consensus on behavioural limits of the network. This limit is set to a large multiple of typical demand.
The size of a block is the size in bytes of the serialised form of the block, including the block header and all of the transactions it includes.
Block Subsidy Rule
The block subsidy will drop by half at a scheduled rate of every 210,000 blocks, starting with a subsidy of 5,000,000,000 satoshis per block from the genesis block, rounding down when sub-integer fractions are encountered.
Block consensus rules 2
Proof of Work Target Adjustment Rule
The network will adjust the target for the difficulty of the Proof of Work needed for a valid block to maintain an approximate 10 minute block discovery rate.
Genesis Block Rule
Only blocks that add to the block chain formed by building upon the Genesis block are valid. The genesis block is identified using its block hash which is:
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f.
Transaction consensus rules 1
Transaction consensus rules are the rules that define how transactions are interpreted by the nodes collectively, so it is of utmost importance that consensus be reached and maintained.
Maximum Transaction Size Rule
This is an economic limit imposed by miners in consensus. The length is the number of bytes in the serialised transaction. This rule allows miners to collectively set a practical limit for users on the size of a transaction. As the capabilities of nodes and node software improve, this limit will rise, providing added utility to all network users.
Use of nLockTime and nSequence
The nSequence fields of every transaction input and the nLockTime field of the transaction collectively determine the “finality” of a transaction. If a transaction is “non-final” then it can not be valid, but it can become “final” at a later time. If a transaction is “final” then it can be included in a block.
Transaction consensus rules 2
The sum of the value of the inputs of a transaction must be greater than or equal to the sum of the values of the outputs.
When transactions are created in Bitcoin, they must spend what are known as ‘Unspent Transaction Outputs’ (UTXOs). UTXOs are the live coins available to be spent on the network. The ledger represents the cumulative transaction history of those coins from their distribution as part of the block reward. Every node has a set of UTXOs it manages, which it curates according to the operator’s chosen local policies.
Each UTXO holds a quantity of bitcoin satoshi tokens locked in a script. When the locking script is successfully executed in the script engine using an unlocking script, the satoshi tokens are released to be spent. To be successful, the full script must terminate with a single non-zero value remaining on the stack. The transaction then re-allocates the satoshis to new outputs which themselves become UTXOs, replacing their predecessors in the current UTXO set across the network.
Coinbase Maturity Rule
Nodes may not spend the outputs of a Coinbase transaction in a block that is less than 100 blocks higher than the one the Coinbase appears in.
Transaction Format Rule
Transactions must conform to the data formatting rules of the Bitcoin protocol, including respecting the sizes of certain fields and their encoding schemas.
Script language rule 1
The Bitcoin scripting language and its specification
One of the aspects of Bitcoin which gives it such a broad range of applicability and function is its scripting language. Based on Forth, the language is stack based and uses Reverse Polish Notation as the means to enter and process data. While the language appears simple, when used properly it can provide a Turing complete environment within which complex and diverse applications can be built.
The following rules are applied for all transactions.
Data Types
All data items in Bitcoin Script are a byte sequence. Some operations interpret their parameters as numeric or boolean values and require the item to fulfil the specifications of those types. Some operations produce items on the stack which are valid numeric or boolean values.
Formal Grammar for Bitcoin Script
The Formal Grammar for Bitcoin Script is set by node operators. This contains the full set of approved opcodes and their exact spelling and function.
Script language rule 2
Validity of Script Rule
The locking and unlocking scripts for every input of a transaction must be grammatically valid, as defined by the formal grammar rules above.
Bitcoin Numeric Value Size Rule
For a byte sequence to validly represent a numeric value, the length of the byte sequence must be less than or equal to 750,000 bytes. A byte sequence that is larger than this is a valid byte sequence, but is not a valid numeric value.
Bitcoin Stack Memory Usage Rule
The stack memory usage consensus rule limits the amount of memory that can be used on the stacks. This rule is evaluated against the sum of the memory used by the stack and the alt-stack.
If the execution of the unlocking and locking script for an input uses more memory than defined in this rule, then the transaction is invalid.
