Merge pull request #24 from absolute-community/v12.2.5PR13.4

V12.2.5 PR13.4

Author: CryptoCentric

.travis.yml

@@ -49,10 +49,11 @@ 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:
-    - 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")
     - chmod +rwx -R depends/
@@ -62,7 +63,7 @@ before_install:
     - chmod +rwx -R contrib/
     - chmod +rwx autogen.sh
 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

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 validation.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

Makefile.am

@@ -28,7 +28,7 @@ OSX_DSSTORE_GEN=$(top_srcdir)/contrib/macdeploy/custom_dsstore.py
 OSX_DEPLOY_SCRIPT=$(top_srcdir)/contrib/macdeploy/macdeployqtplus
 OSX_FANCY_PLIST=$(top_srcdir)/contrib/macdeploy/fancy.plist
 OSX_INSTALLER_ICONS=$(top_srcdir)/src/qt/res/icons/bitcoin.icns
-OSX_PLIST=$(top_builddir)/share/qt/Info.plist #not installed
+OSX_PLIST=$(top_srcdir)/share/qt/Info.plist #not installed
 OSX_QT_TRANSLATIONS = da,de,es,hu,ru,uk,zh_CN,zh_TW
 
 DIST_DOCS = $(wildcard doc/*.md) $(wildcard doc/release-notes/*.md)
@@ -53,7 +53,16 @@ COVERAGE_INFO = baseline_filtered_combined.info baseline.info block_test.info \
   leveldb_baseline_filtered.info test_absolute_coverage.info test_absolute.info
 
 dist-hook:
+	-$(MAKE) -C $(top_distdir)/src/leveldb clean
+	-$(MAKE) -C $(top_distdir)/src/secp256k1 distclean
 	-$(GIT) archive --format=tar HEAD -- src/clientversion.cpp | $(AMTAR) -C $(top_distdir) -xf -
+distcheck-hook:
+	$(MKDIR_P) $(top_distdir)/_build/src/leveldb
+	cp -rf $(top_srcdir)/src/leveldb/* $(top_distdir)/_build/src/leveldb/
+	-$(MAKE) -C $(top_distdir)/_build/src/leveldb clean
+
+distcleancheck:
+	@:
 
 $(BITCOIN_WIN_INSTALLER): all-recursive
 	$(MKDIR_P) $(top_builddir)/release

README.md

@@ -30,4 +30,51 @@ Absolute Coin gives you the access to the wide range of options created by two-t
 
 For building please see INSTALL / proper files in the doc subfolder.
 
-For more information please visit http://www.absolutecoin.net
+Development Process
+-------------------
+
+The `master` branch is meant to be stable. Development is normally done in separate branches.
+[Tags](https://github.com/absolute-community/absolute/tags) are created to indicate new official,
+stable release versions of Dash Core.
+
+The contribution workflow is described in [CONTRIBUTING.md](CONTRIBUTING.md).
+
+Testing
+-------
+
+Testing and code review is the bottleneck for development; we get more pull
+requests than we can review and test on short notice. Please be patient and help out by testing
+other people's pull requests, and remember this is a security-critical project where any mistake might cost people
+lots of money.
+
+### Automated Testing
+
+Developers are strongly encouraged to write [unit tests](/doc/unit-tests.md) for new code, and to
+submit new unit tests for old code. Unit tests can be compiled and run
+(assuming they weren't disabled in configure) with: `make check`
+
+There are also [regression and integration tests](/qa) of the RPC interface, written
+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, Linux, and OS X, and that unit/sanity tests are run automatically.
+
+### Manual Quality Assurance (QA) Testing
+
+Changes should be tested by somebody other than the developer who wrote the
+code. This is especially important for large or high-risk changes. It is useful
+to add a test plan to the pull request description if testing the changes is
+not straightforward.
+
+Translations
+------------
+
+Changes to translations as well as new translations can be submitted to
+[Absolute Core's Transifex page](https://www.transifex.com/projects/p/absolute/).
+
+Translations are periodically pulled from Transifex and merged into the git repository. See the
+[translation process](doc/translation_process.md) for details on how this works.
+
+**Important**: We do not accept translation changes as GitHub pull requests because the next
+pull from Transifex would automatically overwrite them again.
+

contrib/gitian-descriptors/README.md

@@ -19,8 +19,8 @@ Sanity checks:
 
 Once you've got the right hardware and software:
 
-    git clone git://github.com/absolute-community/absolute/issues
-    git clone git://github.com/devrandom/gitian-builder.git
+    git clone git://github.com/absolute-community/absolute
+    git clone git://github.com/devrandom/gitian-builder
     mkdir gitian-builder/inputs
     cd gitian-builder/inputs
 

contrib/spendfrom/README.md

@@ -16,7 +16,7 @@ With arguments, sends coins received by the `FROMADDRESS` addresses to the `TOAD
 ### Notes ###
 
 - You may explicitly specify how much fee to pay (a fee more than 1% of the amount
-will fail, though, to prevent ABS-losing accidents). Spendfrom may fail if
+will fail,  though, to prevent absolute-losing accidents). Spendfrom may fail if
 it thinks the transaction would never be confirmed (if the amount being sent is
 too small, or if the transaction is too many bytes for the fee).
 

doc/README.md

@@ -53,6 +53,10 @@ The Absolute Core repo's [root README](/README.md) contains relevant information
 - [Shared Libraries](shared-libraries.md)
 - [BIPS](bips.md)
 - [Dnsseed Policy](dnsseed-policy.md)
+- [Benchmarking](benchmarking.md)
+
+### Resources
+* Discuss on the Absolute Discord Server if advice is needed 
 
 ### Miscellaneous
 - [Assets Attribution](assets-attribution.md)

doc/benchmarking.md

@@ -0,0 +1,30 @@
+Benchmarking
+============
+
+Absolute 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 absolute-core, the benchmarks can be run with:
+`src/bench/bench_absolute`
+
+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/build-unix.md

@@ -126,15 +126,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

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

doc/guide-startmany.md

@@ -8,17 +8,17 @@
 2. Click the Receive tab.
 3. Fill in the form to request a payment.
     * Label: mn01
-    * Amount: 1000 (optional)
+    * Amount: 2500 (optional)
     * Click *Request payment* button
 5. Click the *Copy Address* button
 
 Create a new wallet address for each Masternode.
 
 Close your QT Wallet.
 
-### Send 1000 ABS to New Addresses
+### Send 2500 ABS to New Addresses
 
-Send exactly 1000 ABS to each new address created above.
+Send exactly 2500 ABS to each new address created above.
 
 ### Create New Masternode Private Keys
 
@@ -64,8 +64,8 @@ alias ipaddress:port masternode_private_key collateral_output collateral_output_
 Example:
 
 ```
-mn01 127.0.0.1:8800 93HaYBVUCYjEMeeH1Y4sBGLALQZE1Yc1K64xiqgX37tGBDQL8Xg 2bcd3c84c84f87eaa86e4e56834c92927a07f9e18718810b92e0d0324456a67c 0
-mn02 127.0.0.2:8800 93WaAb3htPJEV8E9aQcN23Jt97bPex7YvWfgMDTUdWJvzmrMqey aa9f1034d973377a5e733272c3d0eced1de22555ad45d6b24abadff8087948d4 0
+mn01 127.0.0.1:18888 4gsWMR8PUAZdJ5Umhr4CXrEAQydBGmq3UJ7YR7NwewADRoeudrg 2bcd3c84c84f87eaa86e4e56834c92927a07f9e18718810b92e0d0324456a67c 0
+mn02 127.0.0.2:18888 4hpnZ6zkx8mNEb5ga47MunVdthS5XhG6Jd5C5YaCvsWEh6eFqdM aa9f1034d973377a5e733272c3d0eced1de22555ad45d6b24abadff8087948d4 0
 ```
 
 ## Update absolute.conf on server
@@ -74,7 +74,7 @@ If you generated a new masternode private key, you will need to update the remot
 
 Shut down the daemon and then edit the file.
 
-```vim .absolutecore/absolute.conf```
+```nano .absolutecore/absolute.conf```
 
 ### Edit the masternodeprivkey
 If you generated a new masternode private key, you will need to update the `masternodeprivkey` value in your remote `absolute.conf` file.
@@ -120,7 +120,7 @@ absolute-cli masternode status
 {
     "outpoint" : "<collateral_output>-<collateral_output_index>",
     "service" : "<ipaddress>:<port>",
-    "pubkey" : "<1000 ABS address>",
+    "pubkey" : "<2500 ABS address>",
     "status" : "Masternode successfully started"
 }
 ```

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