The Bitcoin SV Node team has released version 1.0.0 of the Bitcoin SV Node implementation. This version implements the updates required to support the Genesis hard fork upgrade which is scheduled to activate on February 4, 2020. The specification for the updates to the Bitcoin and Consensus rules is available here.
It is important to note that all installations of Bitcoin SV Node implementation must be upgraded to this release by February 4, 2020. Prior versions of the Bitcoin SV node software are incompatible with the updated rules and will fail after February 4.
Mandatory consensus parameters must be configured by the system administrator. The software will terminate immediately if these parameters are not configured. More information about the mandatory consensus parameters is available on the bitcoinsv.io website.
The hard limit on the block size is a configuration parameter that specifies the maximum size that a block can be in order for it to be validated by the software. Blocks that are larger than this maximum will not be retrieved by the software or validated.
Maximum Stack Memory Usage During Script Evaluation
This mandatory consensus parameter defines the maximum amount of memory that can be used on the stack by a script during evaluation. If a script attempts to use more stack memory than defined in this consensus parameter, then the evaluation of the script will be terminated and the script fails.
This change restores 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.
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.
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 the 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 prevents any new P2SH outputs from being made.
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.
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.