Bitcoin Unlimited Code Changes
gandrewstone merged 2 commits by ptshcip from “ptschip:dev_stalling” into “BitcoinUnlimited:dev”. During the merge, 2 files were changed for a total of 1 addition and 22 deletions. These changes deal with technical debt and the removal of unnecessary code. Previously, a section of code was employed in the bitcoin Unlimited client titled “Block Stalling”. This code was employed to “stall” other functions of the client while performing certain behaviors. Following the introduction of the client’s “Request Manager”, many sections of the “Block Stalling” code became obsolete as the new Manager performed it’s functions. These changes remove the “Block Stalling” code, correcting some technical debt that had been present in the client. In the comments of this Pull Request, reviewers were discussing the absence of tests correlated with this code. Several reviewers noted that the original stalling code, which was ported with the initial fork of the client, did not contain any specific tests as well. Once the review process of the code removal within this Pull Request was finalized, the reviewers agreed that tests were necessary, and a method for accurate testing should be devised.
gandrewstone merged 5 of his own commits from “gandrewstone:dev_validateblocktemplate” into “BitcoinUnlimited:dev”. During the merge, 7 files were changed for a total of 460 additions and 8 deletions. These changes add a new Remote Procedure Call to the client specifically for miners. As the world of bitcoin mining is extremely fast paced and energy intensive, it is imperative that miners operate as efficiently and expediently as possible. One potential hazard that a miner may encounter in their efforts is receiving a potentially invalid block from a different client. This causes problems for two reasons. The first is that mining on top of such a block is a wasted effort, and marks a loss of time and resources for the miner. The second reason is the presence of an invalid block marks a miscommunication between clients, and it’s potential to occur should be removed completely from the mining equation. The changes laid out in this Pull Request eliminate both of the problems listed above by providing miners a method by which to check that a block is valid before mining on top of it. These changes achieve this in the form of a Remote Procedure Call which validates the block template of the block in question. This pre-check allows miners the flexibility to run different versions of bitcoin Unlimited as well as any other clients of their choosing while still retaining a guarantee that the client will accept each block as it is mined. These changes help to bring a greater degree of flexibility to miners allowing each miner in question to customize their software layout to meet their personal demands. This Procedure Call is constructed to check that a block is being built onto the chain tip of the block chain, and a result, it is crucial that each client involved in the template validation be synchronized with each other. If a miner were to feel that a node that transfers a questionable block to their client is not properly synchronized, the miner can force a sync to this node via “addnode”.
gandrewstone merged 8 commits by ptschip from “ptschip:dev_exploit” into “BitcoinUnlimited:dev”. During the merge, 12 files were changed for a total of 1,023 additions and 322 deletions. These changes are specific for XTHIN Blocks and the procedure of receiving them. Following a series of malicious attacks on bitcoin Unlimited clients which utilized XTHIN blocks as an attack vector, the Unlimited team has been working to ensure that the XTHIN block code in their code base is secure. As Xtreme THIN blocks have become an incredibly important element in the bitcoin ecosystem, the proper handling procedure surrounding them is also very important. These changes deal with the initial receiving of an XTHIN block from one client to another, and very clearly lays out the acceptable procedure. The four checks of the “Handshake” that occurs when an XTHIN block is received are first the “VERSION”, followed by the “VERACK”, followed by the “BUVERSION”, and finally the “BUVERACK”. These changes ensure that if any part of this process is not followed exactly than a client side ban of the delivering node will occur. This eliminates the potential of a malicious node attempting to deliver a harmful XTHIN block between clients. These changes also come with a host of tests specific for each section of the “Handshake” as well as other migrating all tests that deal with consistency from “thinblock.cpp” into “exploit.cpp”.
Bitcoin Classic Code Changes
zander merged 2 commits by AllanDoensen from “AllanDoensen:b12MultiMonFix” into “bitcoinclassic:1.2”. During the merge, 1 file was changed for a total of 9 additions and 6 deletions. These changes deal with user preferences and screen positioning of the client. Upon startup of the client, developer AllanDoensen noted that some issues could occur with the positioning of the client window on the monitor. After doing some light investigation, the developer deduced a potential miscommunication that could occur between the client and windows operating systems that could cause the client to display misaligned on multiple monitors. These changes address this potential error, and ensures that users who are employing multiple monitors will be able to display their Classic clients in the manner they desire.
zander committed “Protect against memory exhaustion.” into “bitcoinclassic:master” within 1 file for a total of 36 additions and 19 deletions. These changes deal with preventing Memory Exhaustion in the client. A very important element of any peer to peer network client is rigid security against malicious intent. Peer to peer networks are at their heart structured to connect individuals to each other, and this does not come without risk. As a result, any individual seeking to disrupt such a network need only to attack the various nodes of individuals to disrupt the flow of data. Such attacks can be mounted in various ways, but bitcoin is especially susceptible to several specific types of attack. As bitcoin clients deal with the exchange of data in the form of blocks, one potential attack vector is in the form of malicious blocks that are designed to be too large. These extremely large blocks, if accepted by unsuspecting client, will quickly overwhelm the clients capabilities to process it by exhausting it’s memory. Such an attack can easily take a node offline if precautions against such blocks are not taken. The changes laid out in this Pull Request seek to protect against such Memory Exhaustion attacks. These changes achieve this goal by limiting the amount of memory given to external inputs which does not allow creation of a block that is too large to accept. These changes also prevents the creation of a large amount of “uint256” instances.
Bitcoin Core Code Changes
iaanwj merged 5 commits by sipa from “sipa:chacha” into “bitcoin:master”. During the merge, 20 files were changed for a total of 482 additions and 44 deletions. These changes deal with the “FastRandomContext” of the client and the generation of randomness. The “FastRandomContex” system deals with creating randomness in the form of numbers to be used in tandem with security in the clients encryption. These changes bring a new cipher to the system titled “ChaCha20”. This cipher is related to the “Salsa20” cipher, but differs in its round functionality. This cipher is particularly useful in generating random numbers for the client. These changes also bring support to the “FastRandomContext” system for generating single bit of entropy. In the encryption sense, entropy refers a quantity of data and not the typical scientific definition of “systems breaking down”. These changes also bring benchmarks to the system which document the performance of its elements. Developer sipa noted that “rand32” became 5.2 times slower following these changes, while the new “randbool” function was on average 15% faster than the older function.
iaanwj merged 6 of his own commits from “laanwj:2017_03_wallet_dbwrapper” into “bitcoin:master”. During the merge, 9 files were changed for a total of 355 additions and 242 deletions. These changes deal with the client’s Wallet and how it handles it’s database. Developer iaanwj described the logic behind his changes: “My immediate goal with this is to make it easier to use a different key/value store instead of BerkeleyDB, for a sandboxing project. However, it is an improvement also for BerkeleyDB.” As stated these changes deal with the clients key / value store. The details provided by the developer are extensive, and readears are encouraged to look at his full dialogue here. The developer broke down the process of his changes into 4 steps. The first step deals with moving a filename from “strFilename” into “CWalletDBWrapper” as well as making it private. The second step removes “fFileBacked” from the codebase as it was deemed too much work to completely fix and would disjoint the code. The third step reduces the references made to the global value “bitdb” as it will eventually enable multiple database enviornments. The final step of the changes gives “CWalletDB” its own “CBD” making the system capable of replacing the internal transaction with a different database without internal leaks. The developer goes on to state several future projects that can be constructed on top of these changes. The changes in thiss Pull Request help bring greater internal structure to the key / value storage system of the client.
iaanwj merged 1 commit by kallewoof from “kallewoof:abort-rescan-tests” into “bitcoin:master”. During the merge, 2 files were changed for a total of 67 additions and 0 deletions. These changes add tests to the client for a new Remote Procedure Call. In the previous iteration of these code reports, developer kallewoof was shown to have contributed a new “abortrescan” Remote Procedure Call to the bitcoin Core client. This Call has the functionality of allowing users to abort a complete rescan of the blockchain should it occur against their wishes. Following the merge of the original Remote Procedure Call, reviewers requested that some tests of the new Call be committed as well. Developer kallewoof commits these tests in the form of the currently discussed Pull Request. He describes his tests as such: “A new function ‘ref_node’ was added to ‘util.py,’ which works like ‘start_node’ except it never actually launches the process. This is used to get two node objects in python which work separately from each other, in order to make two simultaneous requests (‘importprivkey’ and ‘abortrescan’).” These changes help to ensure that the “abortrescan” Remote Procedure Call is functioning optimally and behaving within it’s established parameters.
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