Bitcoin Unlimited Code Changes
gandrewstone merged 1 commit by sickpig from “sickpig:doc/release-note-1.0.1” into “BitcoinUnlimited:release”. During the merge, 1 file was changed for a total of 76 additions and 0 deletions. These changes update the release notes for the latest software update from the team. Following the release of version 1.0.0, this release is a self described “bugfix rollup release”, and is a culmination of several of the larger development commits the team has made in the past few weeks. In the developers own words, the following list describes some of the changes this release contains:
– “ensure consistent configuration: When the excessive block and max mined block configuration is set or changed, that excessive block is >= max mined block.”
– “allow the “pushtx” RPC accept partial node IP addresses and it will search for the first match”
– “add miner maximum block generation size to CTweaks as “mining.blockSize””
– “point release 22.214.171.124: fix to reserve space for miner’s coinbase and correctly account for coinbase in internal miner”
This release is intended to update all current full node software from bitcoin Unlimited, and the developers provide a brief instruction dialogue for installation procedure:
“If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).”
ptschip committed “Fix potential unwanted assertion” with gandrewstone in the “Release” branch of the Unlimited code repository. This commit was made within 2 files for a total of 9 additions and 3 deletions. These changes are a Hotfix for an attack vector that was present in the Client. Earlier this week, an unknown assailant attacked the bitcoin network. These attacks were calculated, and focused solely on the users employing the bitcoin Unlimited full node client software. These attacks derailed the functionality of the Unlimited nodes by passing them invalid X Thin Block data resulting in their behavior becoming modified, and subsequently being taken offline through a Delay of Service. The developers of the Unlimited team gave an interview to a news site describing the details of the attack. Lead developer Andrew Stone stated that the Unlimited team had identified the possible attack vector, and were working on a patch for it prior to the attack. Before this patch could be released, a tweet highlighting the the attack vector was made by high profile developer Peter Todd who has in the past submitted code to the bitcoin Core project, and is perhaps most famous for his authoring of the Core feature “Replace by Fee”. This tweet generated no shortage of controversy. Almost immediately following the tweet, the aforementioned attack occurred, taking the majority of the bitcoin Unlimited nodes off the network. These changes close this attack vector, eliminating the risk of a future relapse attack of the same type. In the developers own words:
“Sending an invalid GET_XTHIN is a serious misbehavior and any node
doing so will be DOS100 banned immediately.
Also sending a GET_XTHIN with an invalid message type will also
cause the sendder to be banned.”
Bitcoin Classic Code Changes
*Notification* : Following the attacks this week of the bitcoin Unlimited full node client software, there has been some concern from the general public that the bitcoin Classic software may be vulnerable to the same attack vector as Unlimited as Classic originally received it’s XThin Block code from the Unlimited team. Release Manager zander put forth an official statement stating that bitcoin Classic does not bear the same remote-rash bug vulnerability, and is unaffected by the attack for this reason. A link to the statement is available here.
zander merged branch “1.2” in line with branch “bitcoinclassic:master” within 10 files for a total of 18 additions and 8 deletions. These changes were made to bring the most recent batch of finalized commit changes to the stable branch of the Classic code repository. These changes include two different commits. The first was a commit made to update the client to indicate the correct version revision number. Previously, the client’s current version had been updated once, but with this second revision, the number has been updated to “2”. These changes are a standardized and efficient house keeping procedure to help maintain client order and history. The second commit was a cherry pick of the code that the Unlimited development team implemented as a hotfix for the code vulnerability present in their client that led to the network attack earlier this week. As stated by the release manager above, bitcoin Classic is not susceptible to the same remote-crash bug, citing the teams quality standards for code implementation. The inclusion of this code from Unlimited is not a fix for a problem for this reason, but rather an effort to maintain consensus. If the bitcoin Unlimited project makes an alteration to their software to mitigate an attack, other client software must be able to cope with and remain in harmonious exchange alongside it to ensure optimal cross platform performance.
Bitcoin Core Code Changes
iaanwj merged 1 of his own commits from “laanwj:2017_03_014_release_notes” into “bitcoin:master”. During the merge, 1 file was changed for a total of 873 additions and 0 deletions. These changes bring the release notes for version 0.14.0 to the client’s release notes documentation folder. These release notes describe the full body of the work the Core team has performed over the last several months to bring the 0.14.0 release to the public. These notes also include a full change log documenting each new addition the 0.14.0 version includes over the prior software release. These releaser notes help to bring further understanding to users of the software of exactly what their software will contain and how it will function. The practice of including release notes is an excellent industry standard, and helps to achieve a more educated and informed public.
MarcoFalke merged 9 commits by jnewbery from “jnewbery:rpctestlogging” into “bitcoin:master”. During the merge, 53 files were changed for a total of 398 additions and 394 deletions.. These changes are described the developer as a “Work in Progress” pull request which brings logging functionality to the “test-framwork.py” module of the client. This new logger for the module will include two separate “Handlers” each with their own unique rolls. A “StreamHandler” will be responsible for outputting error messages as well as higher level records to “stderr”. A “FileHandler” will be responsible for outputting all log records to a new “test_framework.log” file in the temporary test directory. This logger will help bring much tighter control of feedback from the client in relation to testing and quality control. As the developer writes: “The eventual goal is to remove all print() calls and replace them with logging.” The implementation of such a logging module is the first step to achieving this over arching goal
iaanwj merged by jonasschnelli from “jonasschnelli:2017/01/fee_warning” into “bitcoin:master”. During the merge, 2 files were changed for a total 29 additions and 0 deletions. These changes modify the user interface of the client. Recently, bitcoin Core has been receiving reports that some of their users are sending transactions with very low fees. This is problematic, as any fee that is too low results in a transaction waiting far longer to receive a confirmation. This problem of sending fees that were too low was resulting from users utilizing the clients built in smartfee estimator. The estimator requires an analysis window of several blocks to project an appropriate median fee, and if the estimator has not performed an adequate check, the fee data that it recommends can be too low. These changes modify the users graphical interface to display a “Warning” message alongside the fee estimator which provides a clear update whenever fee estimation is currently unavailable. These changes help users to maintain proper fee structure when sending transactions so as to avoid excessively long confirmation times.
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