Bitcoin Unlimited Code Changes
gandrewstone merged 1 commit by jamoes from “jamoes:bu-tray-icon-menu” into “BitcoinUnlimited:release”. During the merge, 1 file was changed for a total of 5 additions and 5 deletions. Developer jamoes, common contributor to the bitcoin Classic team, provided the same code he committed some weeks prior for Classic to the Unlimited project as well. These changes fix a bug that could occur that caused the tray icon for the client software to appear empty on certain operating systems. In the developers own words: “This change resolves this bug by moving the ‘trayIcon->show()’ call to be made after the ‘trayIcon >setContextMenu(trayIconMenu)’ call”. These changes enhance the user experience with the client, ensuring proper functionality and usability.
gandrewstone merged 1 commit by ptschip from “ptschip:dev_orphanui” into “BitcoinUnlimited:dev”. During the merge, 5 files were changed for a total of 49 additions and 10 deletions. These changes surround information gathering, particularly in regards to the orphan cache of transactions. Currently, the orphan cache timeout is tied to the transaction timeout, establishing a standardized 72 hour wait time for cache expiration. These changes add the ability to monitor the size of the orphan cache over time to determine if these two timeouts should remain linked, or if it would be more expedient and efficient to give them their own unique timeouts. In the developers own words: “In the future we could decouple this so that orhpans could be purged more quickly from the cache rather than waiting the standard 72 hours”.
gandrewstone merged 2 commits by ptschip from “ptschip:dev_thinblock” into “BitcoinUnlimited:dev”. During the merge, 1 file was changed for a total of 16 additions and 7 deletions. This commit was titled “More thinblock updates”, and it is an apt description of it’s contents. These changes bring a light clean up to to the thin block process, refining their structure. These changes also ensure that the lock that engages in response to “cs_orphancache” remains closed for a much longer period of time. This is done to help guarantee proper locking order in relation to the thin blocks system.
gandrewstone committed “Updates copyright for 2017” with the help of developer HansHauge. The commit was made within 406 files for a total of 407 additions and 407 deletions. These changes run the length of the bitcoin Unlimited client, and see the replacement of all usage of the value 2016 with 2017 in relation to the copyright information presented by the developers. This brings the client up to date from the previous year. Developer HansHauge expressed his satisfaction with contributing to the bitcoin Unlimited code base, saying: “No problem! Now I can add ‘Bitcoin Unlimited Contributor’ to my resume…”
Bitcoin Classic Code Changes
zander committed “Move orphans handling to one class” within 6 files for a total of 400 additions and 188 deletions. These changes were made in regards to orphaned transactions and the manner in which the client handles them. Orphaned transaction are transactions that are present in orphaned blocks. When orphaning occurs, the orphaned transactions are placed into the memory pool where they can be reevaluated, or drained as necessary. In the Classic client, the manner in which this is achieved is very akin to the functionality of the other major clients. This is done to ensure cross compatibility between the clients on the network. However, as release manger for Classic zander describes it, these changes were a part of the “make it object oriented again” movement Classic is working towards. These changes fall in line with a development ideology now being re-expressed within the client wherein the focus is put upon the object of the moment, in this case orphaned transactions and the ‘orphancache’. By developing software with this object oriented focus, software can be achieved that is concise and functionally sound. These changes in particular streamline the functionality of ‘orphancache’ and it’s handling into one class, slimming down the code base in certain areas, while establishing the parameters soundly for the cache into it’s own system.
zander committed “Add expedited handling” within 9 files for a total of 478 additions and 148 deletions. These changes deal with thinblocks, and their functionality. Primarily, the purpose of thinblocks, (also known by their full title of Extreme Thinblocks), is expediency and efficiency. When nodes need to communicate across the network, sending the data of an entire block can be extremely compromising to both storage and bandwidth in terms of sheer data volume. Thinblocks provide a solution to this by reordering the construction of a block to be slimmer, more compact, and far easier and efficient to move between nodes. These changes move some of the code that deals with thin block handling into the dedicated thinblocks code system: “thinblock.cpp”. These changes also rewrite the reconstruction process for the thinblock itself, streamlining the reconstruction itself and greatly speeding up the process.
zander committed “[FT] Add new feature -ft-strict” within 4 files for a total of 63 additions and 0 deletions. These changes deal with Flexible Transactions. FlexTrans, which is currently in Beta in the latest client release from bitcoin Classic, solves the malleability issues with transactions, as well as other problems facing bitcoin such as the quadratic hashing issue. FlexTrans utilizes different tokens to function, including undefined tokens for certain purposes. In the current software, these tokens are ignored if present to ensure compatibility with older node software when new types of tokens are created. These changes add a new feature to the client called “-ft-strict”, which serves to take this token management a step further. For miners, rejected transactions are time consuming and result in losses. These changes turn on the functionality of ignoring these FlexTrans tokens to ensure that any miners who should encounter them do not have their transactions rejected due to this non-recognition.
Bitcoin Core Code Changes
sipa merged 10 commits by TheBlueMatt from “TheBlueMatt:2017-02-fix-copystats-races” into “bitcoin:master”. During the merge, 3 files were changed for a total of 105 additions and 45 deletions. These changes were built on top of pull request #9645, and address potential attack vectors present in bitcoin clients. The reasoning behind these changes, as stated by the developer: “Because we (finally) have C++11, there is no excuse for using ints/flags/anything concurrently.” These changes address two systems that were omitted in the previous pull request. TheBlueMatt describes how the pull request #9645 addressed many of the security vulnerabilities when it was merged, but left out a pair of systems. He says: “#9645 got most of them, but the last two (addrName and addrLocal) were left out because they might need more discussion.” These changes gives omitted systems a wrapper, which does lock them functionally and closes the attack vector, but it does create copies of them during their use. These changes help the client in addressing potential larger problems should they arise in the future.
iaanwj merged 3 of his own commits from “laanwj:2017_02_dnsseeds” into “bitcoin:master”. During the merge, 5 files were changed for a total of 2,084 additions and 1,614 deletions. These changes modify the hardcoded seeds present in the client. As the Core team works towards the release of their .14.0 full node client, several under the hood improvements are taking place. This is one such, modifying the hard coded seeds utilized by the client, and updating them to the most current versions. Developer sipa provided his domain name server list of seeds for these changes. These changes also update the seeds tooled specifically for Python 3, helping keep the client modern and efficient for future coding and upgrades.
iaanwj merged 2 of his own commits from “laanwj:2017_02_qt_translations” into “bitcoin:master”. During the merge, 9 files were changed for a total of 1,520 additions and 224 deletions. These changes deal with QT-format specifiers, and how the client handles them. Qt formatting for developers can be challenging when not handled properly. These changes address this by handling all numeric format specifiers and “others” as Qt format. As iaanwj describes: “ In the case of Qt formatting, only numeric formats are replaced at all. This means (percentage: %1%) is valid (which was introduced in #9461), without needing any kind of escaping that would be necessary for ‘strprintf’”. These changes provide these parameters, ensuring that “%)” will not wrongly be detected as a print format specifier. These changes also contain a periodic translation update for Transifex.
iaanwj merged 5 commits by ryanofsky from “ryanofsky:watchtime” into “bitcoin:master”. During the merge, 7 files were changed for a total of 130 additions and 57 deletions. These changes are built on top of pull request #9682. 3 of the commits in this pull request pertain to #9682, the remaining two became the current pull #9108. These changes affect how an addresses timestamp is saved in the client. Currently, when a watch only address is imported using “importmulti”, its wallet’s “nTimeFirstKey” is set to 1. These changes allow for a specify time stamp that is associated with the address to be imported and stored as metadata associated with the watch only key. As developer ryanofsky describes: “This can improve wallet performance because it can avoid the need to scan the entire blockchain for watch only addresses when timestamps are provided”.
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