Bitcoin Unlimited Code Changes
gandrewstone merged 8 commits by kyuupichan from “kyuupichan:backport/macos_docs” into “BitcoinUnlimited:dev” During the merge, 3 files were changed for a total of 73 additions and 90 deletions. These changes were made on top of the previously merged pull request #323. Following the build components that pull #323 backported to the client, these changes add a series of documents describing the various build elements the client provides for Mac operating systems. These documents include instructions for building Protobuff Version 3, as well as updates to the Mac build notes for version 10.11 of the Software Development Kit. These backported description documents help to deepen the experience for users of Mac operating systems by providing the information and instructions necessary to build within the client.
gandrewstone merged 1 commit by kyuupichan from “kyuupichan:addrman” into “BitcoinUnlimited:dev”. During the merge, 3 files were changed for a total of 391 additions and 49 deletions. These changes were backports from bitcoin Core, and affect the “CAddrMan” and “CAddrinfo” systems. Previously in the client, the tests used in these systems were deterministic tests exclusively. Deterministic tests will always return the same values if they are supplied the same inputs, and are useful for testing exact internal behavior of a system. However, this predictability can give rise to oversights and potential bugs to be found in fringe cases. These changes provide Non-Deterministic tests to these systems, allowing such potential fringe cases and oversights to be curtailed. These changes also add a several new tests to these systems, significantly expanding the testing curriculum. These changes bring a higher degree of stability to the client, allowing for much more analytical and concise development behind the scenes.
gandrewstone merged 1 commit by ptschip from “ptschip:dev_ban” into “BitcoinUnlimited:dev”. During the merge, 1 file was changed for a total of 136 additions and 135 deletions. These changes affect the Network Initialization in the client. During the startup of the client, one of the most important elements of it’s functionality is the syncing with the blockchain. This is a fundamental element of the bitcoin ecosystem as a whole. During this syncing process, a large degree of data is exchanged with the network, and the activation ordering of the various systems found in the client is critical. These changes affect that ordering, ensuring smooth client operation from start up on. As the author of the commit describes it, these changes: “Make Network initialization happen after the blockchain is loaded and checked. This prevents connection attempts from getting backed and then executed all at once at the end of the startup, which can result in a premature ban of a node or network crawler.”
gandrewstone merged 5 of his own commits from “gandrewstone:dev” into “BitcoinUnlimited:dev”. During the merge, 4 files were changed for a total of 87 additions and 13 deletions. These changes were made to restrict certain parameters within the client for miner specific inputs. One of the largest elements of note within the bitcoin Unlimited client is the users ability to dictate what size blocks they are willing to accept and validate with their client. This parameter is set with the EB system, or the Excessive Block Size system. In the case of miners however, one other important parameter that is established is the Mined Block Size. It is very important for these two systems to work symbiotically, for if a miner produces a block that is of a larger size than what their clients are willing to accept, such an unintentionally excessive block would become a problem. These changes force these two systems to work in tandem by limiting the Mined Block Size parameters to be less than or equal to the parameters of Excessive Block Size. This ensures that no accidental blocks are generated that violate the users preferences. These changes also lay the groundwork functionally speaking for some future improvements to the Graphical User Interface. As of the merging of this pull request, there is no error message accompanying it for use in the case of incorrect inputs being applied. While the code laid out in this pull will automatically reject any invalid inputs, the user will not receive a message detailing and informing them the specifics of why such a rejection is occurring. This leaves room for improvement down the road, and as developer gandrewstone describes it: “Miners are likely not using the GUI, and there is not machinery to display an error message in the unlimited dialog box, so quite a few changes must be made. I will add the GUI error message in a subsequent PR.”
Bitcoin Classic Code Changes
zander merged 1 commit by jamoes from “jamoes:adminlisten” into “bitcoinclassic:master”. During the merge, 4 files were changed for a total of 34 additions and 4 deletions. These changes bring a new command line argument to the client named “-adminlisten”. These changes resolve issue #208. As the issue this pull request resolves was requesting, these changes establish a new configuration property that allows users to choose the port number they wish to listen to. Should the user not elect to enter a specific port, the system will listen to “127.0.0.1” and “[::1]” by default. In addition, these changes also see the inclusion of an Admins Server port to the “chainparamsbase” system. This portion of the pull request deviates from the original issue requests slightly. Originally, the issue requested that if a user were to not specify a port to listen to, their client would automatically set to “0.0.0.0” and listen to all available ports. Instead, the “chainparamsbase” Admin Server port will now set to “127.0.0.1” by default. This is done so that a user may not accidentally open their node’s Admin Server to external connections.
zander committed “String support is not needed here.” in “bitcoinclassic:master” within 1 file for a total of 4 additions and 17 deletions. These changes modify the behavior of strings in the “src/serialize.h” system. Previously, there was coded in support for string usage in “src/serialize.h”. These changes remove this support, as it is not applicable to these particular files. The developer describes removing string support from this system as: “we don’t use strings in this class because std::string and utf8 are not best friends.” While quite humorous, this explanation does an excellent job conferring the incompatibilities with string usage between these two systems. For string support, zander goes on to say: “Compact Message Format users should look at the Streaming::MessageBuilder and MessageParser for better support.”
zander committed “Move the reindexing code to BlocksDB” in “bitcoinclassic:master” within 8 files for a total of 238 additions and 218 deletions.These changes reorganize the files containing the client’s reindexing code. These changes maneuver this code into the “BlocksDB” system. zander provides a light overview of this pull request: “The most visible change is that the global boolean fReindex is now owned by BlocksDB and directly coupled to the persistent storage
of that boolean.” These changes help to streamline the client by repackaging and reorganizing it’s systems. These changes also serve as a light optimization for the reindexing code the client uses, polishing and updating it during it’s transfer to “BlocksDB” system.
zander commited “Updates to the dev-notes.” in “bitcoinclassic:master” within 1 file for a total of 21 additions and 15 deletions. These changes bring changes to the developers notes of the client. As bitcoin is so far an open source coding project, anyone can contribute potential changes to the codebase of a bitcoin client. Developers notes stand as a guide post for developers seeking to submit commits to the project, providing a rough set of parameters for the house keeping procedures desired by the team. These changes refresh the Classic team’s developer notes, and provide clarification of certain usage cases. In regards tot his clarification, zander writes: “Make clear the difference between a method() and a (global) Function() case.” These changes also provide a request to developers working in certain areas of code, asking developers to write code utilizing atomics and lock-free solutions if possible. This done to ensure a secure and streamlined client which offers a compact and complete solution to consumers.
Bitcoin Core Code Changes
The bitcoin Core team has put forth the latest version of their full node client software: Version 0.14.0. This release comes on the heels of several months of work and commits from the team. As such, it is remarkably dense technically speaking. The team has put forth a comprehensive set of release notes detailing the many additions that have been made to this newest software version since the teams previous major release. These release notes should be viewed in full for a more thorough understanding of the release, but a brief synopsis of the new software’s major changes, (in the developers own words), are as follows:
– Performance Improvements: “Validation speed and network propagation performance have been greatly improved, leading to much shorter sync and initial block download times.”
– Manual Pruning: “Bitcoin Core has supported automatically pruning the blockchain since 0.11. Pruning the blockchain allows for significant storage space savings as the vast majority of the downloaded data can be discarded after processing so very little of it remains on the disk.”
– “getinfo” Deprecated: “The “getinfo” RPC command has been deprecated. Each field in the RPC call has been moved to another command’s output with that command also giving additional information that “getinfo” did not provide.”
– Network Activity Toggle: “A RPC command and GUI toggle have been added to enable or disable all p2p network activity. The network status icon in the bottom right hand corner is now the GUI toggle. Clicking the icon will either enable or disable all p2p network activity. If network activity is disabled, the icon will be grayed out with an X on top of it.”
– Sensitive Data Is No Longer Stored In Debug Console History: “The debug console maintains a history of previously entered commands that can be accessed by pressing the Up-arrow key so that users can easily reuse previously entered commands. Commands which have sensitive information such as passphrases and private keys will now have a (…) in place of the parameters when accessed through the history.”
– Introduction of assumed-valid blocks: “A significant portion of the initial block download time is spent verifying scripts/signatures. Although the verification must pass to ensure the security of the system, no other result from this verification is needed: If the node knew the history of a given block were valid it could skip checking scripts for its ancestors.”
All readers are again highly encouraged to view the release notes, and the fully detailed change log here. This brief list is far from comprehensive of the changes this document list, and is intended only as an overview of the major changes this software release brings to users. The release notes credit 99 individual developers how helped make this release possible. Between these 99 developers, 399 individual pull requests were merged in “bitcoin:master”
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