Bitcoin Unlimited Code Changes
The bitcoin Unlimited project has release the newest version of their full node client software: Bitcoin Unlimited 1.0.0. This software release marks the 3rd release by the bitcoin Unlimited team. This new version of the Unlimited full node client software brings together the multitudes of commits and improvements made by the team over the previous months, and provides a smooth, powerful, and intuitive user experience. Solex, forum moderator of www.bitco.in and member of the Unlimited team, compiled a release statement for 1.0.0 general release. In Solex’s own words: “The third official BU client release reflects our opinion that Bitcoin full-node software has reached a milestone of functionality, stability and scalability. Hence, completion of the alpha/beta phase throughout 2009-16 can be marked in our release version.”
The bitcoin Unlimited project, sharing a similar mindset with the bitcoin Classic and XT projects, seeks to alter the bitcoin ecosystem, and the technical manner in which it operates. This newest software release provides users with many different tools and options to “vote with their nodes”, and begin pushing bitcoin in a direction of larger block size parameters and a network of emergent consensus. As Solex describes it: “The most important feature of BU’s first general release is functionality to restore market dynamics at the discretion of the full-node network. Activation will result in eliminating the artificial full-blocks handicap, restoring a healthy fee-market, allow reliable confirmation times, fair user fees, and re-igniting stalled network effect growth”.
This release, just as much as the recent bitcoin Classic release from a few weeks back, provides a multitude of new features. Some highlights of the major elements and improvements of this software release include:
– Emergent Consensus Improvements: The parameters for Emergent Consensus have been strengthened and streamlined, eliminating potential attack vectors, and providing signature operations for accurate counting of blocks as they increase over 1mb.
– Wide-spectrum Anti-DoS improvements: Providing better security against “Denial of Service” attacks, the client now screens peers for “heavy hitters” and “excessive invasive traffic, and evicts them should they trigger any red flags.
– Orphan Pool Transaction Management Improvements: The orphan pool has seen a host of improvements, particularly in the efficiency by which it evicts and erases transactions when it is required. Possible attack vectors were also theorized, and precautionary steps taken to mitigate them.
– XThin Block Propagation Optimizations: Following the monitoring of live traffic of XThin Blocks and their propagation, many general improvements and enhancements have been made to ensure fast and efficient XThin blocks performance.
– Maintenance and Fixes: The client saw a generalized cleaning across the majority of its systems. The majority of these were to provide greater client stability across a multitude of operating systems, as well as to provide a complete deterministic build for users utilizing ARM architecture.
This edition of bitcoin Unlimited does not include the features “Replace by Fee” or “Alert Key” as these systems have been determined to be either dangerous to the bitcoin protocol, or dated in their functioning, and have not been included in the Unlimited client since version 0.12.0.
Download binaries for the 1.0.0 bitcoin Unlimited release can be found here.
The source code for the project can be viewed in the bitcoin Unlimited GitHub repository here.
(For information regarding the block produced with parameters over the network cap of 1mb that was accidentally made using the Unlimited client this week, please see the news section at the bottom of this code report)
Bitcoin Classic Code Changes
Bitcoin Classic release manager zander has issued a general update about the Classic project titled: “What is new in Bitcoin Classic (2017/01/30)”. In a similar fashion to these code reports, zander broke down many of the recent major updates and changes made to the Classic code base. These include updates for the teams recent software release, (which will become the 1.2.1 version), as well as new code being developed for the next version of Classic (version 1.3).
These code reports seek to impart the thoughts and intentions of the client developers onto the public, and seeing as zander has provided just such an outline for the teams recent work, this section will be, by and large, composed of his own words. As such, all quotations used for the remainder of this section will be from zander and his update unless otherwise stated.
In reference to the development of the 1.2 stable branch of the Classic code: “We have seen bugfixes in the 1.2 stable branch (to become the 1.2.1 release)”
– “[QT] Bugfix: ensure tray icon menu is not empty. By Stephen McCarthy.”
– “Fix failing maxuploadtarget.py QA test from the -extended set. By Stephen McCarthy.”
– “Make configure fail on old Boost. (1.55 has been the minimum for some time)”
zander committed “Make configure detect old Boost.” within 1 file for a total of 1 addition and 1 deletion.
In reference to the development of version 1.3: “On the ‘master’ line of coding (to become the 1.3 version) we have seen various improvements as well.”
– “We merged a PR written by Pat O’Brien that sanitises the default permissions of files written by the node on Unix. Adding code to make sure that the wallet.dat is only ever visible to the main user.”
– “Merge a PR from Søren B.C. to remove some dead code (semicolons) from many files.”
– “Merge various Pull Requests from Amaury Sechet for backports and to add sublime text project file to gitignore”
– “Merge a PR from Stephen McCarthy that makes sure that any unrecognized command line arguments or config-file lines will cause a warning on startup. This should make it much easier to configure the application.”
– “Cleanup the NetworkStyle usage. This makes code less fragile and more coherent.”
zander committed “Cleanup the NetworkStyle a little.” within 7 files for a total of 93 additions and 91 deletions.
– “Remove duplicate (copy/pasted) code originally imported from the xthin project.”
zander committed “Cleanup and add some debug output” within 3 files for a total of 19 additions and 31 deletions.
Bitcoin Core Code Changes
iaanwj merged 1 commit by sdaftuar from “sdaftuar:2017-01-net-time-comparisons” into “bitcoin:master”. During the merge, 5 files were changed for a total of 28 additions and 18 deletions. These changes were made as an update to the “network” portion of the Core code, and deal with determining periods of inactivity. Previously, the client utilized mock times in its test logic. This caused an unforeseen issue between the systems of “GetTime()” and “GetTimeMicros()/1000000”. This is due to the fact that “GetTime()” was utilizing mock time values while “GetTimeMicros()/1000000” would pull its values from the system clock. This inconsistency made the comparison of these two systems in calculating inactivity unreliable. These changes modify “GetTime()” and force it to use the system clock as well to ensure consistency between the two systems.
MarcoFlake merged 1 commit by kallewoof committed from “kallewoof:no-using-namespace-src” into “bitcoin:master”. During the merge, 13 files were changed for a total of 179 additions and 206 deletions. These changes are the last addition to a set of ongoing pull requests made by kallewoof with the intention of removing “namespace” usage from the Core client. These particular changes removed the usage of namespace from all files bearing prefix “src/“. Developer kallewoof also included the binaries for all of his changes, as well as a list of all affected files for the “src?” namespace removals. kallewoof has been working on this project since the end of November 2016.
iaanwj merged 8 commits by morcos from “morcos:walletincremental” into “bitcoin:master”. During the merge, 6 files were changed for a total of 70 additions and 36 deletions. These changes are built on top of previous commits made by morcos, and deal with the client’s wallet and its fees, specifically “bumpfee”. One element of these changes introduces “WALLET_INCREMENTAL_RELAY_FEE” into the client, which modifies the default bump value of the wallet to be higher that of “incrementalRelayFee”. This is done to ensure that if ever the “incrementalRelayFee” is modified within the client, or by nodes on the network, nodes running this software would still relay to the network. These changes also modify the descriptor for the resulting value of “bumpfee” from “oldfee” to “origfee”. This was done to clarify a confusion caused by “oldfee” producing an error message resulting in two different numeric values for the output, instead of the appropriate actual fee for a transaction that was replaced.
iaanwj merged 3 commits by sdaftuar from “sdaftuar:2017-01-bumpfee-error-cleanup” into “bitcoin:master”. During the merge, 3 files were changed for a total of 77 additions and 21 deletions. These changes were built on top of previous changes made by developer morcos, and deals with “bumpfee”. The first element of these changes modifies the algorithm used to correctly calculate the size of the “bumpfee”, or replacement transaction. The size of the “bumpfee” will directly determine the value of the fee attached to transactions, so correct calculation is key. The second element of these changes deals with a potential error within the chronology of “bumpfee” processing. Previously, if a potential “bumpfee” failed to enter the mempool once generated, this would trigger a remote procedure call error to the client. This is misleading to users however, as the new transaction would be indicated in the wallet, while the original transaction would not be marked as replaced. This would make it appear that the operation failed. These changes force the delivery of new transaction ID’s to users one generated, and aggregates any errors into a single JSON object and returns it to the client, similar to how the Core client handles other remote procedure calls.
Some News From The Bitcoin Ecosystem
Bitcoin Classic developer Tom Zander called for the formation of a new channel of communication between bitcoin developers. Tom was in attendance at the recent Satoshi Roundtable this previous week in Cancun, and returned from it with many thoughts about the most efficient ways of moving the ecosystem forward. In his call for a new communication channel, Tom quoted Rick Falkvinge, who released his impressions of the Roundtable a few days prior on his blog, as saying: “Overall, my assessment is that bitcoin is lacking project management”. Following this logos, Tom stated: “If we want to have any hope of so many smart people making progress again, we need to stop trying to skip step 1. We need to allow people to talk to each other and start the conversation on how to address the concern Rick formulated on his blog.” He would go on to expand on how to accomplish this: “This week I reached out to the Bitcoin Unlimited team on their slack in order to get their input on starting a new mailing list under new management that can accomplish the goal of cross-team communication. We had some good ideas, one of them was to call it the ‘post-1MB planning’ list.” This theoretical mailing list would cover a host of topics, but most importantly, it would deal with bitcoin consensus rules. In his communication call, Tom describes the current consensus issue: “What is interesting is that there currently is no bitcoin-wide document how the consensus rules are actually supposed to be changed to support Bitcoin Classic or Unlimited. This needs to change.” This mailing list could provide an excellent neutral environment by which developers from different teams could communicate openly about their goals and intentions to produce an ecosystem wide consensus prior to large protocol changes that affect all users become implemented. Any developers or organizations interested in assisting with such a project are encouraged to contact Tom Zander at his email here: firstname.lastname@example.org
Following the first general release from the bitcoin Unlimited team, a truly remarkable phenomena occurred: The first block with parameters above the current 1mb block size restriction was accidentally mined. Block number 450,529 was mined by the bitcoin.com mining pool on January 29th, 2017 with an additional 23 bytes of data above the stated 1mb protocol limit. This resulted in the block being being immediately rejected by the same node that mined it, in addition to all the other nodes seeking to verify it with the parameters of a 1mb acceptance established. This anomaly was caused by an error in the code of the bitcoin Unlimited software being utilized by the pool, which was running the latest Unlimited software version 1.0.0. This error was immediately patched by the Unlimited development team. In an incident report published by bitcoin.com’s mining pool managers, it has been shown that the event was closely analyzed, and the mitigation of the error was quick and efficient by both the pool, and the Unlimited development team. While this unforeseen bug in the Unlimited code has generated no shortage of outcry from those in contention with increasing the block size, this strange event has been incredibly useful in verifying two hotly contested topics: that of whether or not larger blocks are functionally possible, and how the Nakamoto Consensus defines the parameters of emergent consensus. For those unfamiliar with the topic of the Nakamoto Consensus, it deals with full nodes and their individual decisions to accept or reject a particular block, and this notion drives the central element of the bitcoin networks decentralization. This excerpt is taken from the original white paper published by Satoshi Nakamoto, and in “Section 12: Conclusion”, Satoshi says: “Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.” This immediate, and automated response by the bitcoin network demonstrates that nodes determine which blocks they will or will not accept, and while the Unlimited client is geared at removing the current block size limitation in favor of emergent consensus, this anomalous block violated the current protocol limits, and was rejected.