Merge pull request dashpay#1804 from codablock/pr_backport_bitcoin_0.13-4

Backport missing PRs from Bitcoin 0.13 - Part 4

Author: UdjinM6

.travis.yml

@@ -49,20 +49,20 @@ env:
 # No wallet
     - HOST=x86_64-unknown-linux-gnu PPA="ppa:bitcoin/bitcoin" PACKAGES="python3" DEP_OPTS="NO_WALLET=1" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-glibc-back-compat --enable-reduce-exports"
 # Cross-Mac
-    - HOST=x86_64-apple-darwin11 PPA="ppa:bitcoin/bitcoin" PACKAGES="cmake imagemagick libcap-dev librsvg2-bin libz-dev libbz2-dev libtiff-tools python-dev" BITCOIN_CONFIG="--enable-gui --enable-reduce-exports" OSX_SDK=10.9 GOAL="deploy"
+    - HOST=x86_64-apple-darwin11 PPA="ppa:bitcoin/bitcoin" PACKAGES="cmake imagemagick libcap-dev librsvg2-bin libz-dev libbz2-dev libtiff-tools python3-dev" BITCOIN_CONFIG="--enable-gui --enable-reduce-exports" OSX_SDK=10.9 GOAL="deploy"
 
 before_install:
     - git clone https://github.com/dashpay/dash_hash
-    - travis_retry sudo apt-get install python-dev
+    - travis_retry sudo apt-get install python3-pip python3-dev
     - travis_retry sudo add-apt-repository ppa:ubuntu-wine/ppa -y
     - export PATH=$(echo $PATH | tr ':' "\n" | sed '/\/opt\/python/d' | tr "\n" ":" | sed "s|::|:|g")
 install:
-    - if [ "$PYZMQ" = "true" ]; then pip install pyzmq --user ; fi
+    - if [ "$PYZMQ" = "true" ]; then pip3 install pyzmq --user ; fi
     - if [ -n "$PPA" ]; then travis_retry sudo add-apt-repository "$PPA" -y; fi
     - if [ -n "$DPKG_ADD_ARCH" ]; then sudo dpkg --add-architecture "$DPKG_ADD_ARCH" ; fi
     - if [ -n "$PACKAGES" ]; then travis_retry sudo apt-get update; fi
     - if [ -n "$PACKAGES" ]; then travis_retry sudo apt-get install --no-install-recommends --no-upgrade -qq $PACKAGES; fi
-    - cd dash_hash && python setup.py install --user && cd ..
+    - cd dash_hash && python3 setup.py install --user && cd ..
 before_script:
     - unset CC; unset CXX
     - unset DISPLAY

CONTRIBUTING.md

@@ -17,13 +17,13 @@ To contribute a patch, the workflow is as follows:
   - Create topic branch
   - Commit patches
 
