Bitcoin Unlimited Code Changes
gandrewstone merged 1 commit by ptschip from “ptschip:dev_sync” into “BitcoinUnlimited:dev”. During the merge, 2 files were changed for a total of 20 additions and 2 deletions. These changes deal with the clients initial syncing of the blockchain. Following the recent attacks that have been leveled at bitcoin Unlimited software users, the development team has taken steps to ensure security within their client. When a full node client first syncs with the blockchain, the node is required to download a series of headers that validate the node. After analysis, developer ptschip discovered that a malicious node could attempt to prevent the initial download of these headers. These changes address this possibility. As developer ptschip describes it: “In the event that we do not receive the initial batch of headers from a node then disconnect them safely with the fDisconnect flag and then give them a 4 hour ban.” These changes further outline secure node operation and helps to ensure a structured and safe environment for users.
gandrewstone merged 4 commits by ptschip from “ptschip:dev_parallel” into “BitcoinUnlimited:dev”. During the merge, 3 files were changed for a total of 29 additions and 19 deletions. These changes deal with Parallel Validation, and its “scriptqueue”. Developer ptschip describes the motivation behind for these changes as: “Previously we were releasing the queue in two places and from potentially two different threads which was causing an intermittent crash.” As a solution to this potential crash, ptschip goes on to say: “We only need to set the pScriptQueue = NULL in SetLocks() which is called when the boost scope guard is triggered in
connectblock().” Modifying the “scriptqueue” in this way so that it only releases from one thread at a time guarantees that the described potential crash will not occur. These changes help to strengthen and streamline the clients Parallel Validation feature, helping to speed up validation times exponentially.
gandrewstone merged 3 commits by deadalnix from “deadalnix:maxtxfee” into “BitcoinUnlimited:dev”. During the merge, 9 files were changed for a total of 26 additions and 25 deletions. These changes deal with the maximum transaction fee the client will accept, and are a backport of code from the bitcoin Core project. Occasionally in the bitcoin ecosystem, a user may accidentally send a transaction with an erroneously high transaction fee by mistake. Such a mistake is not only costly, but also demoralizing, as the fees sent are at the mercy of whomever validates the transaction. These changes address this potential user error by setting a maximum transaction fee within the client. This ensures that no such accidental overages will occur with accompanying fees. Upon the opening of this pull request, gandrewstone requested to deadalnix that the “maxtxfee” port be converted to a “CTweaks” variable to generate the functionality within the client to modify the values in a different fashion. deadalnix agreed with the request, modifying the object construction and initialization of the port to be a “CTweaks” variable.
gandrewstone merged 9 of his own commits from “gandrewstone:release” into “BitcoinUnlimited:release”. During the merge, 22 files were changed for a total of 280 additions and 170 deletions. These changes contain a large amount of information, and deal with a host of topics. First and foremost, this Pull Request is titled “Release 18.104.22.168”, and as implied, is the latest release of the client bearing various bug fixes, as well as other small details that were observed by reviewers. Following the events of the previous weeks attacks, the question of the Unlimited teams code review was being called into question in certain communities. This batch of changes was reviewed by a total of 12 different individuals including the release manager of bitcoin Classic, and the project lead for bitcoin XT. These changes address several different possible attack vectors that a malicious entity could try to exploit. Both of the attacks that were targeted at bitcoin Unlimited dealt with assertions and Xthin blocks. A good deal of these changes deal with assertions thusly, mitigating any possible avenues of attack. The commit “Re-Evaluate Use of Asserts” for example combs the client, reviewing and re-writing the clients behavior with assertions. These changes help to strengthen the client and it’s features, removing possible attack vectors and ensuring a secured user environment.
Bitcoin Classic Code Changes
zander committed “Cleanup xthin a little” in “bitcoinclassic:master” within 2 files for a total of 96 additions and 35 deletions. These changes deal with the Xthin Blocks code employed within the client. The Xtra Thin Blocks source code was developed by the bitcoin Unlimited team, and was ported into the Classic client. Following the attacks on users employing Xthin Blocks in their Unlimited clients last week, Classic release manager zander began the process of refining the Xthin code in the teams own way. As the previous attacks dealt with malicious entities sending incorrect Xthin Block data to nodes to crash them, the Classic team took steps to allow their software users to completely disable Xthin traffic in and out of the client should they wish. These changes commit this functionality, with zander describing them as: “First of all, when the user does not enable xthin, this now goes both ways. Before it was about the node sending out xthin requests, while always serving others. Now that is also disabled when the user turns off xthin.” These changes also modify the internal functionality of Xthin itself, modifying and sanitizing the blocks that Xthin allows. As the software is geared only at blocks that have come into existence after Xthin was implemented, the client will not accept Xthin block requests from historical blocks as Xthin does not pertain to them. This closes a potential attack vector as well as speeds up client performance. These changes also modify the Xthin behavior in regards to the ordering of Xthin functions. These changes add many new locking points to the Xthin system to ensure that if the client were to detect any misbehavior, it will safely lock and be address any errors promptly rather than allowing the client to succumb to a potential attack.
zander merged 1 commit by jamoes from “jamoes:nomaxvout” into “bitcoinclassic:master”. During the merge, 1 file was changed for a total of 1 addition and 4 deletions. These changes affect the clients “Bitcoin-Transaction” tool and the limits upon it’s inputs. These changes allow the usage of any positive integer in the “Input vOut” for transactions created the clients “Bitcoin-Transaction” tool. This change creates the same behavior as the “getrawtransaction” Remote Procedure Call that is present in other major clients. These changes allow for transactions made with the “Bitcoin-Transaction” tool to be created without an upper limit. These changes also remove all mention of “MAX_BLOCK_SIZE” from the “Bitcoin-Transaction” tool, allowing users to set their own block size in line with the views of Emergent Consensus.
Bitcoin Core Code Changes
jonasschnelli merged 3 commits written by himself and cherry picked by ryanofsky from “ryanofsky:pr/grbf” into “bitcoin:master”. During the merge, 6 files were changed for a total of 35 additions and 3 deletions. These changes modify the Graphical User Interface in a users wallet within the client. First and foremost, these changes modify the wallet behavior to enable “Replace by Fee” for transactions by default. These changes go on to add a “Check Box” that users can enable to opt into Replace by Fee from directly inside their wallet’s transaction generator. This allows users easier access to Replace by Fee for their transactions should they wish to opt in. jonasschnelli experienced some light complications with the implementation of the new check box from an aesthetic angle, noticing that when the client was displayed in certain languages, the graphical user interface appeared too cluttered. Reviewer aesedepece added a comment stating that the replace by Fee functionality should perhaps be moved within the user interface to be next to the fees. He stated that: “My point is that the user will not perceive the transaction being replaced but rather being “upgraded”. That’s why I believe that from an UX point of view, RBF is more related to fees than to a transaction as a whole, and therefore putting the checkbox in the fees frame makes much more sense to me.” The developers performing the review agreed, and after a few final tweaks, merged the Pull Request into the master branch.
MarcoFalke merged 5 commits by jnewbery from “jnewbery:reorganise_qa” into “bitcoin:master”. During the merge, 160 files were changed for a total of 252 additions and 260 deletions. These changes modify the organization of the entire “qa” test system. In a developer discussion taking place on botbot.me, jonasschnelli suggested that the “qa” system be renamed and reorganized. Taking on this task, jnewbery did exactly this, submitting his commits in Pull Request #9956. jnewbery describes the requirements of the new “test” directory to be the following:
– “qa directory should be renamed to come after /src alpabetically, so that git diffs and github PRs show changes to qa tests beneath changes to product code.”
– “rpc-tests should be renamed to something, since they test more than the RPC interface”
– “pull-tester should be renamed to something, since it’s run locally as well as on PRs”
– “bitcoin-util-test should be moved to the qa test directory, since it’s a functional test rather than a unit test.”
These changes perform these specified requirements by renaming the entire “qa” system to “test”, as well as renaming the “rpc-tests directory” to “qa”, as well as renaming “test/pull-tester/rpc-tests.py” to “test/runner/runner.py, as well as renaming the “—enable-extended-rpc-tests” configuration option to “—enable-extended-qa-tests”, and by moving the “bitcoin-util-test.py” test into “test/util” folder. These changes also provided a new structure to the directory of these tests, adding an organization to the newly renamed systems.
MarcoFalke merged 5 commits by ryanofsky from “ryanofsky:pr/bumpfee-fragile” into “bitcoin:master”. During the merge, 1 file was changed for a total of 46 additions and 64 deletions. This changes modify the tests associated with “bumpfee” and “fundrawtransaction”. In a comment left on Pull Request #8456, ryanofsky described some issues he was having with “fundrawtransaction” during “bumpfee” testing. These errors cause a small assortment of issues and failures, and these changes help to correct these behaviors. In one issue, the developer experienced an error where the “fundrawtranscation” would select different inputs than what different subsystems were expecting, causing an error. This issue was resolved by manually creating Replace by Fee transactions with the correct inputs. Another issue arose when the developer noticed that “fundrawtransaction” would use up the correctly sized inputs before any tests could use them. This issue was solved by rewriting the order in which the tests would run, ensuring all tests ran before a “fundrawtransaction” was called.
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