Genesis upgrade

Genesis is a major update to the BitcoinSV mining client which is used by the majority of miners on the BitcoinSV network.

The upgrade is seen as a return to the original Bitcoin protocol, and includes the removal of all limit based consensus rules, and their replacement with miner configurable settings that give node operators the autonomy needed to set their own limits as they determine are practical.

The full specification is available here.

A short summary of the specification is given here.

Genesis is scheduled to go into effect on or around the 4th of February 2019.

Block Consensus Rules

These consensus rules apply to blocks that are produced after Genesis activation.

Block Size - The consensus rule that restricts the maximum size of a block to a specific number of bytes has been converted into a configurable consensus rule. The size of a block is the size in bytes of the serialized form of the block including the block header and all of the transactions confirmed by the block. MINERS ARE EXPECTED TO REACH CONSENSUS ON THIS VALUE AND CONFIGURE IT MANUALLY.

Number of CheckSig Operations per MB of Block Space - The consensus rule that limits the number of checksig operations per megabyte of block space has been removed.

Transaction Consensus Rules

These consensus rules apply to transactions that are confirmed in blocks after Genesis activation.

Maximum Transaction Size - The size of a transaction is the size in bytes of the serialized form of the transaction. The maximum size of a transaction is 1GB (1,000,000,000 bytes). This limitation is expected to be lifted in the future.

Maximum Number of CheckSig Operations per Transaction - The consensus rule that limits the number of checksig operations per transaction has been removed.

nLockTime and nSequence - After Genesis activation, the functionality of the nLockTime field of a transaction and the nSequence fields of transaction inputs revert to their original purpose. The rules defined here only apply to transactions that are confirmed after Genesis activation.

Script Language Rules

This section contains changes to the Script Language Rules. Bitcoin Script is the programming language that is used to lock and unlock transaction outputs. More can be found at: Advanced Bitcoin Scripting. The rules defined here apply to locking and unlocking scripts for transaction outputs that are created after the Genesis activation. The previous rules apply to transaction outputs created prior to Genesis activation.

OP_RETURN Functionality

The functionality of the OP_RETURN operation is being restored. OP_RETURN will cause termination of the script and the validity of the script is determined by the value of the top item on the stack. See OP_RETURN.

Formal Grammar for Bitcoin Script

A formal grammar has been defined for Bitcoin Script. There are the following features of this formal grammar.

The complete script consists of two sections, the unlocking script and the locking script. The locking script is included in the transaction output that is being spent, the unlocking script is included in the transaction input that is spending the output.

The unlocking script can only contain constants. The requirement is part of Validity of Script Consensus Rule, defined later.

A branching operator (OP_IF or OP_NOTIF) must have a matching OP_ENDIF.

An OP_ELSE can only be included between a branching operator and OP_ENDIF pair.

OP_RETURN may appear at any location in a valid script. The functionality of OP_RETURN has been restored and is defined later in the section OP_RETURN functionality. Grammatically, any bytes after an OP_RETURN that is not in a branch block are not evaluated and there are no grammatical requirements for those bytes.

Note that disabled operations are included in this grammar. A disabled operation is grammatically correct but will produce a failure if executed.

Validity of Script Consensus Rule - The locking and unlocking scripts for every input of a transaction must be grammatically valid, as defined by the formal grammar above.

PUSHDATA Only in Unlocking Script Consensus Rule - After Genesis activation, the unlocking scripts used in transaction inputs may only contain PUSHDATA operations, as defined by the formal grammar.

In contrast to all the other updates in this section, this consensus rule is activated for all inputs of transactions that are, or will be, confirmed in a block after Genesis activation, regardless of the height of the UTXO being spent. This rule is a subset of the Validity of Script Consensus Rule defined above but is included separately because the activation conditions are different.

Sunsetting

P2SH, OP_CHECKLOCKTIMEVERIFY, and OP_CHECKSEQUENCEVERIFY - The P2SH capability is being removed by the Genesis upgrade and the presence of a p2sh script template in an output will invalidate a transction. The opocde operations revert to NOPs, which have no effect.

Disabling Operations Consensus Rule - OP_2MUL, OP_2DIV, OP_VERIF, OP_VERNOTIF . If they are present in un-executed script, the script execution may succeed.

Consensus Rule Replacement

Functionality provided by these consensus rules is now covered by the Stack Memory Usage Consensus Rule.

Consensus Rule	Description
Script Element Size	Limits the maximum size of a script element.
Stack Size	Limits the combined number of elements that can be placed on the stack and the altstack.
Script Size*	The maximum size of the script
Number of Non-Push Operations per Script	Limits the number of non-push operations per script. Other capabilities manage the cost of execution.

functionality also covered by the Maximum Transaction Size Consensus Rule.

Consensus Rule Changes

Consensus Rule	Description
Numeric Value Size	For a byte sequence to represent validly 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.
Number of Public Keys per Multisig Consensus Rule	Limits the number of public keys per multisig has been changed to be 2^31-1 (INT32_MAX).
Stack Memory Usage	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 memory used by the altstack.

Standard Local Policies

Policies are settings that are configured by software operators. These settings are generally required by software implementations.

Policies control which transactions the software will propagate across the P2P network or include in a block. However, policies are not Bitcoin Rules or Consensus Rules and are not used to determine the validity of blocks or the transactions confirmed by the block.

Standard Local Transaction Policies

Maximum Acceptable Transaction Size Policy
Transaction Evaluation Timeout

Standard Local Script Language Policies

Numeric Value Length
Stack Memory Usage

Standard Local P2P Network Policies

Propagation of non-Standard Transactions

Page Contents

Navigation

Tools