-The project coding conventions in [doc/developer-notes.md](doc/developer-notes.md) must be adhered to.
+The project coding conventions in the [developer notes](doc/developer-notes.md) must be adhered to.
 
 In general [commits should be atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention) and diffs should be easy to read. For this reason do not mix any formatting fixes or code moves with actual code changes.
 
 Commit messages should be verbose by default consisting of a short subject line (50 chars max), a blank line and detailed explanatory text as separate paragraph(s); unless the title alone is self-explanatory (like "Corrected typo in main.cpp") then a single title line is sufficient. Commit messages should be helpful to people reading your code in the future, so explain the reasoning for your decisions. Further explanation [here](http://chris.beams.io/posts/git-commit/).
 
-If a particular commit references another issue, please add the reference, for example "refs #1234", or "fixes #4321". Using "fixes or closes" keywords will cause the corresponding issue to be closed when the pull request is merged.
+If a particular commit references another issue, please add the reference, for example `refs #1234`, or `fixes #4321`. Using the `fixes` or `closes` keywords will cause the corresponding issue to be closed when the pull request is merged.
 
 Please refer to the [Git manual](https://git-scm.com/doc) for more information about Git.
 
@@ -35,13 +35,27 @@ The title of the pull request should be prefixed by the component or area that t
     Consensus: Add new opcode for BIP-XXXX OP_CHECKAWESOMESIG
     Net: Automatically create hidden service, listen on Tor
     Qt: Add feed bump button
-    Trivial: fix typo
+    Trivial: Fix typo in main.cpp
 
-If a pull request is specifically not to be considered for merging (yet) please prefix the title with [WIP] or use [Tasks Lists](https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments) in the body of the pull request to indicate tasks are pending.
+If a pull request is specifically not to be considered for merging (yet) please prefix the title with [WIP] or use [Tasks Lists](https://help.github.com/articles/basic-writing-and-formatting-syntax/#task-lists) in the body of the pull request to indicate tasks are pending.
 
 The body of the pull request should contain enough description about what the patch does together with any justification/reasoning. You should include references to any discussions (for example other tickets or mailing list discussions).
 
-At this stage one should expect comments and review from other contributors. You can add more commits to your pull request by committing them locally and pushing to your fork until you have satisfied all feedback. If your pull request is accepted for merging, you may be asked by a maintainer to squash and or rebase your commits before it will be merged. The length of time required for peer review is unpredictable and will vary from patch to patch.
+At this stage one should expect comments and review from other contributors. You can add more commits to your pull request by committing them locally and pushing to your fork until you have satisfied all feedback.
+
+Squashing Commits
+---------------------------
+If your pull request is accepted for merging, you may be asked by a maintainer to squash and or [rebase](https://git-scm.com/docs/git-rebase) your commits before it will be merged. The basic squashing workflow is shown below.
+
+    git checkout your_branch_name
+    git rebase -i HEAD~n
+    # n is normally the number of commits in the pull
+    # set commits from 'pick' to 'squash', save and quit
+    # on the next screen, edit/refine commit messages
+    # save and quit
+    git push -f # (force push to GitHub)
+
+The length of time required for peer review is unpredictable and will vary from pull request to pull request.
 
 
 Pull Request Philosophy
@@ -61,7 +75,7 @@ Refactoring is a necessary part of any software project's evolution. The followi
 
 There are three categories of refactoring, code only moves, code style fixes, code refactoring. In general refactoring pull requests should not mix these three kinds of activity in order to make refactoring pull requests easy to review and uncontroversial. In all cases, refactoring PRs must not change the behaviour of code within the pull request (bugs must be preserved as is).
 
-Project maintainers aim for a quick turnaround on refactoring pull requests, so where possible keep them short, uncomplex and easy to verify. 
+Project maintainers aim for a quick turnaround on refactoring pull requests, so where possible keep them short, uncomplex and easy to verify.
 
 
 "Decision Making" Process

README.md

@@ -52,8 +52,7 @@ There are also [regression and integration tests](/qa) of the RPC interface, wri
 in Python, that are run automatically on the build server.
 These tests can be run (if the [test dependencies](/qa) are installed) with: `qa/pull-tester/rpc-tests.py`
 
-The Travis CI system makes sure that every pull request is built for Windows
-and Linux, OS X, and that unit and sanity tests are automatically run.
+The Travis CI system makes sure that every pull request is built for Windows, Linux, and OS X, and that unit/sanity tests are run automatically.
 
 ### Manual Quality Assurance (QA) Testing
 

doc/README.md

@@ -55,6 +55,7 @@ The Dash Core repo's [root README](/README.md) contains relevant information on
 - [Shared Libraries](shared-libraries.md)
 - [BIPS](bips.md)
 - [Dnsseed Policy](dnsseed-policy.md)
+- [Benchmarking](benchmarking.md)
 
 ### Resources
 * Discuss on the [DashTalk](https://dashtalk.org/) forums, in the Development & Technical Discussion board.

doc/benchmarking.md

@@ -0,0 +1,30 @@
+Benchmarking
+============
+
+Dash Core has an internal benchmarking framework, with benchmarks
+for cryptographic algorithms such as SHA1, SHA256, SHA512 and RIPEMD160. As well as the rolling bloom filter.
+
+After compiling dash-core, the benchmarks can be run with:
+`src/bench/bench_dash`
+
+The output will look similar to:
+```
+#Benchmark,count,min,max,average
+RIPEMD160,448,0.001245033173334,0.002638196945190,0.002461894814457
+RollingBloom-refresh,1,0.000635000000000,0.000635000000000,0.000635000000000
+RollingBloom-refresh,1,0.000108000000000,0.000108000000000,0.000108000000000
+RollingBloom-refresh,1,0.000107000000000,0.000107000000000,0.000107000000000
+RollingBloom-refresh,1,0.000204000000000,0.000204000000000,0.000204000000000
+SHA1,640,0.000909024336207,0.001938136418660,0.001843086257577
+SHA256,256,0.002209486499909,0.008500099182129,0.004300644621253
+SHA512,384,0.001319904176016,0.002813005447388,0.002615700786312
+Sleep100ms,10,0.205592155456543,0.210056066513062,0.104166316986084
+Trig,67108864,0.000000014997003,0.000000015448112,0.000000015188842
+```
+
+More benchmarks are needed for, in no particular order:
+- Script Validation
+- CCoinDBView caching
+- Coins database
+- Memory pool
+- Wallet coin selection

doc/build-unix.md

@@ -128,15 +128,15 @@ Dependency Build Instructions: Fedora
 -------------------------------------
 Build requirements:
 
-    sudo dnf install libtool make autoconf automake openssl-devel libevent-devel boost-devel libdb4-devel libdb4-cxx-devel
+    sudo dnf install gcc-c++ libtool make autoconf automake openssl-devel libevent-devel boost-devel libdb4-devel libdb4-cxx-devel
 
 Optional:
 
     sudo dnf install miniupnpc-devel
 
 To build with Qt 5 (recommended) you need the following:
 
-    sudo dnf install qt5-qttools-devel qtr5-qtbase-devel protobuf-devel
+    sudo dnf install qt5-qttools-devel qt5-qtbase-devel protobuf-devel
 
 libqrencode (optional) can be installed with:
 

doc/developer-notes.md

@@ -5,7 +5,9 @@ Various coding styles have been used during the history of the codebase,
 and the result is not very consistent. However, we're now trying to converge to
 a single style, so please use it in new code. Old code will be converted
 gradually.
-- Basic rules specified in src/.clang-format. Use a recent clang-format-3.5 to format automatically.
+- Basic rules specified in [src/.clang-format](/src/.clang-format).
+  Use a recent clang-format to format automatically using one of the [dev scripts]
+  (/contrib/devtools/README.md#clang-formatpy).
   - Braces on new lines for namespaces, classes, functions, methods.
   - Braces on the same line for everything else.
   - 4 space indentation (no tabs) for every block except namespaces.

doc/gitian-building.md

@@ -452,8 +452,8 @@ Then when building, override the remote URLs that gbuild would otherwise pull fr
 cd /some/root/path/
 git clone https://github.com/dashpay/dash-detached-sigs.git
 
-BTCPATH=/some/root/path/dash.git
-SIGPATH=/some/root/path/dash-detached-sigs.git
+BTCPATH=/some/root/path/dash
+SIGPATH=/some/root/path/dash-detached-sigs
 
 ./bin/gbuild --url dash=${BTCPATH},signature=${SIGPATH} ../dash/contrib/gitian-descriptors/gitian-win-signer.yml
 ```

doc/zmq.md

@@ -38,7 +38,7 @@ newer. Typically, it is packaged by distributions as something like
 *libzmq3-dev*. The C++ wrapper for ZeroMQ is *not* needed.
 
 In order to run the example Python client scripts in contrib/ one must
-also install *python-zmq*, though this is not necessary for daemon
+also install *python3-zmq*, though this is not necessary for daemon
 operation.
 
 ## Enabling

qa/README.md

@@ -11,23 +11,36 @@ Before running the tests, the following must be installed.
 
 Unix
 ----
-The python-zmq library is required. On Ubuntu or Debian it can be installed via: 
+The python3-zmq library is required. On Ubuntu or Debian it can be installed via:
 ```
-sudo apt-get install python-zmq
+sudo apt-get install python3-zmq
 ```
 
 Running tests
 =============
 
-You can run any single test by calling `qa/pull-tester/rpc-tests.py <testname>`.
+You can run any single test by calling
 
-Or you can run any combination of tests by calling `qa/pull-tester/rpc-tests.py <testname1> <testname2> <testname3> ...`
+    qa/pull-tester/rpc-tests.py <testname>
 
-Run the regression test suite with `qa/pull-tester/rpc-tests.py`
+Or you can run any combination of tests by calling
 
-Run all possible tests with `qa/pull-tester/rpc-tests.py -extended`
+    qa/pull-tester/rpc-tests.py <testname1> <testname2> <testname3> ...
 
-Possible options:
+Run the regression test suite with
+
+    qa/pull-tester/rpc-tests.py
+
+Run all possible tests with
+
+    qa/pull-tester/rpc-tests.py -extended
+
+By default, tests will be run in parallel if you want to specify how many
+tests should be run in parallel, append `-paralell=n` (default n=4).
+
+If you want to create a basic coverage report for the rpc test suite, append `--coverage`.
+
+Possible options, which apply to each individual test run:
 
 ```
   -h, --help            show this help message and exit