Bitcoin Unlimited Code Changes
AllanDoensen committed “Merge branch ‘release’ of https://github.com/BitcoinUnlimited/BitcoinUnlimited into release” in the “BitcoinUnlimited:release” branch within 22 files for a total of 280 additions and 170 deletions. These changes come from a newer code contributor to the bitcoin Unlimited project named Allan Doensen. Apart from the Unlimited code base, Allan is also involved in other bitcoin client software projects, including a build titled “Bitcoin Unified” which seeks to blend the bitcoin Core code base with the emergent consensus block size parameters of bitcoin Unlimited. The changes that this pull request deals with are varied in purpose. Several of the changes deal with proper labelling, modifying and updating various descriptors to display the latest versions of the code base. Other changes update the clients description of certain systems, adding a more enriched message to users about the functionality of the systems being described. These changes also transfer over the various changes that were developed in the “dev” branch in relation to assertions and their behavior within the client. These modifications help to bring stability and security to the client by closing potential attack vectors. Finally, these changes help to reorganize and restructure the code base, trimming away excessive code and streamlining the overall infrastructure of the client. This helps ensure expedient and efficient functionality, while retaining an uncluttered and confusing layout.
gandrewstone merged 1 commit by ptschip from”ptschip:dev_pruning” into “BitcoinUnlimited:dev”. During the merge, 1 file was changed for a total of 6 additions and 11 deletions. These changes deal with blockchain synchronization, and the clients parameters towards it. Developers seeking to optimize client speed and functionality typically establish efficiency rules and guidelines towards large quantities of data being moved in or out of the client. These changes help to establish this optimal efficiency, especially in the case of Parallel Validation. Developer ptschip describes his logic towards this commit as: “When doing IBD and especially when in pruning mode we don’t want to download too many blocks ahead otherwise we can possibly use up more disk space than is available to store unconnected blocks.” To ensure that this described client behavior doesn’t occur, ptschip goes on the say the following: “Right now it’s coded to not allow more than 256 blocks forward. Once we get some of the other issues with the request manager out of order blocks we may be able to tune this value and make is much less but for now it’s necessary to ensure an smooth IBD without gaps.” These changes keep the client functioning in the appropriate patterns necessary for newer client behaviors, such as Parallel Validation. to be further refined and implemented.
BitcoinUnlimited Janitor committed “add code formatting script and tweak style definition as agreed on slack, reformat BU only files” in the “BitcoinUnlimited:dev” branch within 14 files for a total of 2,898 additions and 2,416 deletions. These changes deal with reformatting the code base. Due to the eclectic and decentralized nature of bitcoin code development, hundreds of different mins have contributed to the open source code base over the years. And with these myriad of developers originating from within coding backgrounds ranging from the hobbyist to the professional, it is understandable that the resultant code of this blending of styles is somewhat messy. For this reason, a sizable portion of modern day bitcoin client refinement deals with code infrastructure. The bitcoin Unlimited team has been taking steps to maximize their code base’s readability and efficiency, ensuring ease of usage not only for themselves, but for any individuals who may with to make use of it down the road. Following a discussion in the teams Slack channel, the decision was made to refine the code written by the Unlimited team to be in the “Allman” coding style. Also sometimes known as “BSD Style”, (due to the creator of the style writing many of the utilities for BSD Unix), this coding style puts the brace associated with a control statement on the next line, indented to the same level as the control statement. This coding style differs from other coding styles such as “Egyptian” style wherein the braces come to resemble the famous “walk like an Egyptian” pose. These formatting changes only affect files in the “.src” directory, and only files that were written by the Unlimited team.
Bitcoin Classic Code Changes
zander merged 1 commit by zquestz from “zquestz:view_flush_assert” into “bitcoinclassic:master”. During the merge, 1 file was changed for a total of 2 additions and 1 deletion. These changes deal with assertions in the Classic code base. An assertion, (commonly contracted to assert), in the coding sense is a “true or false” statement that is expected to be true at the point of it’s usage in the code. Assertions have a variety of usage in many different coding languages, and they have historically been employed in all major bitcoin clients. One major problem with assertions is that should they fail when the code is run, they will generate an “assertion fail” error, which typically will cause a program to crash. This potential vulnerability in assertions was the culprit for the recent node attacks that were leveled at the bitcoin Unlimited client users. Following these attack, the Classic team began making extra efforts to remove any potential assertion vulnerabilities from their code base. These changes deal with a “view.Flush()” assertion within the client. Developer zquestz undertook the task of combing the code base for potential assertion vulnerabilities, and had this to say about the “view.Flush()” assertion: “Fixed another case of the view.Flush() assert issue. Went through most of the asserts in the code base, and it appears all the others are just conditional checks, not actual functions. Except this one.” These changes strengthen the Classic code base, ensuring proper functionality free from attack vectors. Developer zquestz finished his comment message by stating: “Going to do one more pass, if I find any others I will send a follow up PR.”
zander merged 2 commits by jamoes from “jamoes:max_sigops” into “bitcoinclassic:1.2”. During the merge, 8 files were changed for a total of 83 additions and 37 deletions. These changes deal with signature operations in the client, and it’s behavior in regards to them. Following the formal submission of the “Bitcoin Unlimited Improvement Proposal” #40, developer jamoes drafted these changes to maintain consensus with the propositions that the Unlimited team are seeking to implement in relation to signature operations. Signature operations inside of bitcoin transactions are very important as they contain necessary information used for verifying each transaction. As block sizes increases, the amount of signature operations data in each block will also increase. This presents a potential attack vector for a malicious entity, as broadcasting excessively large blocks with huge amounts of signature operation data could bloat and disable the network. The Unlimited team submitted BUIP #40 as a guide on the subject of how to handle signature operations in blocks larger than 1mb, as well as a countermeasure to this attack vector. The changes within this pull request lay out a similar approach for the Classic client to employ in relation to signature operations handling. The changes begin by adding a new “Policy::blockSigOpAcceptLimit” function to the client which will calculate the maximum allowed quantity of signature operations per the given block space.This formula is currently: 20,000 signature operations per megabyte, with he block size rounded up to the nearest megabyte. This ensures there will be enough space reserved for signature operations while eliminating the potential overage of space necessary for malicious attack type transactions. These changes also rename “MAX_BLOCK_SIGOPS” to “MAX_BLOCK_SIGOPS_PER_MB” while providing it it’s own definition. These changes also add unit tests for “Policy::blockSigOpAcceptLimit”, while updating other tests already within the client these new signature operation rules.
Bitcoin Core Code Changes
iaanwj merged 1 commit by jnewbery from “jnewbery:improveassumevalid” into “bitcoin:master”. During the merge, 2 files were changed for a total of 59 additions and 44 deletions. These changes deal with “assumevalid.py” and its behavior within the client. “assumevalid.py” was added to the client in the previously merged pull request #9484 and is geared at optimizing script validation by assuming a blocks ancestors are valid if they contain valid script signatures. Following the merge of this functionality, the “assumevalid.py” was not added to the “test_runner” system, resulting in the system absence from extended testing. Developer jnewbery describes his changes and their intentions: ”This commit adds assumevalid to the list of tests in test_runner. It also makes the code in assumevalid considerably clearer.” These changes help to ensure proper testing is occurring within the client, thus ensuring proper client functionality.
iaanwj merged 23 commits from “jonasschnelli:2016/12/hd_split” into “bitcoin:master”. During the merge, 8 files were changed for a total of 241 additions and 89 deletions. These changes deal with the clients Wallet and it’s internal functionality. The changes bring about a new HD chain for change outputs, resulting in split chains. First, these changes result in the internal keys of the client, (the ‘change outputs’), will use a “m/0’/1’/k'” set, while retaining the “m/0’/0’/k'” set for the external keys (‘getnewaddress’). These changes do not alter the usage of a single keypool, but they do bring a new internal flag for it’s usage: “fInternal”. After a round of review, these changes were modified so that rather than the keypad being filled with 80% external keys, it will now be filled with 100% external keys with an additional 20% (round ceil) internal keys. These changes also modify the functionality of the “getwalletinfo” call by now including the data from “keypoolsize_hd_internal” which provides the amount of internal keys currently in the keypool. Developer jonasschnelli also goes to discuss which versions of the client will be compatible with this new internal HD chain split. He says: “This hd split change will only affect new wallets. Current 0.13 HD wallets will continue to only use the external chain.”
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