Bitcoin Unlimited Code Changes
gandrewstone merged 20 commits overseen by deadalnix and sickpig from “sickpig:port/deadalnix-pr-213-to-218” into “BitcoinUnlimited:dev”. During the merge, 38 files were changed for a total of 1,009 additions and 594 deletions. These changes are a culmination of several pull requests, and are mostly comprised of backports. The original authors of each commit can be viewed in a list here. One large element of these changes are 7 commits backported by deadalnix. Each pull request is dependent upon the pull request that occurs numerically before it, and in order, they are: #213, #214, #215, #216, #217, #218. These various pull requests cover a wide range of client optimizations, including reorganizations of where certain tests are stored, updates to OpenSSL, and the creation of a “generatetoaddress” Remote Procedure Call. In addition to these commits, developer sickpig also transcribed a large quantity of backports. Pull request #7797 from the bitcoin Core team was included in these changes to help fix an unforeseen bug introduced with the Unlimited pull request #214. In addition, a complete change set was implemented in the client. This change set was geared at moving and re-compartmentalizing the internal miner code of the client. This was done to simultaneously increase the ease and efficiency of future backporting projects from other development teams while ensuring that such porting would come with as few errors and issues needing to be resolved.
gandrewstone merged 24 commits by ptschip from “ptschip:dev_parallel” into “BitcoinUnlimited:dev”. During the merge, 34 files were changed for a total of 1,925 additions and 322 deletions. These changes bring about an optimized method of block validation: Parallel Validation. This validation method was created by the same team who originally created the Extreme Thin Blocks concept which has since migrated to the other major clients beyond bitcoin Unlimited. Parallel Validation, as defined by the developers, is: “Rather than validating each block within the main processing thread, we instead create a separate thread to do the block validation. If more than one block arrives to be processed then we create yet another thread. There are currently up to 4 parallel block processing threads available making a big block DDOS attack impossible.” This method of validation eliminates the hazard of the hypothetical “Big Block DDOS” by opening up the validation capacity 4 times over. Since this validation allows more than one block to enter the process at a time, the development team goes on to describe the features that Parallel Validation offers in this scenario. They are described as: “If there are multiple blocks processing at the same time, when one of the blocks wins the race to complete, then the other threads of processing are interrupted and the winner will be able to update the UTXO and advance the chain tip. However, the other blocks that were interrupted will still be stored on disk in the event of a re-org. The blocks that are allowed to finish or are interrupted depend again on the rules of which block has the most proof of work”. This method of validation represents a massive protocol improvement over the current validation method.
gandrewstone merged 2 commits by sickpig from “sickpig:fix/mac_build” into “BitcoinUnlimited:dev”. During the merge, 7 files were changed for a total of 101 additions and 1 deletion. These changes were backports from bitcoin Core. These 2 commits bring to the Unlimited client support for different builds specifically for Mac operating systems. The first of the two commits was originally developed by kallewoof. It’s changes focuses on compilation on OS X software with QT enabled, forcing the usage of built in byte-swap if available. The second of the two commits was developed by theuni. This set of changes focus on the build of QT5.7 on Mac operating systems. These two backports bring a greater depth of customizability to the Unlimited client, deepening the user experience, while providing a wider selection of build options.
Bitcoin Classic Code Changes
zander merged 1 commit by jamoes from “jamoes:blocksizeacceptlimit-gui” into “bitcoinclassic:master”. During the merge, 4 files were changed for a total of 79 additions and 0 deletions. These additions to the client bring about an update to the graphic user interface. Previously, a user would not have an option to modify their preferred accepted block size acceptance listed in the user interface when viewing their input options. These changes modify this by adding just such an option labelled as “Block Size Accept Limit” into the options dialogue. These changes modify the behavior of the client to keep it’s flexibility towards on chain scaling available and readily accessible to it’s users. These changes lay in the ground work for all future modifications of this client behavior as well. In a brief dialogue between developers from the Classic team in the comments of this pull request, future optimizations for the system were suggested and discussed. The full conversation between the team on the subject can be viewed here.
zander merged 1 commit by jamoes from “jamoes:blocksizeacceptlimitbytes” into “bitcoinclassic:master”. During the merge, 5 files were changed for a total of 23 additions and 8 deletions. These changes deal with the clients default parameters established for accepted block size. These changes add a new command line option to the client: “blocksizeacceptlimitbytes”. This command allows users to set a default accepted block size within the client. These changes also modify the “DEFAULT_BLOCK_ACCEPT_SIZE” system by changing its constant from a ‘float’ type to a ‘int32_t’ type, which is an unsigned 32-bit integer. These changes also add a new batch of tests for the new command line flags being added to the client. The priority of these command line flags as defined by the developer are: “Check for ‘-blocksizeacceptlimit; first. Then, use ‘-blocksizeacceptlimitbytes’ if the first is not specified. Finally, fall back to ‘-excessiveblocksize’ if none of the others are specified.”
zander committed “Update script” within 1 file for a total of 13 additions and 9 deletions. These changes were made to update and fix the file permissions used in the “contrib/debian/postinst” file. Previously, the file permissions were relatively straight forward. These changes remove a small amount of technical debt, while streamlining the permissions themselves. The changes expand upon the permissions path in the client, all while ensuring proper client behavior. These changes also add some small technical touch ups, including proper spacing and notation, as well as a slight expansion and correct ordering of the different subsystems present in this file.
Bitcoin Core Code Changes
MarcoFalke merged 1 commit by jnewbery from”jnewbery:docstrings” into “bitcoin:master”. During the merge, 89 files were changed for a total of 389 additions and 484 deletions. These changes bring about documentation for the tests in the “qa” system, including all Remote Procedure Calls. Previously, tests in this system would have light or even no explanation as the functionality of the tests. These changes modify this, adding description modules to each test in the system with correlative length to the tests complexity. These changes deepen the user interface, adding a higher degree of understanding and information to the user in relation to what these tests are for and how they function.
iaanwj merged 1 commit by TheBlueMatt from “TheBlueMatt:2017-02-pieter-revsig” into “bitcoin:master”. During the merge, 1 file was changed for a total of 104 additions and 0 deletions. These changes add a list of sidned commits into the “revsig-commits” file. Developer sipa performed some house cleaning duties, and in the process, revoked a series of subways. These subkeys are utilized for verify-commits, and without them, these commits have to be white listed in order to pass. This commit adds a list of older commits signed by sipa into the “revsig-commits” file to alleviate this white listing issue. As developer TheBlueMatt describes: “The purpose of the allow-revsig-commits file is just this – if a key is revoked, for whatever reason, you commit the list of hashes so that we still allow the sig, but only for commits that were known prior to the revocation”.
iaanwj merged 4 of his own commits from “laanwj:2017_02_osrandom” into “bitcoin:master”. During the merge, 6 files were changed for a total of 174 additions and 11 deletions. These changes focus on entropy and randomness within operating systems. These changes bring “GetOSRandom” functionality to the operating systems of Linux, OpenBSD, and FreeBSD. Previously, when a user of a Unix like system wishes to generate randomness in their operating system, they might use the built in pseudo-devices “/dev/random” and “/dev/random”. These changes bring the entropy-supplying system call “GetOSRandom” to the client. These changes also bring some tests into the client for “GetOSRandom”, ensuring that it does not fail and that all bytes of entropy are overridden. In the commit messages, there was some discussion towards it’s future implementation in the client. For example, author iaanwj commented: “Another option would be to use them only when /dev/urandom is not available. But this would mean these code paths receive less testing, and I’m not sure there is any reason to prefer /dev/urandom”.
iaanwj merged 1 commit by sipa from “sipa:merge_sha512” into “bitcoin:master”. During the merge, 1 file was changed for a total of 43 additions and 3 deletions. These changes add a SHA512 hash to a merged commit message. This SHA512 hash pertains to the merged tree in the code repository. sipa commented on this has generation: “Assuming gpg uses a sufficiently strong hash internally, this results in our gpg signed commits avoiding any potential SHA1 issues w.r.t. the commit’s resulting contents (but NOT its history)”. These changes were made to address a potential compromise of the security of the repository and its users. These changes provide this security measure, ensuring safe and efficient guards against false code additions. Lead developer iaanwj commented on the security additions: “this is a nice and simple change that alleviates the direct worries about SHA1 compromise. More advanced things or functionality to reject symlinks can be added to the script later”.
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