Please note, this is a STATIC archive of website bitcoinsv.io from October 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.
Bitcoin SV Genesis hard fork specification
by Aleksander Gora
December 20, 2019 (4min read)
The Bitcoin SV Node team has just published the complete specification for the Genesis hard fork upgrade (scheduled to activate on February 4, 2020).  The specification is...

The Bitcoin SV Node team has just published the complete specification for the Genesis hard fork upgrade (scheduled to activate on February 4, 2020).  The specification is available here.

We have previously announced the implementation plan before the February 4 hard fork, and what steps should be taken now to prepare by anyone running an instance of the BSV Node.  We encourage all users of the Bitcoin SV Node software to begin testing their own applications using the Bitcoin SV Node beta software, and to further participate in the testing of the Bitcoin SV Node itself.  This applies to operators of mining nodes, in addition to “blockchain listeners” – wallets, exchanges, applications and others running instances of the Bitcoin SV Node software that do not write transactions to the blockchain.    Read our prior announcement for more information and the timeline of events through February 4, 2020.

Highlighted Changes

Consensus Changes

Change the default hard limit on the block size to infinite

This limit will still exist as a configuration option for miners however the default will be changed to no limit at all.  After Genesis it will be a miners responsibility to manage this limit if they choose to impose it at all.

Restore the functionality of OP_RETURN

This change will restore the function of OP_RETURN to its original design, enabling Script developers to terminate Scripts early and easily, with the possibility of the result of executing the script being valid.

Change the script numeric type from 32 bit numbers to big numbers

This change will dramatically increase the mathematical capabilities of the Bitcoin Script language. 32-bit numbers are very limited in size which makes it very complicated and inefficient to do complex mathematical operations such as signature verification. This change will restore the original design, enhancing the efficiency of complex mathematical operations and enable complex Scripts that provide all kinds of advanced functionality.

Sunset P2SH for new transactions

Pay-to-script-hash (or P2SH) is a mechanism introduced to Bitcoin to enable hiding of output scripts at the time they are created.  This is counter to philosophy of Bitcoin as an honest record of events.  Additionally, P2SH use has encouraged wide use of poor privacy practices and divergence from the peer 2 peer workflow practices that are integral to the scaling proposition of Bitcoin. Existing P2SH coins will be unaffected so there is no need to sweep old wallets.  This change simply prevents any new P2SH outputs from being made.

Restore Satoshi style handling of nLockTime & nSequence

These two data fields are integral to the mechanism of payment channels that Satoshi describes as a fundamental mechanism for allowing high speed micropayments on Bitcoin.  They have been since repurposed by BTC Core developers for two new op codes.  Along with removing those op codes the original usage of nLockTime and nSequence are being restored.

Other Required Change

P2P Relay non-standard transactions

This change will enable the use of complex transactions by all participants of the network. Prior to Genesis, only transactions that were of a standard type, such as payment transactions or plain data transactions, would be distributed across the peer-to-peer network and therefore reach a miner. This meant that if a participant needed to use complex transactions, they would have to find a miner and reach an agreement to confirm the transactions in a block. After Genesis, all transaction types will be relayed across the peer-to-peer network, enabling anyone to use complex transaction types.

Additional Consensus Changes

  • Genesis Upgrade block height activation mechanism
  • UTXO age dependent rules
  • Formal Script Grammar
  • scriptSig can only contain OP_PUSHDATA operations
  • Sunset OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY for new transactions
  • Add a policy limit on max_script_memory_usage with a default of 100MB
  • Add a consensus limit on max_script_memory_usage with a default of infinite
  • Remove the consensus limit on the number of signature operations per MB of block space
  • Remove the consensus limit on the maximum number of signature operations per transaction
  • Remove the consensus limit on the number of op codes per script
  • Remove the consensus limit on the maximum script element size
  • Remove the consensus limit on the maximum number of elements in a script
  • Remove the consensus limit on the maximum number of public keys per multisig
  • Increase the consensus limit on the maximum transaction size to 1GB.
  • Support the original sighash algorithm for transaction spending pre-Genesis UTXOs

Other Required Changes

  • Parallel Block Validation
  • Separate processing of non-standard transactions in low priority queue
  • Set script evaluation timeout policies for standard and non-standard transactions
  • Tx should be included in inv messages in the order in which they are validated
  • Discourage accidental use of P2SH by not relaying or mining transactions containing outputs using P2SH script pattern
Specifications