Bitcoin Unlimited Code Changes
A backport of bitcoin Core Pull Request #8613 by kyuupichan was merged into “BitcoinUnlimited:dev”. During the merge, 52 files were changed for a total of 1,942 additions and 372 deletions. These changes modify the clients internal subtree “src/leveldb” to a version containing the changes made for 1.19 that had been merged upstream of the current software version. LevelDB is an open source key / value store that is focused on speed and efficiency that was originally developed by Google. The system provides ordered mapping for string keys and string values while storing all data on disk. In the case of Bitcoin, blockchain metadata is stored within this LevelDB database. The changes laid out in this backport bring a specialized LevelDB subtree to the client allowing for a highly efficient and bitcoin focused key / value storage system to be utilized. These changes streamline the client functionally as well as allowing for a series of future optimizations.
gandrewstone merged 1 commit by Justaphf from “Justaphf:migrateSettings” into “BitcoinUnlimited:dev”. During the merge, 1 file was changed for a total of 135 additions and 7 deletions. These changes modify the start up of the client by adding a test specifically for saved Qt settings. Qt software is designed to be a cross-platform framework for applications allowing said applications to be developed on various software and hardware while requiring only very minor, if any, changes to the codebase. In the bitcoin Unlimited client, a previous Pull Request was merged which modified a setting that specifies that this software was made by the Unlimited team, namely “QAPP_ORG_NAME”. The client utilizes the value of this system to generate a registry path for the Qt application, and since the values were modified, the application would sometimes find itself pointed at an incorrect registry. These changes modify this behavior and close this redundancy ensuring that the client will behave as intended with no risk of losing stored preferences.
gandrewstone merged 3 commits by ptschip from ”ptschip:dev_netsplit” into “BitcoinUnlimited:dev”. During the merge 4 files were changed for a total of 104 additions and 23 deletions. These changes modify the clients setting regarding XTHIN capable nodes, and their connectivity. The developer elaborated on the nature of is changes in the comments of the Pull Request: “In the past we relied on ‘-addnode’ or ‘-connect-thinblock’ to manually configure connection to XTHIN capable nodes, or to just rely on luck in getting a connection.” These changes modify the client connection preferences to XTHIN capable nodes, ensuring there is at least a few nodes connected. The developer expounds on the nature of these changes: “Here we will actively seek out XTHIN nodes and maintain at least 4 connections or the minimum number of outbound connections whichever is less.” These changes guarantee that the client remains connected to the appropriate minimum / quantity of XTHIN capable nodes ensuring smooth network functionality.
gandrewstone merged 7 commits by AllanDoensen from “AllanDoensen:devWinBuildFix” into “BitcoinUnlimited:dev”. During the merge, 2 files were changed for a total of 73 additions and 18 deletions. These changes update documentation in the client. As the Unlimited client was initially forked from the original bitcoin client, it included some lineage documentation that described amongst other things the process of building the client on various operating systems. As operating system software continues to progress and evolve, proper documentation of it’s features and requirements remains very important for bitcoin client users seeking to compile and build their clients from source. Developer AllanDoensen elaborated upon the lineage documentation files that described build instructions for users bringing them up to date with current standards. These elaborations include a full set of instructions for users seeking to build utilizing the Windows Subsystem for Linux, as well as updating the existing documentation to include different command line arguments to help prevent potential build failure. These changes add an even higher degree of assistance to users who intend to build their client from source.
Bitcoin Classic Code Changes
zander merged 3 commits by ftrader from “ftrader:parallel-unit-test-tool” into “bitcoinclassic:master”. During the merge, 2 files were changed for a total of 561 additions and 0 deletions. These changes bring a new tool to the client specifically for Boost tests. The Boost Test framework is a library of interfaces for writing and controlling simple tests that is used primarily in the development of software. The major bitcoin clients all make use of the Boost Test framework in different ways, and bitcoin Classic is no exception to this. Boost tests can be extremely in depth if they are programmed as such, and as a result can take a long period of time to run in full. As a solution to this lengthy testing duration, an adaption of a piece of software originally written by Google was made. This adapted software is designed to run Unit Tests written in C++ within the Boost Framework in parallel with each other, and the Pull Request of this section adds this code to the Classic client. As the code utilizes a command line parameter specific for Boost, this parallel testing tool will only work in tandem with Boost version 1.59 or later. The tool references the clients “test_bitcoin” system’s executable, and queries it for a list of runnable tests. Once queried, the tests it receives will all run in parallel. This tool is also optimized for ongoing performance increases by storing a testing score per unit test which is stored in the pre-determined file labelled “~/.gtest-parallel-bitcoin-times”. These scores allow the tool to reorder the testing so that the longest tests are always engaged first which drastically helps to reduce lag and run time. In testing, this tool has proven itself capable of reducing the duration of Boost testing exponentially. In reference to this fact, the developer states: “Testing on a desktop machine with sufficient cores shows that the total test execution time when using this parallelization script is reduced to approximately the running time of the slowest unit test.”
zander committed “Add option -min-thin-peers to ensure we have better xthin connectivity” into “bitcoinclassic:master” within 7 files for a total of 223 additions and 40 deletions. These changes are an adaption of code that was contributed to the bitcoin Unlimited codebase this week that was authored by ptschip and aimed at XTHIN node connectivity. In a similar fashion, these changes ensure that a connection is established in the client to a minimum of XTHIN capable nodes allowing for efficient network functionality. However, there are a few differences between the original code merged into the Unlimited client and the code reported here. In the comments of the original Pull Request from bitcoin Unlimited, Classic release manager zander joined the review process and contributed several comments of his own. Building on top of the code submitted to Unlimited, zander wrote some additions of his own for his merge into the Classic client. These variations from the original include restructuring different global variables, including copy right notices, and renaming the system to be unique in its own right to maintain consistency. These changes are a part of the Classic client’s continued support and optimization toward XTHIN nodes.
Bitcoin Core Code Changes
iaanwj merged 2 commits by kallewoof from “kallewoof:rescan-abortability” into “bitcoin:master”. During the merge, 4 files were changed for a total of 46 additions and 1 deletion. These changes affect the clients “importprivkey” command in it’s Wallet. When a user enters the “importprivkey” command, an entire rescan of the blockchain is engaged unless the user explicitly indicates that the client should not. As this functionality is widely used in the client, accidental rescans of the blockchain are often made causing lengthy delays. These changes modify the behavior of this system by enacting an “abort” option for the blockchain rescan following a “importprivkey” command. This allows for the user to correct the redundancy if such a rescan was activated accidentally. The changes achieve this by adding support for a new Remote Procedure Call titled “abortrescan” that prompts “ScanForWalletTransactions” to stop scanning. Building on the top of these changes, reviewer jonasschnelli recommended that an addition be made to the wallet’s Graphical User Interface to include a button specifically for this abortion of the rescan. Author of the Pull Request Kallewoof agreed that an easily accessible and visible button for this Remote Procedure Call was outside the scope of this single Pull Request, and would seek to implement such a feature at a later date to compliment these current commits. These changes help to enhance the user experience with the Wallet of their client, and to ensure they are not subjected to undesired periods of latency.
iaanwj merged 1 commit by ryanofsky from “ryanofsky:pr/scanret” into “bitcoin:master”. During the merge, 2 files were changed for a total of 15 additions and 3 deletions. These changes improve the returned values of the “ScanForWalletTransactions” system. Following the merge of a previous Pull Request committed by ryanofsky, developer TheBlueMatt noticed some odd behavior that had begun to occur as a result in the client’s Application Program Interface. He noted that upon the running of the “ScanForWalletTransactions” system, the scan would sometimes return incorrect values based upon a failure that occurred while observing the blockchain. Developer ryanofsky stated that he intends to commit a more in depth and expansive change to the client’s Application Program Interface in the future, but chose to also release this fix for the “ScanForWalletTransactions” system’s current behavior. He states: “The only code currently using the ‘ScanForWalletTransactions’ return value is in ‘importmulti’, and ‘importmulti’ always calls ‘ScanForWalletTransactions’ with a pindex pointing to the first block in
chainActive whose block time is >= (nLowestTimestamp – 7200), while ‘ScanForWalletTransactions’ would only return null without reading blocks when pindex and every block after it had a block time < (nTimeFirstKey – 7200). These conditions could never happen at the same time because nTimeFirstKey <=nLowestTimestamp.” These changes modify the returned value of the “ScanForWalletTransactions” system by making the non-failing returned value to be non-null allowing for the differentiation of the two values.
iaanwj merged 7 commits by morcos from “morcos:moveTxConfirmStats” into “bitcoin:master”. During the merge, 15 files were changed for a total of 247 additions and 261 deletions. These changes completely refactor the “CBlockPolicyEstimator” system present in the client. As mentioned in a previous code report, code refactoring is the process of restructuring existing computer code, (changing the factoring), without changing its external behavior. This is essentially infrastructure work that is designed to not alter the behavior or performance of the client, and is done as an organization optimization. Up to this point in the history of the client, the “CBlockPolicyEstimator” system has been closely intertwined with the system that controls the Memory Pool of the client, namely “CTxMemPool”. This Pull Request is the first step in separating these two systems. The first series of changes in this Pull Request is that of making “CBlockPolicyEstimator” into its own global object. The “CTxMemPool” system will still need to reference “CBlockPolicyEstimator” for the time being, but this initial deviation allows for the beginnings of true separation wherein the memory pool will eventually never interact with the Policy Estimator. Developer morcos states in the comments of his Pull Request that there are also preliminary commits included in this Pull that lay the groundwork for future projects both potential and incipient related to Fee Estimation and “TxConfirmStats” in the “CBlockPolicyEstimator”.
The scaling debate is approaching its breaking point, and now more than ever, it is important for every individual, not just miners and software developers, to do their part. All readers are recommended to download and establish a full node supporting the client of their choice should they have the technological and economical means to do so. Download links for each of the major full node clients:
– Bitcoin Unlimited – (Pro immediate block size increase via hard fork, Emergent Consensus)
– Bitcoin Classic – (In line with the view points of bitcoin Unlimited, Emergent Consensus)
– Bitcoin XT – (In line with the view points of Classic and Unlimited)
– Bitcoin Core – (Block size increase slowly over several years, immediate soft fork w/ Segwit)
If any reader feels daunted, confused, or overwhelmed by this task, please do not hesitate to reach out