Gridcoin rebase
The original code used by Gridcoin dates back to 2014 and has passed through several coins before it ended up where it is now. As a consequence, it is severely outdated and diverged compared to the current Bitcoin/altcoin trees. To combat this Gridcoin will slowly be taken up to speed, piece by piece with the goal of being able to isolate Gridcoin changes in a manner that they end up being compatible with an up to date base.
Since there are so many changes beyond the areas changed by Gridcoin we should take a bottom-up approach. We start with the code which has the fewest dependencies, port them, remove them from the dependency tree and repeat. This will have the benefit of slowly bringing the Gridcoin code closer to the Bitcoin code making further porting easier.
To keep track of remaining work there is a graphviz dependency file showing all the remaining dependencies in the Bitcoin source tree. We should pick nodes with few dependencies, prioritizing code we do not have or have done very small modifications to. For each successful merge, the dependency tree is purged of the updated files and the tree shrinks.
We will eventually hit roadblocks where the code has diverged too much for a simple copy. These are the critical points and we should try to avoid modifying the upstream code where possible. One example of this is in the RPC handling where we have both added new and changed existing RPC calls to fit our needs. With newer Bitcoin code we have the option to inject new commands into the RPC handling table and to overwrite existing ones where we need it. This allows us to isolate our changes without disturbing the original code.
Here is an example where sync.cpp and sync.h along with the dependencies were brought up to date with the current (at the time) Bitcoin tree.
Before:
After:
This upstream sync slightly untangles the tree and allows us to progress further.
Some sources have undergone several iterations of changes and must be ported in steps. One example of this is uint256 which has both been split into two separate classes (uint256 and arith_uint256) and changed the way it behaves when serializing. These type of changes should be done in the same steps as in the upstream tree or the changeset will become too large to handle. In this case we would probably port the files in three steps
- from before the split into arith
- from after the split into arith
- from after the changes to serialize