It’s been an interesting few days but the work continues…
When the Bitcoin SV project began last August we published a roadmap up to Q2 this year. It’s time we updated it. There’s only one item on our published roadmap which hasn’t yet been addressed. All the others are either complete or significantly progressed. That item is parallel block validation which was simply deprioritised in favour of other scaling enhancements that offer a bigger ROI in the short term.
In this post we want to give a high level outline of our roadmap going forward including proposing two protocol upgrade dates. It is broadly broken into the categories of scaling and protocol restoration.
Protocol Upgrades
The first upgrade, code named “Quasar”, is proposed for Jul 24th 2019 and is primarily focused on scaling. At a protocol level the only change planned for this upgrade is a lifting of the default block size hard cap. We have previously signalled an intent to raise the cap to 512MB however after consultation with the Bitcoin Association (the owner of the Bitcoin SV project) and miners representing a significant majority of hash rate it has been decided that the Bitcoin SV software will implement a default of 2GB in July. Initially a majority of miner hash rate will manually set their hard cap down to 512MB. The reasoning behind this is simple, the Bitcoin SV network hit the 128mb block cap unexpectedly early and the miners don’t want to hit the cap again after it’s raised. If the default is 2GB then miners, by consensus, are able to lift the limit without further software changes. There is of course a lot of plumbing under the hood that goes into increasing our scaling capacity. Things like parallel validation paths and cleaning up a lot of expensive to run code that was put in place to handle full blocks. In the coming weeks I will make a detailed post on this and why we believe this both a safe and necessary extension of prior plans.
Returning to Genesis
The second and more significant upgrade is proposed for Feb 4th, 2020 and is planned to include a set of protocol restoration changes that represent an almost complete return to the original protocol and as such we have decided to give it the code name “Genesis”. The proposed date is 11 years, 1 month and 1 day after the original Genesis block and this upgrade represents the return to Genesis and the restoration of the Satoshi Vision that is the project’s namesake and primary purpose.
The Genesis upgrade will also address scaling. We believe that by late in 2019 the Bitcoin SV node software will have implemented all of the safety mechanisms required to allow us to eliminate the block size cap altogether and let miners manage it without intervention from developers. So long as those changes are completed we intend to bring the planned date for allowing unlimited block size forward by almost a year and lift the cap completely in the Genesis upgrade.
The (incomplete) list of proposed changes include:
- Sunsetting of P2SH
- Replacing 32 math op codes with BigNumber versions
- Sunsetting 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…
In the coming months we will be making a series of posts on all of these things explaining the mechanisms proposed for each of these changes, the prerequisites required and why the Bitcoin SV team have concluded these changes can be done safely and securely.
Outside of consensus
This post has focussed mostly on consensus protocol upgrades, but the majority of the work on Bitcoin SV isn’t at the protocol level. It’s under the hood and is what enables scaling. There is so much to report on what we’ve discovered, what we’ve done and we plan to do that it deserves several posts of its own.
We will be explaining the work we are doing at a non-consensus level on the software itself so the roadmap to progress is more widely understood. I will leave a non-exhaustive list of some of the broader topics here and will be listening to feedback from the ecosystem about issues they’d like to hear about first.
- Parallel transaction validation
- Parallel block validation
- Poison block attack mitigations
- Poison script attack mitigations
- Horrific mempool structures
- The cost of small blocks (aka fee tracking)
- Restoring fast propagation (work in progress)
- Ancestor limit
- Child pays for parent
- Updating the mining API
- Fixing the block building process
- QA process improvement
Steve Shadders
