Bitcoin Code Report – December 10, 2016

Bitcoin Unlimited Code Changes

—-gandrewstone submitted 6 change files with 81 additions and 59 removals regarding "resolve additional CCriticalSection destruction dependencies". These changes resolve issues that appeared in "CCriticalSection".

--nomnombtc Committed 1 change to "Fix typo in build-unix.md " with 4 additions and 4 removals. These changes replaced the word "Core" with "Unlimited" in an example, fixed some minor typos, and added the environment variable " $pwd " to the configure prefix.

---ftrader Submitted 1 change file about "Add unique extension option to rpc-tests.py to run unique extension tests", total 6 additions and 3 removals. These changes ensure that "rpc-tets.py" will run unique extension tests when " runtests " is entered.

Bitcoin Classic Code Changes

—zander submitted 1 change file with 2 additions and 2 removals regarding "Better error messages". These changes affect " fTestNet " and " fRegTest " by replacing the old error messages with more concise and precise output when errors occur.

—-zander submitted 24 change files regarding "Implementing market-based equilibrium blocksize", with 89 additions and 945 removals. These changes remove BIP109, the 2MB blocksize that was submitted to Core, and replace it with "dynamic blocksizing based on market equilibrium". Zander described this as: "We removed the maximum block limit from the consensus rules. Introduced a command line parameter that defines the maximum block size it will accept from other nodes." This allows Bitcoin Classic to be compatible with Bitcoin Unlimited, while still allowing miners to set the block size they create using "-blockmaxsize" and limit the block size they will accept using "-blocksizeacceptlimit".

Bitcoin XT Code Changes

–dgenr8 Merged 1 commit " dagurval:cachebump " into " bitcoinxt:master ". During the merge, 2 files were changed, with a total of 13 additions and 5 removals. These changes are mostly code optimizations, except for one rewritten section about " nMaxBlockDBAndTxIndexCache "

Bitcoin Core code changes

– sipa Merged two commits “ gmaxwell:node_is_this_i_dont_even ” into “ bitcoin:master ”. During the merge, 3 files were changed, totaling 3 additions and 22 deletions. These changes removed a portion of the code for the “ Pub Sub Mechanism ” that existed in the original Bitcoin code. This “ Pub Sub Mechanism ” was deprecated in Merge #1036. Subsequent code removed by gmaxwell was used to support this system which could not be ignored.

- iaanwj Committed 1 change file with 1 addition and 1 removal regarding " torcontrol : explicitly request RSA1024 private keys". This change forces all newly generated private keys to be in RSA1024 format. The current bitcoin p2p protocol does not support ed25519 keys, so explicitly requesting RSA1024 keys is important.

- iaanwj Submitted 1 change file on "doc: Improve Windows build instructions with Linux Subsystem" with 46 additions and 20 changes. These changes are to help make the build instructions for Windows Subsystem for Linux more user friendly. This is primarily done by placing 64-bit instructions first, and removing double spacing, as well as providing suggestions and tips for build users.

- paveljanik committed 1 change file with 2 additions and 0 removals regarding "About Responsible Reporting of Security Issues". These additions to " .github / ISSUE_TEMPLATE.md " are intended to provide clear information to users so that they can best submit their issues to Bitcoin Core.

Some news from the Bitcoin ecosystem

Bitcoin Classic announced in the subreddit r/btc that “Bitcoin Classic is back!” The Bitcoin Classic team has been hard at work over the past year updating and improving their client, and one of their most recent projects includes updating Bitcoin’s transaction format. This new classic format is called “Transaction Version 4,” more commonly known as “Flexible Transactions.”

Using the acronym Flex Transaction is one of several ways to think about this transaction format. Deadalnix was kind enough to provide us with a way to think of Flex Transaction as a simplified transaction format:

"There is a fundamental problem with the current transaction format. Each transaction is hashed to verify the signature, but the signature is inside the transaction data structure. Therefore, there is a very complex process to remove signatures, hashes, symbols, etc. from within the transaction. In addition to unnecessary complexity, this causes two problems. The first problem is that you have to re-hash the entire transaction for each signature. This creates what is called the "quadratic hashing problem". In simple terms, large transactions are very expensive to verify. The second problem is transaction malleability. By changing the signature, you can change the transaction ID, and then no code can trust the transaction ID. This causes a lot of problems for SPV security. It is also a technical problem that the Lightning Network needs to face. To solve both problems, you want to remove signatures so that they are not used to calculate the transaction ID and are not part of the hashed data used to verify the signature. Both Segregated Witness and Elastic Transactions can do this. This, but Flex Transaction is coming as a hard fork, while Segregated Witness is coming as a soft fork. When you reconcile transactions via a hard fork, you create a new transaction format that doesn't cause these problems. However, as a soft fork, you need to make old nodes consider the transaction valid. So the way Segregated Witness works is that segregated transactions are in the old format, and anyone can send old transactions to old nodes in the old format. So you end up with segregated unspent transaction outputs and non-segregated unspent transaction outputs, with all the problems that come with it. On the one hand, Flex Transaction introduces a new transaction format. Old nodes can't understand this format, so when Flex Transaction is activated, all nodes need to be updated. On the other hand, Flex Transaction uses compatible unspent transaction outputs, so the old transaction format is gradually phased out over time. These problems will be solved once and for all."

Bitcoin Unlimited lead developer Andrew Stone kindly agreed to answer a few questions this week regarding Bitcoin Unlimited’s latest code changes and plans for the software. The questions were:

Q: You recently made a commit about GitHub's handling of destruction dependencies. Would you like to briefly elaborate on the purpose of this change?

A: We have an ongoing project to make Bitcoin Unlimited very stable. All Satoshi clients had some bugs with construction and deconstruction. The first was that certain global variables were dependent on each other, but their deconstruction order was not guaranteed. By moving the global variables to a single folder, we can effectively control the deconstruction order. Another issue was not allowing clients to run deadlock detection for a long time - you would get false positive detections because the CCriticalSection objects were removed from the detection when they were deconstructed. All of these issues have been fixed in Bitcoin Unlimited.

Q: Can you tell us more about any BU projects you are currently working on? Are there any exciting developments you think the public should know about?

A: We are working on a new version! The last feature of the new version is to add an "emergent consensus" type parameter to prevent extremely expensive transactions! (Translator's note: This paragraph means that Bitcoin Unlimited will introduce BUIP041 to prevent a small number of computing forces from launching large block attacks.)

The Bitcoin Unlimited team will release more information about their new release soon.