Weekly musing #8 - Keep calm and fork
 |
BTCfork
A rebase on very recent BU dev branch has been completed.
I learned the painful lesson that it is much easier just to merge in the changes from upstream as opposed to actually rebasing (in Git's sense) all the MVF work, which would necessitate a forced push on MVF-BU's master (default) branch. That would be disruptive to those who have checkouts of MVF-BU (not many, I suppose, but it would be bad practice).
Thinking about requirements for a UASF counter-fork to UASF will see me adding a few requirements to the MVFs.
One of them is probably time-based forking - in order to fork exactly on an unknown block height which corresponds to the median time activation criterion of BIP148 or similar proposals. This would make MVFs capable of forking on either block height OR a chosen time, whichever comes first.
One could set the block height to a very high value if one did not want to use it, to let the time-based forking take precedence.
I've held off on implementing time-based forking up to now since it comes with a few more complications. The client cannot tell for certain when the final pre-fork block has been received, and this makes things like changing to the new consensus rules and performing wallet backups harder. But it seems that flag day forks like UASF require a forking trigger in MVF to be able to fork at exactly the same time, so as to create the least difference between the fork blockchain and the legacy chain.
A rebase of MVF-Core is still outstanding. The objective will be to rebase on Core 0.14 minus SegWit/RBF, but with Adjustable Blocksize Cap.
Bitcoin Unlimited
Apart from reviews and minor fixes to some extended tests, I've uploaded my eligible BUIPs for the coming voting round.
I am keen to see the new voting system in action, although it is becoming clear that it will need a bit of handholding by its creator for the first session. This is of course normal. So far, I like what I've seen! There are some areas that may need small improvement in future, e.g. in management of unpublished proposals, and dealing with users who have lost their keys and need to revoke them. The latter part may be a bit tricky! I would recommend BU users to always keep a separate PGP key for BU signing purposes, so that they could use that to revoke the Bitcoin key in a pinch.
References
[1] Image of Vevey fork in Lake Geneva derived from public domain (CC0) work:
https://pixabay.com/en/vevey-lake-fork-switzerland-museum-2104986/