BSV Development Update: Genesis Hardfork

'

Bitcoin Satoshi’s Vision (BSV) has a hard fork named “Genesis” scheduled for tomorrow, February 4th. 

BSV’s name advertises what the network is all about. Many developers and enthusiasts in the BSV camp were disillusioned by BTC and BCH’s development path and have wanted to restore the Bitcoin protocol to its original framework, putting emphasis on their interpretation of what Satoshi Nakamoto envisioned for the network. BSV is their attempt to do so. 

The BSV development community focuses on restoring the protocol to its more original specifications, on-chain scaling, and pure Proof of Work based consensus. The upcoming fork has a few notable changes that relate in some way to these focuses, which we’ve covered below.

No Block Size Limit

At the root of many of the battles between different camps in Bitcoin is the difference in opinion over the appropriate block-size for the Bitcoin blockchain. BTC has a block-size of 1 MB, BCH has a block size of 32 MB, and BSV has been handling 2 GB blocks. 

The obvious benefit of bigger blocks is the increase in transaction throughput. However, the bigger blocks are harder to communicate throughout the network and make it difficult for ordinary users to run a non-mining, fully validating node, which are seen by many as possible checks on miner power. This class of nodes keep full copies of a blockchain’s entire history and check transactions as well as the the blocks they’re organized in for any deviation from the agreed upon network rules. 

The BSV camp thinks these non-mining nodes don’t offer much value and actually hold back the network from reaching its potential. On the other end of the spectrum, the BTC camp thinks having non-mining nodes as part of the network is essential to its security and avoiding asymmetric power in the hands of miners. 

In the upcoming upgrade of BSV the current limit on block-size will be removed entirely. This is in line with their desire to roll back the protocol to its original design. At first Bitcoin didn’t have a block limit, but a limit was put in at the suggestion of early Bitcoin pioneer Hal Finney as a security measure for the young network. However, the limit was somewhat arbitrary and later became a very contentious issue. 

After February 4th, BSV miners will be able set a limit for themselves as a configuration option, but there will be no hard cap on the block size at the protocol level. This takes the size of blocks out of the desires of developers or users and puts the question of size to the miners. Miners will want to stuff as many revenue generating transactions into their blocks as possible but they will also want to be aware of what size block the rest of the network can handle.

OP_Return Restored

The functionality of OP_Return is being restored to its original implementation to support the storage of every type of content imaginable on BSV. 

OP_Return is a function that can be used for storing data on the Bitcoin network, but its use had been limited by subsequent changes to the BTC protocol. BTC developers thought the storing of non-financial data on Bitcoin should be deprioritized and the protocol should be optimized for financial transactions. The BSV camp disagrees vehemently and wants to store as much data on the BSV chain as possible. Many in BSV think this will open up a lot of content related use cases for their chain, as well as provide transaction fee revenue for miners. 

Sunsetting P2SH

In its infancy, Bitcoin users could only send funds to a hash of a public key. Pay-to-script-hash (or P2SH) was introduced to Bitcoin in 2012, allowing users to send funds to a hash of a Bitcoin script, which is a hash of a set of instructions instead of a public key. Bitcoin Core developers introduced P2SH to address issues such as privacy and ease of use with the previous method of constructing multi-signature transactions.  

P2SH in Bitcoin enables the hiding of output scripts at the time they are created. Output scripts are instructions that describe how the receiver of coins can spend them in the future. According to the BSV community, hiding these instructions is counter to the original design philosophy of Bitcoin, which they view as a fully transparent record of events. Hiding these instructions removes the legal enforceability of Bitcoin smart contracts, which they see as a vital part of the security model of Bitcoin SV. 

Removing P2SH might bring BSV closer to the vision of its supporters, but removing a widely used transaction type isn’t devoid of negative consequences. Services such as BitGo will discontinue their support for BSV. Their security model and business relies on P2SH based multi-signature setups. 

Conclusion

If you hold your BSV in Edge, your assets are safe before, during, and after the hard-fork. At this time, there’s no indication of an opposing group challenging these changes. We’re happy to support this growing community and look forward to the network’s continued development. 

Leave a Reply

Your email address will not be published. Required fields are marked *