Desire v.0.12.2.2

.travis.yml

@@ -46,7 +46,7 @@ env:
 # desired
     - HOST=x86_64-unknown-linux-gnu PPA="ppa:bitcoin/bitcoin" PACKAGES="bc python3-zmq" DEP_OPTS="NO_QT=1 NO_UPNP=1 DEBUG=1" RUN_TESTS=true GOAL="install" BITCOIN_CONFIG="--enable-zmq --enable-glibc-back-compat --enable-reduce-exports" CPPFLAGS="-DDEBUG_LOCKORDER -DENABLE_DESIRE_DEBUG" PYZMQ=true
 # 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"
+    - 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"
 
@@ -81,8 +81,8 @@ script:
     - ./configure --cache-file=../config.cache $BITCOIN_CONFIG_ALL $BITCOIN_CONFIG || ( cat config.log && false)
     - make $MAKEJOBS $GOAL || ( echo "Build failure. Verbose build follows." && make $GOAL V=1 ; false )
     - export LD_LIBRARY_PATH=$TRAVIS_BUILD_DIR/depends/$HOST/lib
-    - if [ "$RUN_TESTS" = "true" -a "$WINE" != "true" ]; then make $MAKEJOBS check VERBOSE=1; fi
-    - if [ "$RUN_TESTS" = "true" -a "$WINE" = "true" ]; then wine  src/test/test_desire.exe; fi
+    - if [ "$RUN_TESTS" = "true" -a "$WINE" != "true" ]; then travis_wait 30 make $MAKEJOBS check VERBOSE=1; fi
+    - if [ "$RUN_TESTS" = "true" -a "$WINE" = "true" ]; then wine  src/test/test_desire.exe --log_level=test_suite; fi
     - if [ "$RUN_TESTS" = "true" ]; then qa/pull-tester/rpc-tests.py --coverage; fi
 after_script:
     - if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then (echo "Upload goes here. Something like: scp -r $BASE_OUTDIR server" || echo "upload failed"); fi

COPYING

@@ -1,7 +1,7 @@
 The MIT License (MIT)
 
-Copyright (c) 2009-2016 The Bitcoin Core developers
-Copyright (c) 2014-2017 The Desire Core developers
+Copyright (c) 2009-2017 The Bitcoin Core developers
+Copyright (c) 2018 The Desire 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

README.md

@@ -1,62 +1,37 @@
-Desire Core staging tree 0.12.2.1
-===============================
+Desire Core staging tree 0.12.2.2
 
-https://bitcointalk.org/index.php?topic=2272607.0
+https://www.desire-crypto.com
 
+https://bitcointalk.org/index.php?topic=2272607.0
 
 What is Desire?
-----------------
 
-Desire is an experimental new digital currency that enables anonymous, instant
-payments to anyone, anywhere in the world. Desire uses peer-to-peer technology
-to operate with no central authority: managing transactions and issuing money
-are carried out collectively by the network. Desire Core is the name of the open
-source software which enables the use of this currency.
-
-For more information, as well as an immediately useable, binary version of
-the Desire Core software, see https://bitcointalk.org/index.php?topic=2272607.0.
+Desire is an experimental new digital currency that enables anonymous, instant payments to anyone, anywhere in the world. Desire uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Desire Core is the name of the open source software which enables the use of this currency.
 
+For more information, as well as an immediately useable, binary version of the Desire Core software, see https://bitcointalk.org/index.php?topic=2272607.0.
 
 License
--------
 
-Desire Core is released under the terms of the MIT license. See [COPYING](COPYING) for more
-information or see https://opensource.org/licenses/MIT.
+Desire Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.
 
 Development Process
--------------------
 
