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.
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.
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.
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 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.
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.