Bitcoin Unlimited Code Changes
gandrewstone merged 1 commit by deadalnix from “deadalnix:alertnotifyparam” into “BitcoinUnlimited:dev”. During the merge, 1 file was changed for a total of 6 additions and 9 deletions. These changes deal with the “AlertNotify” system in the client, and it’s parameters. The AlertNotify system is used to execute different types of commands, and it’s proper functioning is important to the overall structure of the client. Previously, there were several lines of code within the client that specified executing a Boolean check when the AlertNotify system is engaged. deadalnix noted that the AlertNotify system is always true, and the necessity to check whether it’s variable was marked “true” or “false” was unnecessary. These changes modify the AlertNotify system parameters, removing this unnecessary checking. These changes remove some technical debt from the client, strengthening and streamlining it’s performance.
gandrewstone merged 10 commits by AllanDoensen from “AllanDoensen:devGuiFix” into “BitcoinUnlimited:dev”. During the merge, 6 files were changed for a total of 234 additions and 67 deletions. The changes deal with the Graphical User Interface within the client. In the previously committed Pull Request #373 made by AllanDoensen, the developer laid out his intentions in regards to modifying the Graphical User Interface of the client. He stated: “The current unlimited settings dialog does not validate the text being entered by the user into the 3 textfields that control blocksize increases. When the user enters an invalid value and hits ‘OK’ on the dialog then invalid settings ‘silently’ fail. While not a critical bug, the user experience is not good in this situation. He continued on to commit changes that added QT Validators to text inputs, helping to remedy this situation. After lengthy peer review, it was determined that there was many more changes that could be made to optimize this element of the client. The developer submitted this second Pull Request from “AllanDoensen:devGuiFix” to address these suggestions.The changes in the subject Pull Request are varied, and see many new optimizations to the clients Graphical User Interface. One set of changes deals with changing a users inputs to the color red if they should enter a value that is unsupported or invalid. Another set of changes modifies the behavior of “TWeak Validators” ensuring that the client follows proper validation procedure when comparing variables. There are several other changes that this merging brings to the client, and readers are encouraged to review the full Pull Request’s contents here.
gandrewstone merged 8 commits by kyuupichan from “kyuupichan:rpc-console” into “BitcoinUnlimited:dev” During the merge, 14 files were changed for a total of 287 additions and 63 deletions. These changes are a series of Backports, and modify the clients Debug Window and Remote Procedure Calls Console. The Backports were taken from development team bitcoin Core. The first set of changes in this Pull Request completed the second and final portion of backporting a security optimization to the clients timer behavior. Another set of changes bring about an optimization for the Graphical User Interface of the Remote Procedure Call console in the form of variable size adjustment for the display text. A third set of changes brings auto-complete features to the Remote Procedure Call console as well. The final set of changes in this Pull Request replaces all “build-date” data with “DataDir” in the systems information tab. This Pull Request brings several new optimizations and security improvements to the client, allowing for smoother operations on the user end, while deepening the user experience.
Bitcoin XT Code Changes
dagurval committed “DRY: Exception handling for thin blocks.” in the “bitcoinxt:master” branch within 1 file for a total of 16 additions and 18 deletions. These changes deal with “Thin Blocks” code. These changes modify the code dealing with error an error message associated with Thin Blocks. Previously, if a certain type of Thin Blocks error occurred within the client, it would execute dealing with the issue in a particular order. These changes eliminate the original code for catching and displaying the error, and replaces it with a much more details error output message, and subsequent handling code. Further more, the changes go on to modify the locking behavior of the client should an error occur, opting to reorder certain variables, speeding up client performance. These changes help to catch potential errors sooner and more efficiently in the Thin Blocks system, and eliminate a small portion of technical debt.
Bitcoin Core Code Changes
iaanwj merged 3 commits by jnewbery from “jnewbery:bitcoin_tx_input_sanitiser” into “bitcoin:master”. During the merge, 3 files were changed for a total of 54 additions and 0 deletions. These additions to client deal with several systems. The first set of changes deals with modifies the client’s behavior so that the total number of arguments being passed to “bitcoin-tx” both in “outaddr” and “outpubkey” are all accounted for. The next set of changes adds a new test for “bitcoin-tx” specific for bitcoin-tx “stderr” will the purpose of verifying that all expected errors within the system are raised to the user. The final set of changes also deal with tests. These tests asses different cases where “bitcoin tx” might be called by “outaddr” and “outpubkey” with an incorrect quantity of separators. These changes help to ensure proper client performance, and optimize it’s utilities for the user.
iaanwj merged 1 commit by gmaxwell from “gmaxwell:log_category_simplify” into “bitcoin:master”. During the merge, 30 files were changed for a total of 377 additions and 273 deletions. These changes modify the “LogAcceptCategory” system of the client, completely restructuring it. Previously, this system used sets of “strings” for all of it’s categories. The main focus of this Pull Request is to replace all of these string sets with boolean flags, or rather, true or false indicators. This Pull request achieves this by replacing all of the string sets with a uint32_t fixed width integer. This modification of the system affects the client in several ways. First, it simplifies the system’s acceptance by avoiding complicated string access. Second, it eliminates the only usage of “boost::thread_specific_ptr” within the client outside of “lockorder” debugging. Third, it eliminates the “fDebug” global, as well as throwing a warning if a user attempts to log unknown categories. Finally, as the developer describes it: “This change allows log entries to be directed to multiple categories and makes it easy to change the logging flags at runtime.” These changes improve the performance of “LogAcceptCategory” by refining it’s infrastructure. The developer also states that should the need to expand the boolean flag integer in the future, updating the “uint32_t” integer to a “uint64_t” integer would be simple.
iaanwj merged 6 of his own commits from “laanwj:2017_03_fs” into “bitcoin:master”. During the merge, 34 files were changed for a total of 233 additions and 207 deletions. These changes deal with the “boost::filesystem” and it’s structure. These changes fall under the “Boost -> C++ Migration” tab of the development teams “Ongoing Projects”. The changes begin by wrapping the “boost::filesystem” as the “FS” namespace all contained within one header. These changes also “fsbridge” to the system for use of bridging both “stdio.h” and “open()” with the path type. These changes lay the groundwork for future implementations. The developer describes these future possibilities as: “Replacing it when the time comes with ‘std::filesystem’ (when standardized, and when we start using the appropriate c++ version) with a single change.” As an added bonus the developer describes one other perk these changes bring: “It’s less typing, too.”
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