Backports and updates for v15

.gitignore

@@ -11,6 +11,7 @@ src/dashd
 src/dash-cli
 src/dash-tx
 src/test/test_dash
+src/test/test_dash_fuzzy
 src/qt/test/test_dash-qt
 src/bench/bench_dash
 
@@ -88,7 +89,6 @@ Dash-Qt.app
 # Unit-tests
 Makefile.test
 dash-qt_test
-src/test/buildenv.py
 
 # Resources cpp
 qrc_*.cpp
@@ -109,9 +109,8 @@ coverage_percent.txt
 linux-coverage-build
 linux-build
 win32-build
-qa/pull-tester/tests_config.py
-qa/pull-tester/tests_config.ini
-qa/cache/*
+test/config.ini
+test/cache/*
 
 !src/leveldb*/Makefile
 

.gitlab-ci.yml

@@ -0,0 +1,159 @@
+image: "ubuntu:bionic"
+
+variables:
+  DOCKER_DRIVER: overlay2
+
+cache:
+  # Cache by branch/tag and job name
+  # Gitlab can't use caches from parent pipelines when doing the first build in a PR, so we use artifacts to copy
+  # caches into PRs
+  key: ${CI_COMMIT_REF_SLUG}-${CI_JOB_NAME}${CI_EXTERNAL_PULL_REQUEST_IID}
+  paths:
+    - $CI_PROJECT_DIR/cache
+
+stages:
+  - build
+
+.build_template: &build_template
+  stage: build
+  before_script:
+    - export BUILD_TARGET="$CI_JOB_NAME"
+    - echo BUILD_TARGET=$BUILD_TARGET
+    - source ./ci/matrix.sh
+
+    # The ubuntu base image has apt configured to delete caches after each invocation, which is something that is not desirable for us
+    - rm /etc/apt/apt.conf.d/docker-clean
+    - apt-get update
+    - apt-get install -y wget unzip
+
+    # Init cache
+    - export CACHE_DIR=$CI_PROJECT_DIR/cache
+    - mkdir -p $CACHE_DIR
+    - |
+      if [ "$CI_COMMIT_REF_SLUG" != "develop" -a "$CI_COMMIT_TAG" == "" ]; then
+        if [ ! -d $CACHE_DIR/ccache ]; then
+          echo "Downloading cache from develop branch"
+          mkdir cache-artifact
+          cd cache-artifact
+          if wget --quiet -O cache-artifact.zip https://gitlab.com/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME/-/jobs/artifacts/develop/download?job=$CI_JOB_NAME; then
+            unzip -q cache-artifact.zip
+            rm cache-artifact.zip
+            mv cache-artifact/* $CACHE_DIR/ || true
+          else
+            echo "Failed to download cache"
+          fi
+          cd ..
+          rm -rf cache-artifact
+        else
+          echo "Not touching cache (was initialized from previous build)"
+        fi
+      else
+        echo "Not touching cache (building develop branch or tag)"
+      fi
+    # Create missing cache dirs
+    - mkdir -p $CACHE_DIR/ccache && mkdir -p $CACHE_DIR/depends && mkdir -p $CACHE_DIR/sdk-sources && mkdir -p $CACHE_DIR/apt
+    # Keep this as it makes caching related debugging easier
+    - ls -lah $CACHE_DIR && ls -lah $CACHE_DIR/depends && ls -lah $CACHE_DIR/ccache && ls -lah $CACHE_DIR/apt
+    - mv $CACHE_DIR/apt/* /var/cache/apt/archives/ || true
+
+    # Install base packages
+    - apt-get dist-upgrade -y
+    - apt-get install -y git g++ autotools-dev libtool m4 automake autoconf pkg-config zlib1g-dev libssl1.0-dev curl ccache bsdmainutils cmake
+    - apt-get install -y python3 python3-dev python3-pip
+
+    # jinja2 is needed for combine_logs.py
+    - pip3 install jinja2
+
+    # Setup some environment variables
+    - |
+      if [ "$CI_EXTERNAL_PULL_REQUEST_IID" != "" ]; then
+        export PULL_REQUEST="true"
+      else
+        # CI_EXTERNAL_PULL_REQUEST_IID is false every time until https://gitlab.com/gitlab-org/gitlab/issues/5667 is done
+        # Until then, we're using https://github.com/brndnmtthws/labhub atm to mirror Github pull requests as branches into Gitlab,
+        # which allows us to use Gitlab CI for Github. The following check detects such mirrored branches.
+        if [[ $CI_COMMIT_REF_NAME =~ ^pr-[^/]*/[^/]*/[^/]*/[^/]*$ ]]; then
+          export PULL_REQUEST="true"
+          # CI_COMMIT_BEFORE_SHA is also invalid until #5667 is implemented, so we need to figure it out by ourself
+          git fetch origin develop
+          export CI_COMMIT_BEFORE_SHA="$(git merge-base origin/develop HEAD)"
+        else
+          export PULL_REQUEST="false"
+        fi
+      fi
+    - export COMMIT_RANGE="$CI_COMMIT_BEFORE_SHA..$CI_COMMIT_SHA"
+    - export JOB_NUMBER="$CI_JOB_ID"
+    - export HOST_SRC_DIR=$CI_PROJECT_DIR
+    - echo PULL_REQUEST=$PULL_REQUEST COMMIT_RANGE=$COMMIT_RANGE HOST_SRC_DIR=$HOST_SRC_DIR CACHE_DIR=$CACHE_DIR
+    - echo "Commit log:" && git log --format=fuller -1
+
+    # Build dash_hash
+    - git clone https://github.com/dashpay/dash_hash
+    - cd dash_hash && python3 setup.py install
+
+    # Install build target specific packages
+    - echo PACKAGES=$PACKAGES
+    - if [ -n "$DPKG_ADD_ARCH" ]; then dpkg --add-architecture "$DPKG_ADD_ARCH" ; fi
+    - if [ -n "$PACKAGES" ]; then apt-get update && apt-get install -y --no-install-recommends --no-upgrade $PACKAGES; fi
+
+    # Move apt packages into cache
+    - mv /var/cache/apt/archives/* $CACHE_DIR/apt/ || true
+
+    # Make mingw use correct threading libraries
+    - update-alternatives --set i686-w64-mingw32-gcc /usr/bin/i686-w64-mingw32-gcc-posix || true
+    - update-alternatives --set i686-w64-mingw32-g++  /usr/bin/i686-w64-mingw32-g++-posix || true
+    - update-alternatives --set x86_64-w64-mingw32-gcc  /usr/bin/x86_64-w64-mingw32-gcc-posix || true
+    - update-alternatives --set x86_64-w64-mingw32-g++  /usr/bin/x86_64-w64-mingw32-g++-posix || true
+
+  script:
+    - export BUILD_TARGET="$CI_JOB_NAME"
+    - cd $CI_PROJECT_DIR
+    - ./ci/build_depends.sh
+    - ./ci/build_src.sh
+    - ./ci/test_unittests.sh
+    - ./ci/test_integrationtests.sh --extended --exclude pruning,dbcrash
+
+  after_script:
+    # Copy all cache files into cache-artifact so that they get uploaded. We only do this for develop so that artifacts
+    # stay minimal for PRs and branches (we never need them)
+    - mkdir -p $CI_PROJECT_DIR/cache-artifact
+    - mkdir -p $CI_PROJECT_DIR/testlogs
+    - |
+      if [ "$CI_COMMIT_REF_SLUG" = "develop" ]; then
+        cp -ra $CI_PROJECT_DIR/cache/* $CI_PROJECT_DIR/cache-artifact/
+      fi
+
+  # We're actually only interested in the develop branch creating the cache artifact, but there is no way to control this
+  # until https://gitlab.com/gitlab-org/gitlab-foss/issues/25478 gets implemented. Until then, we use an expiration time of
+  # 3 days and rely on daily builds to refresh the cache artifacts. We also keep non-develop artifacts at minimum size
+  artifacts:
+    name: cache-artifact
+    when: always
+    paths:
+      - $CI_PROJECT_DIR/cache-artifact
+      - $CI_PROJECT_DIR/testlogs
+    expire_in: 3 days
+
+arm-linux:
+  <<: *build_template
+
+win32:
+  <<: *build_template
+
+win64:
+  <<: *build_template
+
+linux32:
+  <<: *build_template
+
+linux64:
+  <<: *build_template
+
+linux64_nowallet:
+  <<: *build_template
+
+linux64_release:
+  <<: *build_template
+
+mac:
+  <<: *build_template

.travis.yml

@@ -6,7 +6,7 @@ sudo: required
 dist: trusty
 
 os: linux
-language: generic
+language: minimal
 
 services:
   - docker
@@ -47,7 +47,8 @@ runtests: &runtests
     - $DOCKER_RUN_IN_BUILDER ./ci/build_depends.sh
     - $DOCKER_RUN_IN_BUILDER ./ci/build_src.sh
     - $DOCKER_RUN_IN_BUILDER ./ci/test_unittests.sh
-    - $DOCKER_RUN_IN_BUILDER ./ci/test_integrationtests.sh --jobs=3
+    - if [ "$TRAVIS_EVENT_TYPE" = "cron" ]; then extended="--extended --exclude pruning,dbcrash"; fi
+    - $DOCKER_RUN_IN_BUILDER ./ci/test_integrationtests.sh --jobs=3 ${extended}
 
 builddocker: &builddocker
   stage: build docker
@@ -119,10 +120,12 @@ before_install:
 install:
     # Our scripts try to be Travis agnostic
     - export PULL_REQUEST="$TRAVIS_PULL_REQUEST"
+    - export COMMIT_RANGE="$TRAVIS_COMMIT_RANGE"
     - export JOB_NUMBER="$TRAVIS_JOB_NUMBER"
     - export HOST_SRC_DIR=$TRAVIS_BUILD_DIR
     - export HOST_CACHE_DIR=$HOME/cache
     - export TRAVIS_COMMIT_LOG=`git log --format=fuller -1`
+    - export PYTHON_DEBUG=1
     - source ./ci/matrix.sh
     - mkdir -p $HOST_CACHE_DIR/docker && mkdir -p $HOST_CACHE_DIR/ccache && mkdir -p $HOST_CACHE_DIR/depends && mkdir -p $HOST_CACHE_DIR/sdk-sources
     # Keep this as it makes caching related debugging easier

CMakeLists.txt

@@ -33,32 +33,45 @@ if(DEFINED DEPENDS_PREFIX)
 endif()
 
 add_definitions(
+        -DENABLE_CRASH_HOOKS=1
         -DENABLE_WALLET=1
 )
 
 file(GLOB SOURCE_FILES
+        src/*.cpp
+        src/*.h
         src/bench/*.cpp
         src/bench/*.h
         src/bls/*.cpp
         src/bls/*.h
         src/compat/*.cpp
         src/compat/*.h
-        src/consensus/*.h
         src/consensus/*.cpp
+        src/consensus/*.h
         src/crypto/*.c
-        src/crypto/*.h
         src/crypto/*.cpp
+        src/crypto/*.h
+        src/evo/*.cpp
+        src/evo/*.h
         src/leveldb/db/*.cc
         src/leveldb/db/*.h
         src/leveldb/include/*.h
+        src/llmq/*.cpp
+        src/llmq/*.h
+        src/masternode/*.cpp
+        src/masternode/*.h
         src/policy/*.cpp
         src/policy/*.h
         src/primitives/*.cpp
         src/primitives/*.h
-        src/qt/test/*.cpp
-        src/qt/test/*.h
+        src/privatesend/*.cpp
+        src/privatesend/*.h
         src/qt/*.cpp
         src/qt/*.h
+        src/qt/test/*.cpp
+        src/qt/test/*.h
+        src/rpc/*.cpp
+        src/rpc/*.h
         src/script/*.cpp
         src/script/*.h
         src/secp256k1/include/*.h
@@ -67,19 +80,11 @@ file(GLOB SOURCE_FILES
         src/univalue/include/*.h
         src/univalue/lib/*.cpp
         src/univalue/lib/*.h
-        src/wallet/test/*.cpp
         src/wallet/*.cpp
         src/wallet/*.h
+        src/wallet/test/*.cpp
         src/zmq/*.cpp
         src/zmq/*.h
-        src/*.cpp
-        src/*.h
-        src/evo/*.h
-        src/evo/*.cpp
-        src/llmq/*.h
-        src/llmq/*.cpp
-        src/rpc/*.cpp
-        src/rpc/*.h
         )
 
 add_executable(dash ${SOURCE_FILES})

CONTRIBUTING.md

@@ -37,8 +37,8 @@ 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 init.cpp") then a single title line is sufficient. Commit messages should be
+paragraph(s), unless the title alone is self-explanatory (like "Corrected typo
+in init.cpp") in which case 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/).
 
@@ -170,13 +170,13 @@ judge the general consensus of contributors.
 
 In general, all pull requests must:
 
-  - have a clear use case, fix a demonstrable bug or serve the greater good of
+  - Have a clear use case, fix a demonstrable bug or serve the greater good of
     the project (for example refactoring for modularisation);
-  - be well peer reviewed;
-  - have unit tests and functional tests where appropriate;
-  - follow [code style guidelines](/doc/developer-notes.md);
-  - not break the existing test suite;
-  - where bugs are fixed, where possible, there should be unit tests
+  - Be well peer reviewed;
+  - Have unit tests and functional tests where appropriate;
+  - Follow [code style guidelines](/doc/developer-notes.md);
+  - Not break the existing test suite;
+  - Where bugs are fixed, where possible, there should be unit tests
     demonstrating the bug and also proving the fix. This helps prevent regression.
 
 Patches that change Dash consensus rules are considerably more involved than
@@ -225,6 +225,36 @@ discussed extensively on the mailing list and IRC, be accompanied by a widely
 discussed BIP and have a generally widely perceived technical consensus of being
 a worthwhile change based on the judgement of the maintainers.
 
+### Finding Reviewers
+
+The review process is normally fairly responsive on the Dash Core repository, however
+this might not always be the case. If you find that you've been waiting
+for a pull request to be given attention for several months, there may be a number
+of reasons for this, some of which you can do something about:
+
+  - It may be because of a feature freeze due to an upcoming release. During this time,
+    only bug fixes are taken into consideration. If your pull request is a new feature,
+    it will not be prioritized until the release is over. Wait for release.
+  - It may be because the changes you are suggesting do not appeal to people. Rather than
+    nits and critique, which require effort and means they care enough to spend time on your
+    contribution, thundering silence is a good sign of widespread (mild) dislike of a given change
+    (because people don't assume *others* won't actually like the proposal). Don't take
+    that personally, though! Instead, take another critical look at what you are suggesting
+    and see if it: changes too much, is too broad, doesn't adhere to the
+    [developer notes](doc/developer-notes.md), is dangerous or insecure, is messily written, etc.
+    Identify and address any of the issues you find. Then ask e.g. on the forum or on a community
+    discord if someone could give their opinion on the concept itself.
+  - It may be because your code is too complex for all but a few people. And those people
+    may not have realized your pull request even exists. A great way to find people who
+    are qualified and care about the code you are touching is the
+    [Git Blame feature](https://help.github.com/articles/tracing-changes-in-a-file/). Simply
+    find the person touching the code you are touching before you and see if you can find
+    them and give them a nudge. Don't be incessant about the nudging though.
+  - Finally, if all else fails, ask on discord or elsewhere for someone to give your pull request
+    a look. If you think you've been waiting an unreasonably long amount of time (month+) for
+    no particular reason (few lines changed, etc), this is totally fine. Try to return the favor
+    when someone else is asking for feedback on their code, and universe balances out.
+
 
 Release Policy
 --------------

COPYING

@@ -1,7 +1,8 @@
 The MIT License (MIT)
 
-Copyright (c) 2009-2019 The Bitcoin Core developers
-Copyright (c) 2014-2019 The Dash Core developers
+Copyright (c) 2009-2020 The Bitcoin Core developers
+Copyright (c) 2009-2020 Bitcoin Developers
+Copyright (c) 2014-2020 The Dash Core developers
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal