logo

UTXO height based activation – Roadmap to Genesis part 3

Published On

26 Jul 2019

Unfuckening is a very tricky business. There is a lot that got fucked in ten long years and some things are so badly broken that they simply can’t be unbroken cleanly. The BSV blockchain team has done an enormous amount of research, studying the existing and the original code extensively and it’s been a really steep learning curve. But we are feeling pretty confident in the roadmap we need to implement now. There are some pragmatic caveats though.

Let me give you one example. Arithmetic op codes. The original BitCoin used a number implementation that allowed numbers of arbitrary size. That is, it wasn’t restricted to 32 or 64 bit numbers like many systems are. 256 bit (and larger) numbers, which are really useful for cryptographic functions, were also able to be used. Quite early in Bitcoin’s history this was changed and restricted to 32 bit numbers along with the introduction of the horrific CScriptnum class. The removal of capability to do crypto math directly in script (without huge overhead) was a great loss to Bitcoin and it’s something we will unfuck next February. But the question is how?

The solution to many problems

Our next roadmap article will describe the upcoming changes to OP_RETURN because this is a change we want the Bitcoin ecosystem to be aware of as far in advance as possible. The mechanism of that change is what this post is about and the reason we explain it separately is because it is a concept we will be reusing in many ways. I could have incorporated it into the next post but it’s a subject that will come up over and over again so it’s worth giving it’s own post…

The golden rule of Bitcoin

Converting an arithmetic system in a backward compatible way is a tricky thing to do with certainty. We can build tests until we are blue in the face but how will be sure we’ve covered every single edge case? Is it even possible to ensure all cases CAN be backward compatible? We don’t know. But we certainly care because one of the rules we live and breathe by in Bitcoin, the GOLDEN rule, is never make a spendable Bitcoin unspendable. NEVER. Not even by accident.

Thanks P2SH

If you look at the history of Bitcoin this problem may not be as big as we think it is. There are less than 100 transactions in bitcoin history that actually use arithmetic op codes – that we can see. So couldn’t we just write tests to make sure all of those are spendable? Possibly (not in all cases though) but the bigger problem is pay to script hash transactions. P2SH has the interesting property that the content of the output script does not become visible on the blockchain until the time it is spent. That is in stark contrast to the original design where the locking script had to be posted publicly in the blockchain when it’s created. This causes some difficulty in respecting the ‘never make a spendable bitcoin unspendable’ principle. Because we cannot assume what is in P2SH scripts. We HAVE to assume that some of them contain arithmetic op codes and as such to be sure we need to write tests for every single possible usage and edge case to ensure backward compatibility. Many of those edge cases will not exist, in fact likely most. But we have no way of knowing which so we have no choice but to test for them all.

As I said earlier this is hard, maybe impossible to provably do.

Sidestepping the problem

The simple way around this is a principle that is in fact useful to us for many features beyond just the specific case of arithmetic op codes. Don’t even try to be backward compatible. We simply accept that a part of Bitcoin’s history has some broken stuff in it. We continue to support it with the view that one day, eventually, all of those broken outputs will be spent. Maybe that’s decades away but in time we will be able to deprecate the old code.

But how do we fix it if we keep supporting the old rules? Simple, we implement the new rules as of a certain point in time. Everything after that follows the new rules. Everything before follows the old rules. Most Bitcoin consensus changes use what we call ‘height based activation’. That is after the blockchain reaches a certain block height the new rules kick in. But this potentially breaks old transactions that follow the old rules. That imposes a huge burden on developers of a new change that effectively locks them into a set of restrictions that would look very much like what Bitcoin Core have previously called a “soft fork”. Soft forks are for numpties and we aren’t going to buy into that because they are unnecessarily restrictive when you’re trying to undo 10 years worth of damage.

So instead of just blanket implementing the new rules we make them conditional not on the current block height, but on the block height at the time the script was created. More specifically the block height at which the input UTXO you are trying to spend was mined into a block. This a very flexible activation mechanism. It means that all outputs created with arithmetic op codes will continue to be executed using the code that existed at the time they were created. If they were valid then, they are valid for all time regardless of which rule set they were designed for. Fortunately there isn’t a lot of tooling changes required for this in the ecosystem since arithmetic op codes are rarely used. But it is not the only change we plan to activate in this way. Pay to script hash itself will be deprecated this way. Old P2SH outputs will still be able to be spent using the P2SH semantics but after the sunset date (4th Feb 2020) new ones will be invalid (strictly speaking they will actually become a hash puzzle but that’s another story). These are two examples of how we will use UTXO height based activation to ensure a smooth and fully backward compatible pathway back to Genesis.

Blogs

Our blog articles cover the latest in blockchain technology.
Solutions, trends, and news.

post-image

22 Jun 2022

Miner Advisory June 2022 – Transaction Fee Configuration

Bitcoin was designed to distribute coins to miners through the block subsidy. The subsidy halves every 210,000 blocks.

