The Bitcoin SV community has been eagerly waiting some development in its ecosystem, and it did not take long for developers to provide them with the Bitcoin SV Quasar Upgrade. It was released on July 24 as part of its forking protocol upgrade.
The upgrade mainly focuses on scaling and it also separated the default hard cap from the consensus hard cap and that was used to dilute the power of the default setting since it can be set only by a single user; here, the Bitcoin SV team.
Hard Cap as defined by the Bitcoin SV team is the maximum-sized block that a miner will accept as valid. However, the team wishes to eliminate it in the coming February update. On the other hand, the soft cap is a ‘miner-specific setting that indicates the maximum-sized block a specific node will try to mine.’
The update removed the default block size hard cap that the team had previously considered raising to 512 MB, before raising it to 2GB, after consultations with miners and the Bitcoin SV project owner. The miners have to set their hard cap to 512 MB, and a much lower value for their soft cap. As for other people and businesses, they must set their default hard cap at 2 GB.
14 BTC & 30,000 Free Spins for every player, only in mBitcasino’s Crypto Spring Journey! Play Now!
Bitcoin SV has proposed another significant upgrade on February 4, 2020 to include a set of protocol restoration changes, in an effort to make a return to the original protocol, calling it ‘Genesis’. The upgrade will also focus on scaling and eliminate all block size caps to let miners manage without intervention from developers. The proposed changes for the upgrade include,
- Sun-setting of P2SH
- Replacing 32 math op codes with BigNumber versions
- Sun-setting OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY
- Restoration of original OP_RETURN functionality (with a fix for the OP_1 OP_RETURN vulnerability)
- Limited support for the original sighash algorithm to ensure any legacy transaction that have been kept offline become valid on BSV again
- Removing all extraneous limits on script sizes, transaction sizes etc