Weekly musing #12 - Gearing up for release

Final touches on ABC

Bitcoin ABC is a modified version of Bitcoin Core with a user-configurable maximum blocksize, i.e. an Adjustable Blocksize Cap (hence "ABC").

It is based on Core 0.14.1, and implements the UAHF specification. The source code and development can be found at https://reviews.bitcoinabc.org .

We've been very busy getting this to near release so far. There are a few minor finishing touches remaining on the code, but it's almost feature complete.

In a follow-up post I'd like to do a walk-through post of the changes at some stage, but this requires reformatting the baseline (the Core 0.14.1 commit where ABC branched off) so that we can cleanly compare what was built on top.

The difference looks bigger than it really is in terms of code changes, because nearly the entire codebase has been put through clang-format to clean up the source code. This obscures the significant functional changes to an extent. A git diff --stat shows 508 changed files so far - that includes files that were newly added (e.g. ABC tests) and files that were removed (e.g. those related purely to SegWit).

Re-formatting the baseline 0.14.1 with the same style rules to get a clean comparison requires some touch-ups. This is because some sections in ABC were protected from clang-format's modifications. There are also manual formatting actions to improve layouting of comments, although these are easy to ignore. Overall, there were 337 commits since development on top of Core commit 964a185cc began.

It could be helpful to mark the functional changes related to UAHF with their respective requirements.

Test framework issues

We have identified what is likely an issue with the Python test framework's handling of peer messages.

During tests with large blocks, the test framework's mininode may run into buffering problems on the received data, which often leads to test failure. This only seems to happen towards the end of one big-block test at the moment, and there is a workaround to reduces the chance of this happening.

However, it is very likely that we need to re-work the test framework's message buffering and processing if we want to be able to do very-large-block tests.

Perhaps this played a role in previous tests where we struggled to test > 16MB blocks.

On testnet3, the forked client has produced blocks over 15MB already which were well received by its peers.