post-image

12 May 2021

On the governance of Bitcoin limits

The BSV blockchain team recently received this request on the BSV github issue tracker.

post-image

24 Dec 2020

A (belated) Christmas present from BSV blockchain team.

It’s taken us a bit longer than we hoped, but the beta version of BSV 1.0.7 (Dynastic) will be released in early January (hence the “belated” part of this article’s title). The Dynastic release is the result of almost a year of work to untangle a particularly nasty mess we inherited from Bitcoin Core. As […]

post-image

09 Oct 2020

BSV Blockchain Capacity Report

Transaction volume on the BSV blockchain approximately doubled for a few days last week – due to “multi source stamina testing”

post-image

30 Sep 2020

Realising (Finally) Satoshi’s Peer to Peer Vision for Bitcoin

When Bitcoin V0.1.0 was released in 2009, it contained a proof of concept feature that is perhaps the most overlooked in its history.

post-image

16 Sep 2020

Beyond micropayments: The rise of nano-services

The Rails release of BSV (v1.0.5) introduces several game changing features that have long been in the making. This release is code-named RAILS because its major features are aimed to open new and innovative payment cases using the BSV blockchain protocol and ledger, and empower BSV blockchain companies to build more infrastructure for payments – […]

post-image

04 Feb 2020

Genesis activation successful

At 1:28am GMT block 620,537 was mined and BSV nodes of v1.0.0 or greater began accepting transactions under the restored Genesis protocol.  At 1:55am at block height 620,539 the first block containing a Genesis-only transaction was mined, locking in the change. Old node software did not accept this block and forked off onto a legacy […]

post-image

10 Jan 2020

Genesis specification finalized

The draft Genesis specification was published in December 2019 in order to elicit feedback from BSV miners and other ecosystem participants.

post-image

23 Dec 2019

BSV blockchain – Blocking potential P2SH replay attack after Genesis hard fork

The BSV Node team notes the recent public disclosure on Reddit by Gregory Maxwell (a.k.a. /u/nullc) from the Bitcoin Core (BTC) of a potential replay attack vector on BSV.

post-image

06 Dec 2019

BSV blockchain Genesis hard fork implementation plan – in advance of February 4, 2020

On February 4, 2020, the BSV blockchain network will undergo its “Genesis” hard forking upgrade.  This hard fork represents a significant milestone in BSV’s journey to restore the original Bitcoin protocol.  To allow the BSV blockchain ecosystem adequate time to prepare for the hard fork, the BSV Node team would like to communicate the rollout […]

post-image

24 Nov 2019

On the future of Bitcoin transaction fees

Cheaper transaction fees, fiat stable pricing and a highly flexible framework for dynamic fee rate discovery are all on the horizon for BSV blockchain.

post-image

06 Aug 2019

The BSV blockchain & False Reports of a “Three-way Fork”

In recent days there have been a couple of articles which incorrectly suggest that the BSV Blockchain has suffered from a “three-way fork” over the last few weeks. These articles seem to stem from the same source, a tweet from BitMEX Research. Here are the facts.  The BSV Blockchain had a planned hard-fork upgrade on […]

post-image

13 Jul 2019

Quasar upgrade 24th July recommendations – roadmap to Genesis part 2

This upgrade has very limited scope with just changing the block size hard cap but it warrants some further explanation. It was first detailed in part one of this post series.

post-image

22 May 2019

First gigabyte+ blocks mined in STN stress test

Background On May 21st 2019 the BSV blockchain Scaling Test Network (STN) saw its maximum mined block size record broken eight times in rapid succession. In the latest release of BSV Node (0.2.0) one of the standout changes was lifting the hard cap block size limit from 128MB to 10GB. The reason for setting the […]

post-image

29 Apr 2019

BSV blockchain [BSV] Scaling Test Network is open for business

The BSV Scaling Test Network (STN) is an initiative of the BSV blockchain Node project, owned by Bitcoin Association and operated by nChain (with funding by CoinGeek) to scale and test Bitcoin beyond gigabyte and eventually to terabyte blocks. In February 2019, the BSV blockchain team publicly released client software with full support for the […]

post-image

11 Mar 2019

BSV Scaling Test Network Sustains 128MB Blocks for 36 Hours

A new milestone was achieved recently on the Bitcoin SV Scaling Test Network with continuous 128MB blocks over a period of 36 hours. The test ran from about midday on the 7th of March through to midnight on the 8th. 246 blocks were produced during this period and each one was 128MB large. The blocks […]

post-image

01 Mar 2019

Denial of Service Vulnerabilities Repaired in BSV version 0.1.1

As part of its commitment to professionalise the Bitcoin development process.

post-image

24 Jan 2019

BSV blockchain (BSV) Weekly – Jan 23, 2019