-The `master` branch is meant to be stable. Development is normally done in separate branches.
-[Tags](https://github.com/lazyboozer/Desire/tags) are created to indicate new official,
-stable release versions of Desire Core.
+The master branch is meant to be stable. Development is normally done in separate branches. Tags are created to indicate new official, stable release versions of Desire Core.
 
-The contribution workflow is described in [CONTRIBUTING.md](CONTRIBUTING.md).
+The contribution workflow is described in 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
+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.
 
-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`
+Automated Testing
 
-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`
+Developers are strongly encouraged to write unit tests 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
 
-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.
+There are also regression and integration tests of the RPC interface, written in Python, that are run automatically on the build server. These tests can be run (if the test dependencies are installed) with: qa/pull-tester/rpc-tests.py
 
-### Manual Quality Assurance (QA) Testing
+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.
 
-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.
+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.

build-aux/m4/bitcoin_qt.m4

@@ -203,6 +203,21 @@ AC_DEFUN([BITCOIN_QT_CONFIGURE],[
   BITCOIN_QT_PATH_PROGS([LRELEASE], [lrelease-qt${bitcoin_qt_got_major_vers} lrelease${bitcoin_qt_got_major_vers} lrelease], $qt_bin_path)
   BITCOIN_QT_PATH_PROGS([LUPDATE], [lupdate-qt${bitcoin_qt_got_major_vers} lupdate${bitcoin_qt_got_major_vers} lupdate],$qt_bin_path, yes)
 
+  BITCOIN_QT_CHECK([
+    AC_CACHE_CHECK([whether $RCC accepts --format-version option],
+                   [ac_cv_prog_rcc_accepts_format_version],
+                   [ac_cv_prog_rcc_accepts_format_version=no
+                    echo '<!DOCTYPE RCC><RCC version="1.0"/>' > conftest.qrc
+                    $RCC --format-version 1 conftest.qrc >/dev/null 2>&1 && ac_cv_prog_rcc_accepts_format_version=yes
+                    rm -f conftest.qrc])
+    if test "$ac_cv_prog_rcc_accepts_format_version" = yes; then
+      RCCFLAGS="--format-version 1"
+    else
+      RCCFLAGS=
+    fi
+    AC_SUBST(RCCFLAGS)
+  ])
+
   MOC_DEFS='-DHAVE_CONFIG_H -I$(srcdir)'
   case $host in
     *darwin*)

configure.ac

@@ -3,7 +3,7 @@ AC_PREREQ([2.60])
 define(_CLIENT_VERSION_MAJOR, 0)
 define(_CLIENT_VERSION_MINOR, 12)
 define(_CLIENT_VERSION_REVISION, 2)
-define(_CLIENT_VERSION_BUILD, 1)
+define(_CLIENT_VERSION_BUILD, 2)
 define(_CLIENT_VERSION_IS_RELEASE, true)
 define(_COPYRIGHT_YEAR, 2017)
 AC_INIT([Desire Core],[_CLIENT_VERSION_MAJOR._CLIENT_VERSION_MINOR._CLIENT_VERSION_REVISION],[https://github.com/desirepay/desire/issues],[desirecore])
@@ -187,6 +187,9 @@ AC_ARG_ENABLE([debug],
     [enable_debug=$enableval],
     [enable_debug=no])
 
+AC_LANG_PUSH([C++])
+AX_CHECK_COMPILE_FLAG([-Werror],[CXXFLAG_WERROR="-Werror"],[CXXFLAG_WERROR=""])
+
 if test "x$enable_debug" = xyes; then
     CPPFLAGS="$CPPFLAGS -DDEBUG"
     if test "x$GCC" = xyes; then
@@ -198,11 +201,20 @@ if test "x$enable_debug" = xyes; then
     fi
 fi
 
-## TODO: Remove these hard-coded paths and flags. They are here for the sake of
-##       compatibility with the legacy buildsystem.
-##
 if test "x$CXXFLAGS_overridden" = "xno"; then
-  CXXFLAGS="$CXXFLAGS -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -Wno-self-assign -Wno-implicit-fallthrough"
+  AX_CHECK_COMPILE_FLAG([-Wall],[CXXFLAGS="$CXXFLAGS -Wall"],,[[$CXXFLAG_WERROR]])
+  AX_CHECK_COMPILE_FLAG([-Wextra],[CXXFLAGS="$CXXFLAGS -Wextra"],,[[$CXXFLAG_WERROR]])
+  AX_CHECK_COMPILE_FLAG([-Wformat],[CXXFLAGS="$CXXFLAGS -Wformat"],,[[$CXXFLAG_WERROR]])
+  AX_CHECK_COMPILE_FLAG([-Wformat-security],[CXXFLAGS="$CXXFLAGS -Wformat-security"],,[[$CXXFLAG_WERROR]])
+
+  ## Some compilers (gcc) ignore unknown -Wno-* options, but warn about all
+  ## unknown options if any other warning is produced. Test the -Wfoo case, and
+  ## set the -Wno-foo case if it works.
+  AX_CHECK_COMPILE_FLAG([-Wunused-parameter],[CXXFLAGS="$CXXFLAGS -Wno-unused-parameter"],,[[$CXXFLAG_WERROR]])
+  AX_CHECK_COMPILE_FLAG([-Wself-assign],[CXXFLAGS="$CXXFLAGS -Wno-self-assign"],,[[$CXXFLAG_WERROR]])
+  AX_CHECK_COMPILE_FLAG([-Wunused-local-typedef],[CXXFLAGS="$CXXFLAGS -Wno-unused-local-typedef"],,[[$CXXFLAG_WERROR]])
+  AX_CHECK_COMPILE_FLAG([-Wdeprecated-register],[CXXFLAGS="$CXXFLAGS -Wno-deprecated-register"],,[[$CXXFLAG_WERROR]])
+  AX_CHECK_COMPILE_FLAG([-Wimplicit-fallthrough],[CXXFLAGS="$CXXFLAGS -Wno-implicit-fallthrough"],,[[$CXXFLAG_WERROR]])
 fi
 CPPFLAGS="$CPPFLAGS -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS"
 
@@ -224,8 +236,6 @@ AC_ARG_WITH([daemon],
   [build_bitcoind=$withval],
   [build_bitcoind=yes])
 
-AC_LANG_PUSH([C++])
-
 use_pkgconfig=yes
 case $host in
   *mingw*)

desire-docs/protocol-documentation.md

@@ -1,4 +1,4 @@
-Protocol Documentation - 0.12.1
+Protocol Documentation - 0.12.2.2
 =====================================
 
 This document describes the protocol extensions for all additional functionality build into the Desire protocol. This doesn't include any of the Bitcoin protocol, which has been left intact in the Desire project. For more information about the core protocol, please see https://en.bitcoin.it/w/index.php?title#Protocol_documentation&action#edit
@@ -148,9 +148,9 @@ Asks users to sign final mixing tx message.
 | ---------- | ----------- | --------- | -------- |
 | 4 | nDenom | int | Which denomination is allowed in this mixing session
 | 41 | vin | [CTxIn](#ctxin) | unspend output from masternode which is hosting this session
-| 4 | nTime | int | the time this DSQ was created
-| 4 | fReady | int | if the mixing pool is ready to be executed
-| 71-73 | vchSig | char[] | Signature of this message by masternode (verifiable via pubKeyMasternode)
+| 8 | nTime | int64_t | the time this DSQ was created
+| 1 | fReady | bool | if the mixing pool is ready to be executed
+| 66 | vchSig | char[] | Signature of this message by masternode (verifiable via pubKeyMasternode)
 
 ### DSACCEPT - "dsa"
 
@@ -172,7 +172,7 @@ When queue is ready user is expected to send his entry to start actual mixing
 | ? | vecTxDSIn | CTxDSIn[] | vector of users inputs (CTxDSIn serialization is equal to [CTxIn](#ctxin) serialization)
 | 8 | nAmount | int64_t | depreciated since 12.1, it's used for backwards compatibility only and can be removed with future protocol bump
 | ? | txCollateral | [CTransaction](#ctransaction) | Collateral transaction which is used to prevent misbehavior and also to charge fees randomly
-| ? | vecTxDSOut | CTxDSOut[] | vector of user outputs (CTxDSOut serialization is equal to [CTxOut](#ctxout) serialization)
+| ? | vecTxOut | CTxOut[] | vector of user outputs
 
 ### DSSIGNFINALTX - "dss"
 

doc/README_windows.txt

@@ -1,4 +1,4 @@
-Desire Core 0.12.1
+Desire Core 0.12.2
 =====================
 
 Intro
@@ -18,6 +18,4 @@ However, it downloads and stores the entire history of Desire transactions;
 depending on the speed of your computer and network connection, the synchronization
 process can take anywhere from a few hours to a day or more.
 
-See the desire wiki at:
-  https://desirepay.atlassian.net/wiki/
-for more help and information.
+

doc/developer-notes.md

@@ -12,14 +12,15 @@ gradually.
   - No indentation for public/protected/private or for namespaces.
   - No extra spaces inside parenthesis; don't do ( this )
   - No space after function names; one space after if, for and while.
+  - Align pointers and references to the left i.e. use `type& var` and not `type &var`.
 
 Block style example:
 ```c++
 namespace foo
 {
 class Class
 {
-    bool Function(char* psz, int n)
+    bool Function(char* psz, int n, const string& s)
     {
         // Comment summarising what this section of code does
         for (int i = 0; i < n; i++) {

doc/guide-startmany.md

@@ -1,46 +1,6 @@
 # start-many Setup Guide
 
-## Two Options for Setting up your Wallet
-There are many ways to setup a wallet to support start-many. This guide will walk through two of them.
-
-1. [Importing an existing wallet (recommended if you are consolidating wallets).](#option1)
-2. [Sending 1000 DSR to new wallet addresses.](#option2)
-
-## <a name="option1"></a>Option 1. Importing an existing wallet
-
-This is the way to go if you are consolidating multiple wallets into one that supports start-many. 
-
-### From your single-instance Masternode Wallet
-
-Open your QT Wallet and go to console (from the menu select `Tools` => `Debug Console`)
-
-Dump the private key from your MasterNode's pulic key.
-
-```
-walletpassphrase [your_wallet_passphrase] 600
-dumpprivkey [mn_public_key]
-```
-
-Copy the resulting priviate key. You'll use it in the next step.
-
-### From your multi-instance Masternode Wallet
-
-Open your QT Wallet and go to console (from the menu select `Tools` => `Debug Console`)
-
-Import the private key from the step above.
-
-```
-walletpassphrase [your_wallet_passphrase] 600
-importprivkey [single_instance_private_key]
-```
-
-The wallet will re-scan and you will see your available balance increase by the amount that was in the imported wallet.
-
-[Skip Option 2. and go to Create masternode.conf file](#masternodeconf)
-
-## <a name="option2"></a>Option 2. Starting with a new wallet
-
-[If you used Option 1 above, then you can skip down to Create masternode.conf file.](#masternodeconf)
+## Setting up your Wallet
 
 ### Create New Wallet Addresses
 
@@ -58,7 +18,7 @@ Close your QT Wallet.
 
 ### Send 1000 DSR to New Addresses
 
-Just like setting up a standard MN. Send exactly 1000 DSR to each new address created above.
+Send exactly 1000 DSR to each new address created above.
 
 ### Create New Masternode Private Keys
 
@@ -80,8 +40,6 @@ Create the `masternode.conf` file in the same directory as your `wallet.dat`.
 
 Copy the masternode private key and correspondig collateral output transaction that holds the 1000 DSR.
 
-The masternode private key may be an existing key from [Option 1](#option1), or a newly generated key from [Option 2](#option2). 
-
 *Note: The masternode priviate key is **not** the same as a wallet private key. **Never** put your wallet private key in the masternode.conf file. That is almost equivalent to putting your 1000 DSR on the remote server and defeats the purpose of a hot/cold setup.*
 
 ### Get the collateral output
@@ -110,10 +68,6 @@ mn01 127.0.0.1:9919 93HaYBVUCYjEMeeH1Y4sBGLALQZE1Yc1K64xiqgX37tGBDQL8Xg 2bcd3c84
 mn02 127.0.0.2:9919 93WaAb3htPJEV8E9aQcN23Jt97bPex7YvWfgMDTUdWJvzmrMqey aa9f1034d973377a5e733272c3d0eced1de22555ad45d6b24abadff8087948d4 0
 ```
 
-## What about the desire.conf file?
-
-If you are using a `masternode.conf` file you no longer need the `desire.conf` file. The exception is if you need custom settings (_thanks oblox_). In that case you **must** remove `masternode=1` from local `desire.conf` file. This option should be used only to start local Hot masternode now.
-
 ## Update desire.conf on server
 
 If you generated a new masternode private key, you will need to update the remote `desire.conf` files.