Bitcoin SV was upgraded to 1.0.10: What does this mean?

Getting your Trinity Audio player ready...

The Bitcoin SV network recently had a release patch that brought about some changes that have significant repercussions for businesses.

The laundry list of the upgrades are as follows: (Excerpted from BitcoinSV.io)

• Parallel Transaction Validation (PTV) scheduler improvements
• Modification to processing of User Agent strings
• Update default maxscriptsizepolicy, maxscriptnumlengthpolicy
• P2P Header Update – 4GB

1. 1. Versioning
   2. Change Description

• sendrawtransactions – option to skip some policy checks – long ancestor chains
• New ZMQ Topics, paying attention to transaction lifecycles

1. 1. Original rawtx, hashtx, rawblock, hashblock topicstx notifications:
   2. New rawtx2, hashtx2, rawblock2, hashblock2 topicstx notifications:

• Configurable Timeouts

This update has some significant impact on the applications built on BSV and was likely in response to some complaints heard from the community.

We will be going over each, in turn, to further explain their significance to the businesses operating on BSV.

1. P2P Header Update

This bullet point, while making some sense to technical people, will hold little meaning to anyone else, but this change will allow for the inclusion of blocks larger than 4GB in size. As blocks as large as 2GB¹ have already been seen on the BSV blockchain, this change is essential in keeping with the model that the protocol should not be the limiting factor on Bitcoin’s utility, but instead, the free market will determine what the practical limits are. This removes the final block size limitation and BSV can theoretically accept blocks as large as bandwidth and economics will allow, making it the only truly globally scalable protocol, bound only by the practical limits of internet infrastructure and bandwidth.

2. Update default maxscriptsizepolicy, maxscriptnumlengthpolicy

This change directly responds to the community requests to have this default transaction acceptance policy changed.

Even though every miner can change this on their own, the practical issue has always been that miners are generally wary of changing settings that may have an adverse effect on their blocks being accepted by others. These two particular settings govern characteristics of a transaction that make them eligible to be accepted into the mempool or not, and do not affect the acceptability of a block. Still, it is nevertheless something that miners are wary of changing without proper testing. This default change allowing for larger script sizes will hopefully encourage the development of more complex smart contract applications such as those seen on the Metanet protocol on Bitcoin.

3. sendrawtransactions – option to skip some policy checks

This change is likely the most exciting for gaming applications like FYX and others that require long unconfirmed transaction chains.

The benign title belies the powerful features that it enables. Among the policies it allows to be overridden are the ones that govern ‘ancestor limits’ and ‘dust limits.’ Let’s address the ‘ancestor’ one first. I suppose it is better to explain the term first. When a single coin (UTXO), called c1 is spent, a new coin is created, containing up to but not more than the original c1 coin in Bitcoins. This new coin, call it c2, is called the ‘child’, and the original coin is the ancestor. This new child coin can then be subsequently spent before the previous c1->c2 transaction has been confirmed in a block, creating a new child coin, c3. In this fashion, multiple dependent transactions can be created, each turning the latest child coin into an ancestor of the new latest child coin. This is called an ‘ancestor’ chain. This is important because it is the use of creating thousands of transactions that are chained together. There is normally a default limit to the chain’s length before a node stops accepting a new child-coin-creating transaction.

The reason why there is a limit is to protect the node. As you can imagine, if any of the previous transactions in the chain are invalid, then the whole chain of txns after the invalid one will also be invalid and must be evicted from the mempool². By default, this is set to 24 ancestors deep and has been a great limiting factor to many applications in gaming that require bets or actions in a game to be recorded in a transaction at a high rate, funded by a single original funding coin. (The initially confirmed root ancestor of the whole chain). Some applications require up to 1,000 transactions to be created within the span of 10 minutes (before even one block confirmation). So imagine how this limit has a detrimental effect on their ability to write transactions to the blockchain. With this limit removed, applications can be free (with the help of a miner who is willing to bypass this limit with this new feature) to send transactions as fast as their applications can create them.

The second now over-ridable limit, which is significant, is the dust limit, which has historically made it impossible to create transactions created coins of only one satoshi or less. This is important as some token applications (like STAS) which use one satoshi (the smallest denomination of Bitcoin) would be most efficient if they didn’t need to include the previous default limit of the smallest amount of Bitcoin that can be sent into a coin, which lies somewhere between 137 – 500 sats depending how you count³. Overriding this policy limit has been a hairy task in the past because it wasn’t explicitly easy to do without hacking your BSV mining node to some extent. A task that most miners are not willing to do given the risks involved.

This new policy will allow applications which have use to create coins with 1sat or even 0sats to do so, the benefits or drawbacks of which have been debated⁴ among those that have time to debate.

Regardless of whether or not you think it is a good idea or not, Bitcoin doesn’t care. Bitcoin, as I always say, is neutral. It is not political, and it doesn’t impose any limits on its use. It is up to you, your use case, and your conscience to do what you think is valuable and profitable.

The rest of the update contains some improvements to help customized non-mining node services to get up-to-date updates on transactions that they care about via ZMQ, which will be great news to many.

All in all, it is a well worthwhile update and one that is jam-packed with much-requested features—ahem… unlocking of limitations—which will be of great interest to businesses and applications building on the blockchain. This won’t be the final update, though. The last and final big restoration of the protocol will be the much-awaited reversion to the original Difficulty Adjustment Algorithm (DAA) used by Bitcoin from the ’emergency temporary’ one that was put in place to protect BSV/BCH after its split away from the hostile miners of BTC.

Admittedly this is not an update that will interest business applications much and affect mining and transaction processors⁵. Still, it will signal the finalization of the restoration process of BSV back to the original Bitcoin that Satoshi intended it to be. So, stay tuned.

/ Jerry Chan

***

NOTES:

[1] Which works out to be about 15,000 tx/s

[2] The pool of txns queued up to be mined in the next block

[3] Seriously, so confusing that even having read the code myself, I can never remember how this is calculated.

[4] A great summary of this debate can be found here by Angus Adams

[5] And we didn’t even go into the MAPI changes, which now allow for Doubt Spend transaction detection and alerts, adding levels of security to the network unparalleled in Bitcoin, making most of BTC/LN irrelevant. But that will have to wait for the next article.