Bitcoin Unlimited Code Changes
gandrewstone merged 1 commit by nomnombtc from “nomnombtc:noban_wlist_dev” into “BitcoinUnlimited:dev”. During the merge, 1 file was changed for a total of 6 additions and 3 deletions. Theses changes fix an unintentional banning of XTHIN enabled nodes that have already been whitelisted. Following a series of focused attacks on bitcoin Unlimited clients, (clients with XTHIN enabled), the Unlimited development team has been taking extra steps to ensure the XTHIN code base is as secure and efficient as possible. In the wake of the most recent attacks, certain precautions were enabled for users by which they can whitelist certain nodes they know are safe so as not to be disconnected from. Recent commit activity in the Unlimited repository has seen the addition of certain ban specific code that focuses on keeping healthy XTHIN nodes safe against potential incursion by malicious peers. An unintended side effect of these precautions was raised by nomnombtc in an issue report. nomnombtc was experiencing a bug in which a node he was operating would be occasionally banned by mistake by the new precautionary code changes despite the fact that his node was whitelisted by his other nodes. The developer then took steps to ensure that the new precautionary measures would not go into effect against nodes that are whitelisted within the client even if these whitelisted nodes are suspect by the measures. These changes resolve this bug with whitelisted peers, ensuring proper connectivity and node vitality.
gandrewstone merged 7 commits by awemany from “awemany:port-afl-fuzzing” into “BitcoinUnlimited:dev”. During the merge, 6 files were changed for a total of 353 additions and 0 deletions. These additions bring a new piece of automated software to the client for the use of client testing. In the development of software and code, it goes without saying that it is extremely critical to check each creation for proper functionality and efficiency. But while this process may appear easy, the actual review process for developing code can be nothing short of tedious, and in the case of developer proximity to their own creations, blinding. For these reasons, developers need to have tools in their kits designed to assist them in the review process to bring not only a unique set of capabilities to the table, but a fresh set of eyes so to speak. A very good example of such a tool developers employ is a Fuzzer. A Fuzzer is an automated piece of software that is designed to input large amounts of data, be it random or invalid, into a software system to test it for potential bugs, breaks, and leaks. Fuzzers are typically designed to produce “sneaky” data that will appear to the program being tested to be just acceptable enough to pass any initial inspection, but will still be invalid enough to generate new and unexpected behavior as it accesses deeper layers of the software. The changes in this Pull Request are backports that add a Fuzzer of this exact nature to the Unlimited client. The backports were adapted from bitcoin Core. The Fuzzer contained within these backports is titled the “American Fuzzy Lop” Fuzzer, or AFL for short. This program is open source per the Bitcoin standard, and is developed and maintained by Michał Zalewski. Author of the backports awemany noted the the process of using the Fuzzer was slower than it could be, noting his rate was: “40 forks/s/core on my machine”. He elaborated that there was a potential efficiency and speed upgrade possible for this software at some point in the future shouldd it become desirable. The presence of this Fuzzer in the client will now enable the Unlimited development team to systematically stress test their client in a controlled environment to seek out any unforeseen anomalies and further strengthen it’s structure.
Bitcoin Classic Code Changes
zander committed “Make logging sections bigger” into “bitcoinclassic:master” within 2 files for a total of 16 additions and 16 deletions. These changes modify the structure of the Logger within the client and how it displays information. When a user moves to log certain parts of their client, the Logger software set up within the client will subsequently log and output the requested sections. In terms of displaying this logging, the logger previously had a limitation set to 100 debug areas per section of logging. The changes within this Pull Request modify this limitation and expand the restriction to 1000 debug areas per section. This increase in logging debug areas allows a user much more flexibility in terms of using their client’s Logger and enables them to log more data at once. Classic Release Manager zander commented on this increase in the review of his Pull, stating: “100 may get too crowded in the end, and since we have plenty of space, assign 1000 debug areas to each section.”
Bitcoin Core Code Changes
iaanwj merged 1 commit by ryanofsky from “ryanofsky:pr/scanimp” into “bitcoin:master”. During the merge, 2 files were changed for a total of 65 additions and 6 deletions. These changes fix a bug that was present in the “importwallet” system of the client. Previously, if a user were to engage a rescan of “importwallet”, the scan would begin starting at the timestamp of the creation date for the imported wallet rather than the most recent block added to the blockchain. In rare cases, this could result in a situation where the rescan could miss crucial data. These changes address this bug by ensuring that the rescan will begin early enough to catch all blocks, including blocks with decreasing timestamps and blocks with multiple timestamps. These changes ensure proper functionality of the “importwallet” rescan and strengthen the system’s structure.
iaanwj merged 1 commit by practicalswift from “practicalswift:fast-afl-fuzzing” into “bitcoin:master”. During the merge, 2 files were changed for a total of 28 additions and 3 deletions. These changes affect clients settings for the “American Fuzzy Lop” fuzz testing. The “American Fuzzy Lop” software, or “AFL” for short, is an open source Fuzzer system that is designed to be a test for different programs. It functions by taking the program being tested and feeding it large quantities of random or intentionally invalid data, (nicknamed “fuzz”), to check for unwanted breaks, leaks, and bugs. Fuzzer software is an extremely valuable tool in the toolkit of developers as it offers an inside look at their codes resilience to vast inputs of data as well as being an efficient method to test for bugs. This software is the same software this is mentioned above in the bitcoin Unlimited section as the code for the “American Fuzzy Lop” Fuzzer was backported to the Unlimited client from bitcoin Core. The changes within this Pull Request aim to greatly improve the performance speed of the Fuzzer. To achieve this speed increase, developer practicalswift added two new options to the Fuzzer code. User may now replace “afl-gcc” with “afl-clang-fast” and “afl-g++” with “afl-clang-fast++” in their client’s Fuzzer code. Doing so will enable the Fuzzer to compile in such a way that it may make use of a “persistent mode” and a “deferred forkserver”. These two feature allow the Fuzzer to function expeditiously in comparison to it’s standard operation. With these two features enabled, the Fuzzer see it’s estimated execution times drop exponentially and it’s total speed increase by nearly 200%. These changes vastly improve the performance of the “American Fuzzy Lop” Fuzzer software present in the client, and allows developers to perform valuable tests and performance checks with increased efficiency.
iaanwj merged 4 commits by ryanofsky from “ryanofsky:pr/ipc-move” into “bitcoin:master”. During the merge, 6 files were changed for a total of 235 additions and 54 deletions. These changes deal with moving code specific for “WalletModel” functions into “CWallet”. Developer ryanofsky has been working for several weeks to to create code specifically for use in client Interprocess Communication. Interprocess Communications, often shortened to “IPC”, are the mechanisms by which different processes functioning on the same operating manage shared data. Interprocess Communication is essential for distributed computing systems. Relating Interprocess Communication to the code migration in this Pull Request, author ryanofsky says: “Motivation for moving these is to make supporting IPC simpler. These lookups can be one-shot IPC requests instead of back-and-forth interactions over the IPC channel.” ryanofsky also references another experimental Pull Request he is currently developing that is an aimed at providing Interprocess Communication support to the “bitcoin-qt” system by using a specific Interprocess Communication protocol titled “Cap’n Proto”. In this referenced Pull, ryanofsky expands on his vision for Interprocess Communication integration with the client. He states: “The motivation behind this change is to be able to start moving bitcoin from a monolithic architecture where UI, P2P, wallet, consensus, and database code all runs in a single process, to a more modular design.” The changes within this sections Pull Request are the initial steps in ryanofsky’s vision for a modular bitcoin client. Further developments on this project will be covered as the code is refined.
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