Is Bitcoin's 2MB fork just a matter of changing one line of code?

Increasing the Bitcoin block size limit from 1 megabyte (1MB) to 2 megabytes (2MB) may sound simple at first: just change the number “1” to “2” in the source code, and we’re done, right?

If we don't care about smooth upgrades, it might be as simple as changing the following line of code (in src/consensus/consensus.h):

 ... MAX_BLOCK_SIZE=1000000

To:

 ... MAX_BLOCK_SIZE=2000000

If you make your changes and recompile and then run Bitcoin Core, it will work. Your computer will download the entire blockchain and will interoperate with other computers on the network without any problems.

If your computer is assembling transactions into blocks (if you are mining solo, or if you are a mining pool operator), then things get more complicated. I will explain the complexity in the rest of this article, and hopefully you will understand the problem and ensure that changes to the consensus layer are safe.

There is a handy feature on Github that allows you to compare code side-by-side; you can visit https://github.com/bitcoin/bitcoin/compare/v0.11.2…gavinandresen:two_mb_bump to see the code changes for the 2MB fork. You should see something like this:

There are five “commits” (groups of code changes) that implement the block size increase. Please ignore the first one, David Harding’s commit, which is the last commit of Bitcoin Core 0.11.2).

There were changes to 22 files, about 900 lines of new code, of which more than half (500 lines) were new tests to ensure that the new code worked properly.

The first commit is "Minimal consensus/miner changes for 2mb block size bump" and has 20 new lines of code. You can see that one of the changes is MAX_BLOCK_SIZE going from 1,000,000 bytes to 2,000,000 bytes; the rest of the changes are needed for miners to see if it's safe to produce larger blocks. A new MaxBlockSize() method is defined that returns the old or new maximum block size, based on the timestamp in the 80-byte block header. I could probably write a whole blog post explaining why timestamps are used instead of block height or the median time of the last 11 blocks or something else... but not today.

The consensus change is in line 2816 of main.cpp, using the CheckBlock() method and the new MaxBlockSize() method to determine if a block is too large, instead of MAX_BLOCK_SIZE. A similar change was made to the CreateNewBlock() function in miner.cpp, and the 'getblocktemplate' RPC, so that miners can create larger blocks.

The next commit (“Testing infrastructure fixes”) added some functionality and fixed a vulnerability in the code used to test the Bitcoin source code.

There are two levels of code-testing-code; unit tests are put into the tree in src/test/, which are written in C++, and are very low level, and are used to ensure that the behavior of each part of the code is correct. There are also regression tests in the tree in qa/rpc-tests/. They are written in Python and use the RPC (Remote Procedure Call) interface command line run "-regtest mode" to ensure that everything is working properly.

“Two megabyte fork after miner vote and grace period” is the largest commit so far, with about 700 lines of new code. It implements the roll-out rule: when 75% of the hashrate produces blocks with a special bit in the block version number, and then 28 days have passed, larger blocks are allowed to be produced.

75% and 28天are pretty arbitrary choices. I hate arbitrary choices, mainly because everyone will have a different opinion about them (also known as "bikeshedding", which means being too concerned with details and marginal issues and ignoring the main issues), and spend days arguing about a fruitless issue. I have explained in another blog post why we think these numbers are good choices.

The miner voting and grace period code is derived from the BIP 101 implementation I wrote for Bitcoin XT, which has been tested at three levels.

There is a new unit test in block_size_tests.cpp. It tests the CheckBlock() call, creating blocks that are exactly the old or new size limit, or 1 byte larger than the old or new block size limit, and testing whether they are accepted based on whether their timestamp is before or after (or exactly) the time when larger blocks are allowed.

There is also a new regression test, bigblocks.py . It runs four copies of bitcoind, creates a blockchain just for testing on a developer's machine (in -regtest mode, blocks are created instantly), and then tests the fork activation code, making sure miner votes are counted correctly, that the restructuring of the blockchain is handled properly, and that larger blocks are allowed after the transition period is over. This also ensures that if 75% of the hashrate does not accept the change by the January 2018 deadline, the entire code is reported as broken.

Most of my development time is spent making sure regression tests and unit tests are in place. Then, once regression and unit tests are passing, more testing is done on the test network. Writing the code is the easy part.

Finally, this part of the rollout code was verified by Jonathan Toomim, who has performed extensive testing on 8MB blocks and the Bitcoin XT test network (including China's Great Firewall).

Let’s continue exploring the code changes…

There are also some changes in the IsSuperMajority() function in main.cpp, and a new VersionKnown() function in block.h, which are functions used to count the number of blocks that support various changes. When the block size is increased, it can happen at the same time as the "version bits" of BIP 009 and various soft fork BIPs (68, 112, 113, 141).

The most new code (besides tests) is in txdb.cpp . When a miner votes successfully, the hash of the triggering block is written to the blockchain index. This is not strictly required, but this part of the code scans all the block headers in the blockchain to figure out if the vote was successful at each start. It is more efficient than storing part of the information in the blockchain index database.

Alas, describing all of these possible code changes would take much longer than writing the code. There are still 2 commits to talk about.

"Accurate sigop/sighash accounting and limits" is important because without it, increasing the block size limit could be dangerous. You can see some of the details in my presentation at the DevCore conference last November, but basically, Satoshi didn't think very carefully about how transactions were signed, and that could lead to Bitcoin creating very large transactions that were too expensive to verify. This commit cleans up some of that "technical debt", implements a new ValidationCostTracker that tracks how much work went into validating a transaction, and then uses that along with a new limit (MAX_BLOCK_SIGHASH) to ensure that no one can create a very expensive-to-validate block in an attempt to mess up the network.

There is a strong incentive not to create expensive blocks to validate (miners want their blocks to get through the network as quickly as possible, and work hard to minimize their orphan rate). However, one of the principles of secure coding is "belt and braces" (if you want to sound professional or don't like braces, use the term "defense in depth" instead).

MAX_BLOCK_SIGHASH is another annoying, arbitrary limit. It is set to 1.3 GB , which is large enough that no block currently hits it, but small enough that it is possible to create poison blocks that take minutes to verify.

The last commit, “Do not relay or mine excessive sighash transactions”, is another “belt and braces” type of security measure. There are already limits in place that will reject very large, expensive-to-verify transactions, but this commit adds another check to absolutely ensure that a clever attacker can’t trick miners into putting insanely expensive transactions in their blocks.

If you can stick with this stuff, you have a longer attention span than I do. As non-programmers reading this, I hope you can learn from it what you need to pay attention to in order to go from "1" to "2".

Original article: http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
By GAVIN ANDRESEN
Translator: Satuoxi
Source (translation): Babbitt Information (http://www.8btc.com/guided-tour-of-the-2mb-fork ‎)