Bitcoin Unlimited Code Changes
gandrewstone merged 4 commits by sickpig from “sickpig:new/bump-boost-1.61” into “BitcoinUnlimited:dev”. During the merge, 11 files were changed for a total of 401 additions and 255 deletions. These changes bring several backports from the Core team, particularly the work of developer fanquake. These changes update the Boost library used by the client, as well as the macros it uses to the latest serials. Boost is an open source software project that provides libraries of support for C++ programming. These libraries enable many different functions and tools within the client development process, including mulit-threading, unit testing, linear algebra for vector mapping, and many others. Macros, in reference to these libraries, are a single instruction line that automatically expands into a set of instructions to perform a certain task. For example, a macro may be written to check a piece of software for certain dependability files. This example is directly correlative to the changes made by this merge, as these changes also provide the dependability files for Boost 1.61, and the specific macros to check for and build upon it.
gandrewstone merged 1 commit by sickpig from “sickpig:new/release-note-1.0.0” into “BitcoinUnlimited:release”. During the merge, 1 file was changed for a total of 649 additions and 0 deletions.These changes see the inclusion of an updated and expanded version of the release notes for version 1.0.0 with a more comprehensively detailed change log of what was accomplished for the teams new client. Similarly to its previous iteration, these notes and logs detail the changes that this new full node release brings to users both new and old. There is more information in this change log than could be comfortably fit into one digestible section of these reports, so readers are highly recommended to read through the post in full at the link above.
gandrewstone merged 1 commit by ptschip from “ptschip:dev_thinblock” into “BitcoinUnlimited:dev”. During the merge 3 files were changed for a total of 97 additions and 156 deletions. These changes were made to move the thin block re-request code out of “main.cpp”, and into it’s own system. Doing so not only provides higher consistency across the client, but also reduces the size of the main system of the client “main.cpp”. The re-request code for thin blocks was also cleaned and optimized during this merge, streamlining the efficiency of the system.
gandrestone merged 2 commits from “gandrewstone:dev” into “BitcoinUnlimited:dev”. During the merge, 6 files were changed for a total of 86 additions and 13 deletions. These changes affect “tweak” commands in the client. A tweak command in the Unlimited client is a command interface that carries out complicated tasks for the user, all while being very easy to adapt and change. These changes see the addition of “Block Size” and “Mining Comment” to the clients tweak commands. The “Mining Comment” tweak includes text into a blocks coinbase, while the “Block Size” tweak outputs the maximum block size in bytes. According to the code, “Block Size” functions by: “The maximum block size returned from ‘getblocktemplate’ will be this value minus ‘mining.coinbaseReserve’.” By utilizing these tweak commands, complicated processes that require several steps and iterations can be accomplished by a single instance instead. These changes also add help with tweak commands to the command line help itself.
Bitcoin Classic Code Changes
zander merged 1 commit by jamoes from “jamoes:disable-wallet” into “bitcoinclassic:master”. During the merge, 1 file was changed for a total of 15 additions and 14 deletions. These changes were made to fix a potential failure associated with the “-disablewallet” system. In jamoes own words: “There was a recent regression that caused an assertion to fail if the “-disablewallet” command-line flag is used. This fixes that regression”. These changes also force the “Debug Window” not to appear when the wallet is disabled. This is due to the fact the Classic client utilizes the main window as the Debug Window when the wallet is disabled.
zander merged 1 commit by jamoes from “jamoes:default-abort” into “bitcoinclassic:master”. During the merge, 1 file was changed for a total of 2 additions and 0 deletions. These changes were made as an optimization to the Graphic User Interface, particularly in the form of a specific pop-up modal window. Previously, if a bitcoin Classic client user were to have their “-txindex” or “-prune” system options changed, a modal window would appear prompting the user to reindex their client with the blockchain. While a reindex could become necessary should something of that nature occur, this modal window was problematic as its default input was set to “OK”. If a user of the client was surprised by this window, or accidentally hit a key as it appeared, the input “OK’ might have been entered, triggering a lengthy and non-cancelable rescan operation. These changes modify this windows behavior, changing “Abort” to its default input guaranteeing no accidental rescan activations, while retaining a users ability to activate a reindex manually at their convenience.
zander committed “Punish nodes relatively for oversize blocks” within 2 files of bitcoinclassic:master for a total of 10 additions and 4 deletions. These changes were made following the mining of block #450,529, and add some parameters for block acceptance to the Classic client. In response to this block, and it’s limit being over the currently accepted protocol, the Classic client moved to implement steps should this ever happen again. These changes add behavior to the client that will activate if / when it receives another block over the current protocol limits. Once a block has been determined to violate the protocol limit, the client will not immediately disconnect unless the size of the block received is more than 100 bytes over the limit. In the case that is under this limit, the client will instead punish the offending node, rather than banning it outright for the slightest infraction. These changes add a buffer for the instant banning functionality for nodes, immediately disconnecting nodes that are receiving blocks of a substantially larger size than the current limits.
Bitcoin XT Code Changes
dgenr8 merged 4 of his own commits from “dgenr8:pick_core_7917” into “bitcoinxt:master”. During the merge, 4 files were changed for a total of 51 additions and 32 deletions. These changes were backports from bitcoin Core, particularly pull request #7917. These backports add the content of Core pull request #7917, namely the optimization of “reindex”. During block validation within the client, the manner in which the blockchain is reindexed is important. These changes optimize this reindexing process by modifying how the index accepts and imports a new block, as well as the how it handles this new block after it has been accepted.
Bitcoin Core Code Changes
iaanwj merged 1 commit by droark from “droark:linearizefix” into “bitcoin:master”. During the merge, 3 files were changed for a total of 41 additions and 18 deletions. These changes all deal with linearization script issues. The first element of these changes modifies the “last-timestamp-encountered” variable, allowing new blockchain files to be written should they be sorted by month. The next element modifies each particular blockchains files, setting their access point, and allowing for their times to be altered if necessary. The last major element of these changes provides a “Debug Output” option to silence certain outputs of scripts should they prove troublesome or unwanted. These changes also updated the read me file for the “linearization” functionality.
iaanwj merged 5 commits by theuni from “theuni:net-version” into “bitcoin:master”. During the merge, 4 files were changed for a total of 102 additions and 111 deletions. These changes also include 1 commit by TheBlueMatt. These changes deal with the network, particularly network assertions. Previously, a commit was merged into the master branch that provided assertions to help prevent against messages being submitted to the network prior to version negotiation completing. However, there were some leftover bugs the pervious commit left behind, and these changes were sought to fix them. The first element of these changes prevents the accidental delivery of a message that had not fully deserialized. The next element of these changes prevents the delivery of a message to any nodes that are not yet fully connected to the network, and should not be sending or receiving messages.
iaanwj merged 5 commits by TheBlueMatt from “TheBlueMatt:2017-01-better-signraw” into “bitcoin:master”. During the merge, 3 files were changed for a total of 36 additions and 4 deletions. These changes are built upon pull request #9634. These changes prevent a potential flaw in the client that became present when attempting to merge signatures from untrusted parties. These changes add a skip functionality to any attempted merging of untrusted signatures to “signrawtransaction” instead of generating an assertion for them.
iaanwj merged 2 of his own commits from “laanwj:2017_02_bdb_location” into “bitcoin:master”. During the merge, 3 files were changed for a total of 70 additions and 60 deletions. These changes were made specifically for for users building with the client upon BSD systems. BSD, or rather Berkeley Software Distribution, is a Unix operating system. These changes set specific environment setting that specify the “CFlags” and “LIBS’ that are to be used with the “BerkeleyDB”. In the developers own words, these flags: “Will completely by-pass autodetection in the same way as other similar flags for pkgconfig”. These changes utilize the previously merged pull request #3921, which specifies the BerkeleyDB location in the code base. These changes also update the build guides for users utilizing BSD software, including details about these new flags.
Some News From The Bitcoin Ecosystem
Gavin Andresen released a short article this week aptly titled the “Definition of bitcoin”. If you are as of yet unaware of the ongoing contention occurring in the bitcoin ecosystem, this article will come across as a no brainer. But for the individuals keeping up with the controversy of the block size debate, this article was, to say the least, divisive. In his writing, Andresen seeks to define the exact nature of what bitcoin is, and how it will evolve. And while this sounds mundane, it draws a very clear line in the sand. One of the larger points of the debate currently being argued over is whether or not a bitcoin blockchain that has undergone a forking would still be considered to document bitcoin post fork. Proponents of small blocks argue that any fork away from the current main chain would produce an altcoin, versus retaining its title of bitcoin. Proponents of big blocks argue the inverse, citing the original Satoshi white paper as proof that bitcoin was intended to scale. Gavin entered the fray, and postulated his opinion quite clearly: ““Bitcoin” is the ledger of not-previously-spent, validly signed transactions contained in the chain of blocks that begins with the genesis block (hash 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f), follows the 21-million coin creation schedule, and has the most cumulative double-SHA256-proof-of-work.” His posting generated no shortage of activity, so much so, that the following day he posted an update post clarifying his definition. The original lead developer of the bitcoin full node client, who was handed the very keys to bitcoin itself by Satoshi Nakamoto, is no stranger to contention of ideas. The coming days will undoubtedly yield no shortage of agreement upon, and disagreement thereof, his ideals.
Bitcoin Classic release manager Tom Zander made a post this week calling for miners to ultimately select a scaling solution, and help bring the scaling debate itself to a close. He postulates: “We are currently at the limit of transactions per second that the protocol can handle in its current state, even though the hardware is capable of handling more, the current protocol won’t allow it. This means no more new users can make use of the network. Which is bad for adoption. We are nowhere near the limits of adoption, and to smother it in the current stage would kill demand for bitcoin in the long run, forcing old and new bitcoin users alike away to altcoins, whether they like it or not.” Following this logic, he goes on to stress the relief of this network congestion: “It is therefore important that a scaling solution is agreed upon as quickly as possible so that adoption can proceed at a natural pace without artificial limitations due to neglect.” He proceeds to outline why the miners of the bitcoin ecosystem are incredibly important to its success, and steps they should take moving forward. Listing the two main contending full node software clients as bitcoin Core, (offering Segregated witness as its scaling fix), and bitcoin Unlimited, (offering Emergent Consensus as its scaling fix), Tom urges miners to select one. He says: “Please make sure to make a choice by joining a pool that supports either Core or BU and possibly running a full node supporting SegWit or BU.”
The scaling debate is underway, 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 are as follows:
– 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, Increase Block Size to 2mb)
– 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 to the author of these reports at dasbitcoin.com.