A peek inside the development process
Many of you are at this point eagerly waiting to hear the latest about our upcoming PoW² release, is it done yet, when will it be ready etc. In the absence of information gossip and rumour take over, so rather than leaving things open to speculation we thought it would be better just to give a quick update.
The 2.0 release
The core changes of PoW² itself are at this point essentially done, and ready to begin testing. And we are excited to do just that, however there are some obstacles still to overcome.
“What obstacles could those possibly be?” is probably the question that comes to your mind immediately, I mean surely this release is only PoW² so if that is done then the release is done?
Well, no, there is a lot more to a properly done major release than that, a few things to consider:
- PoW² will break backwards compatibility so there needs to be a smooth transition process to ensure everyone can upgrade and as few issues as possible are experienced
- Many users don’t update frequently so we need to make sure this release contains as many bug fixes as we can.
- We also need to ensure that it is as forward compatible as possible with future changes that we want.
So what else needs to be done for the 2.0 release:
- We should update to the latest bitcoin codebase and make sure we test and release the latest code with the most recent bug fixes – good news this is already done.
- We should decide what to do about SegWit.
- We should make sure that we have implemented everything in a way that works best for the coin going forward.
So what does SegWit have to do with PoW²? Well nothing, and everything all at the same time. Directly they have nothing whatsoever to do with one another, however they do share two things in common.
- They both require changes to the way transactions are handled, so it makes sense to consider the way these changes may interact with one another.
- They both potentially can be implemented in a way that breaks backwards compatibility.
The Bitcoin implementation of SegWit bends over backwards to maintain backwards compatibility, which means that several not so great tradeoffs have been made. For instance instead of decreasing the size of transactions SegWit will temporarily -increase- the size of transactions for an indefinite amount of time until backwards compatibility can be phased out.
This makes sense in their specific situation, however we are not Bitcoin and we are not subject to the same constraints so it does not make sense to simply copy what they have done (as so many other altcoins have rushed out to do) but instead to pave our own way forward.
So thats what we are doing, as we need to break backwards compatibility anyway for 2.0 we are going to take full advantage of that, which means we are going to do two other things in this release:
- We are going to implement something similar to how SegWit was meant to be, with transactions that are smaller (not bigger) etc. Before all the backwards compatibility compromises were forced. We will be calling this SegSig (Segregated Signature) so that it will not be confused with PoW² Witnessing and so that people will not accidentally mistake it for a plain SegWit implementation.
- We are going to give a complete overhaul to the transaction/script system allowing us to implement PoW² and SegSig in as clean a way as possible, leading to even further reductions in transaction sizes (above what SegSig brings) and cleaner implementation of future innovations making it less likely we will need to break backwards compatibility in future.
“But won’t this delay the release?”
I imagine this is the next question everyone will have, and the answer is, well no not really not in any significant way at least.
These are all things that we have been working on and considering for months already so for the most part it is already done, however even if it does result in a slight delay I’m sure we can all agree that doing things right is better in the long run than making poor decisions that impact future developments.
PoW² roll out
So how is this all going to roll out in reality? How soon will people be able to start witnessing? Does this mean we will need to wait months to witness after the software is released?
The Gulden 2.0 roll out will be as follows:
Phase 1 – Gulden 2.0 will be released, it will function exactly like an upgraded 1.6 at this point with no PoW² functionality present yet. Upgraded miners will signal for an upgrade, when 75% of miners are signalling the software will activate phase 2.
(Expected to last at most a week or two – depending on miners)
Phase 2 – A new special backwards compatible transaction script type will become available to upgraded (2.0) users which will allow them to create witnessing addresses. Old (1.6) users will verify these scripts but won’t be able to create or use them.
Once a minimum threshold is reached (200 or more witnessing accounts with a combined weight of 20 million or more) we will enter Phase 3.
(Expected to last at most a week or two – depending on coin holders)
Phase 3 – PoW² witnessing commences, with a few limitations that allow old (1.6) users to remain on the network (no transactions allowed yet in the witness portion of the block for instance). Witnesses and miners will automatically start signalling a percentage of how many upgraded users they are seeing, when this percentage goes over an average of 95% for a fixed time period we will enter Phase 4.
(We anticipate that this may take several months)
Phase 4 – At this point our backwards incompatible changes trigger, new transaction format/rules activate, PoW² witnesses start to include transactions in their portion of the block, witness accounts start to switch over to a new improved backwards incompatible transaction format, new accounts using the old temporary format are no longer allowed, SegSig activates etc. The remaining 5% of 1.6.x users will no longer be able to participate in the network.
Phase 5 – After some time 2.1 will be released, code to support old witness accounts can/will be safely removed with affecting block validation – leaving us with a codebase free of technical debt. Checkpointing can also be safely removed at this point.
This information is subject to change. No rights can be derived from this document.