The BSV blockchain ecosystem has benefited from significant developments in the past week – with six (count them six!) new releases just from Bitcoin developer unwriter. That alone deserves a special Satoshi Shout-Out below! Along with increased scaling achievements, the BSV blockchain ecosystem continues to grow at a rapid pace. Read below for a summary of […]

post-image

24 Jan 2019

Warming Up the Scaling Test Network for BSV blockchain – 24 hours of Sustained 64 MB Blocks

The BSV blockchain network is committed to massive on-chain scaling, and nChain’s team is progressing with technical work needed to achieve this Satoshi Vision. In fact, our recent tests have demonstrated the BSV blockchain network’s capacity to handle sustained 64 MB blocks over a full 24 hour period, and we are already moving towards showing […]

post-image

16 Jan 2019

Bitcoin SV (BSV) Weekly – Jan 16, 2019

Along with scaling capacities, the Bitcoin SV ecosystem continues to grow at a rapid pace.  In our weekly post, we provide a summary of some of the past week’s developments from around the world. Today’s special “Satoshi Shout-Out” goes out to hivr; the social network built around a BSV wallet is sponsoring “one of the […]

post-image

04 Jan 2019

Bitcoin SV (BSV) Unveils Logo for Rebirth of Original Bitcoin

The bComm Association unveils an updated logo for Bitcoin SV (ticker: BSV), chosen from public voting after three Twitter polls in a new form of decentralized marketing.  The BSV logo is revealed on the 10th anniversary of the Bitcoin genesis block, to mark Bitcoin SV as rebirth of the original Bitcoin.  A modernized update of […]

post-image

21 Dec 2018

BSV blockchain (BSV) Weekly – Dec 19, 2018

BSV blockchain (BSV) is rebirth of the original Bitcoin, designed to preserve Bitcoin’s fundamental design and fulfil the Satoshi Vision .  BSV provides the enterprise-friendly blockchain – with a stable, scalable, secure, and regulation-friendly platform for businesses to confidently build upon. In just one month since it emerged, the BSV ecosystem has quickly grown.  Numerous […]

post-image

04 Dec 2018

New, Exciting BSV blockchain Projects Announced During CoinGeek Week

The highly anticipated CoinGeek Week conference has drawn to a close and to say that it was a huge success is putting it mildly.

post-image

20 Nov 2018

BSV blockchain Mines 64 MB Block on Bitcoin Cash, Largest Ever on a Public Blockchain

20 November 2018 – BSV blockchain, the new full node implementation for Bitcoin Cash (BCH) mined a 64MB block, the world’s largest ever on a public blockchain. The huge block was mined by CoinGeek Mining, during an on-going Professional Stress Test of the BCH network. Just one hour before, a 38MB block was mined, also […]

post-image

15 Nov 2018

Bitcoin Cash (BCH) Protocol Upgrade: Coin Splitting Advisory

The upcoming Bitcoin Cash (BCH) hard fork on November 15 will likely cause two branches of the blockchain to exist, at least temporarily. Some actors believe both branches will persist, effectively creating two “coins.” Other observers believe that one chain will die off with the alternate “coin” simply becoming unusable, and leaving a single “coin” […]

post-image

14 Nov 2018

Bitcoin SV Notice to Cryptocurrency Exchanges, Wallet & Service Providers: Advisory about BCH Protocol Upgrade and Coin Splitting

We recently received inquiries from several cryptocurrency exchanges about the upcoming November 15 Bitcoin Cash (BCH) protocol upgrade and the role played by Bitcoin SV. There appears to be confusion by some exchanges and other cryptocurrency service providers about Bitcoin SV, perhaps caused by misleading statements made by supporters of other competing BCH implementations (such […]

post-image

08 Nov 2018

Bitcoin Cash (Bch) November 15, 2018 Protocol Upgrade – Notice to Cryptocurrency Exchanges & Bitcoin Cash Wallet Operators

On November 15, 2018, the Bitcoin Cash (BCH) network will undergo a scheduled protocol upgrade. This protocol upgrade has been different to previous upgrades due to differences in opinion as how best to evolve the Bitcoin Cash network to continue to meet the demands of enterprises and consumers who support Bitcoin Cash. We have developed […]

post-image

23 Oct 2018

SVPool is open for business for Bitcoin miners

SVPool proudly runs BSV, the new full node implementation of Bitcoin BCH designed to fulfil the original Satoshi white paper’s vision for Bitcoin.

post-image

16 Aug 2018

BSV Full Node Implementation Launched to Fully Restore Original Bitcoin Protocol

nChain, the global leader in research and development of blockchain technologies, announces the creation of BSV, a new full node implementation of the original Bitcoin protocol now restored in the form of Bitcoin Cash (BCH).

Ready to add blockchain solutions to your business or government agency?

Send us a message and let us know about your needs. Please contact

Join Our Community

Stay updated with the BSV Blockchain Association's latest news and events.
Subscribe to our weekly newsletter.