r1

2022-02-03 23:45:47 -08:00
parent 42c2062cc4
commit 184ece190c
1438 changed files with 404064 additions and 0 deletions
@@ -0,0 +1,72 @@
+Agrarian Core
+=============
+
+Setup
+---------------------
+[Agrarian Core](http://agrarian.org/wallet) is the original Agrarian client and it builds the backbone of the network. However, it downloads and stores the entire history of Agrarian 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. Thankfully you only have to do this once.
+
+Running
+---------------------
+The following are some helpful notes on how to run Agrarian Core on your native platform.
+
+### Unix
+
+Unpack the files into a directory and run:
+
+- `bin/agrarian-qt` (GUI) or
+- `bin/agrariand` (headless)
+
+### Windows
+
+Unpack the files into a directory, and then run agrarian-qt.exe.
+
+### macOS
+
+Drag Agrarian-Qt to your applications folder, and then run Agrarian-Qt.
+
+### Need Help?
+
+* See the documentation at the [Agrarian Wiki](https://github.com/Agrarian-Project/Agrarian/wiki)
+for help and more information.
+* Ask for help on [BitcoinTalk](https://bitcointalk.org/index.php?topic=1262920.0) or on the [Agrarian Forum](http://forum.agrarian.org/).
+* Join our Discord server [Discord Server](https://discord.agrarian.org)
+
+Building
+---------------------
+The following are developer notes on how to build Agrarian Core on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.
+
+- [Dependencies](dependencies.md)
+- [macOS Build Notes](build-osx.md)
+- [Unix Build Notes](build-unix.md)
+- [Windows Build Notes](build-windows.md)
+- [Gitian Building Guide](gitian-building.md)
+
+Development
+---------------------
+The Agrarian repo's [root README](/README.md) contains relevant information on the development process and automated testing.
+
+- [Developer Notes](developer-notes.md)
+- [Multiwallet Qt Development](multiwallet-qt.md)
+- [Release Notes](release-notes.md)
+- [Release Process](release-process.md)
+- [Source Code Documentation (External Link)](https://www.fuzzbawls.pw/agrarian/doxygen/)
+- [Translation Process](translation_process.md)
+- [Unit Tests](unit-tests.md)
+- [Unauthenticated REST Interface](REST-interface.md)
+- [Dnsseed Policy](dnsseed-policy.md)
+
+### Resources
+* Discuss on the [BitcoinTalk](https://bitcointalk.org/index.php?topic=1262920.0) or the [Agrarian](http://forum.agrarian.org/) forum.
+* Join the [Agrarian Discord](https://discord.agrarian.org).
+
+### Miscellaneous
+- [Assets Attribution](assets-attribution.md)
+- [Files](files.md)
+- [Tor Support](tor.md)
+- [Init Scripts (systemd/upstart/openrc)](init.md)
+
+License
+---------------------
+Distributed under the [MIT software license](/COPYING).
+This product includes software developed by the OpenSSL Project for use in the [OpenSSL Toolkit](https://www.openssl.org/). This product includes
+cryptographic software written by Eric Young ([eay@cryptsoft.com](mailto:eay@cryptsoft.com)), and UPnP software written by Thomas Bernard.
@@ -0,0 +1,19 @@
+Agrarian Core
+=====================
+
+Intro
+-----
+Agrarian is a free open source peer-to-peer electronic cash system that is
+completely decentralized, without the need for a central server or trusted
+parties.  Users hold the crypto keys to their own money and transact directly
+with each other, with the help of a P2P network to check for double-spending.
+
+
+Setup
+-----
+Unpack the files into a directory and run agrarian-qt.exe.
+
+Agrarian Core is the original Agrarian client and it builds the backbone of the network.
+However, it downloads and stores the entire history of Agrarian 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.
@@ -0,0 +1,92 @@
+Unauthenticated REST Interface
+==============================
+
+The REST API can be enabled with the `-rest` option.
+
+Supported API
+-------------
+
+#### Transactions
+`GET /rest/tx/<TX-HASH>.<bin|hex|json>`
+
+Given a transaction hash: returns a transaction in binary, hex-encoded binary, or JSON formats.
+
+For full TX query capability, one must enable the transaction index via "txindex=1" command line / configuration option. (enabled by default)
+
+#### Blocks
+`GET /rest/block/<BLOCK-HASH>.<bin|hex|json>`
+`GET /rest/block/notxdetails/<BLOCK-HASH>.<bin|hex|json>`
+
+Given a block hash: returns a block, in binary, hex-encoded binary or JSON formats.
+
+The HTTP request and response are both handled entirely in-memory, thus making maximum memory usage at least 4.66MB (2 MB max block, plus hex encoding) per request.
+
+With the /notxdetails/ option JSON response will only contain the transaction hash instead of the complete transaction details. The option only affects the JSON response.
+
+#### Blockheaders
+`GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex|json>`
+
+Given a block hash: returns <COUNT> amount of blockheaders in upward direction.
+
+#### Chaininfos
+`GET /rest/chaininfo.json`
+
+Returns various state info regarding block chain processing.
+Only supports JSON as output format.
+* chain : (string) current network name as defined in BIP70 (main, test, regtest)
+* blocks : (numeric) the current number of blocks processed in the server
+* headers : (numeric) the current number of headers we have validated
+* bestblockhash : (string) the hash of the currently best block
+* difficulty : (numeric) the current difficulty
+* verificationprogress : (numeric) estimate of verification progress [0..1]
+* chainwork : (string) total amount of work in active chain, in hexadecimal
+
+#### Query UTXO set
+`GET /rest/getutxos/<checkmempool>/<txid>-<n>/<txid>-<n>/.../<txid>-<n>.<bin|hex|json>`
+
+The getutxo command allows querying of the UTXO set given a set of outpoints.
+See BIP64 for input and output serialisation:
+https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki
+
+Example:
+```
+$ curl localhost:18332/rest/getutxos/checkmempool/b2cdfd7b89def827ff8af7cd9bff7627ff72e5e8b0f71210f92ea7a4000c5d75-0.json 2>/dev/null | json_pp
+{
+   "chaintipHash" : "00000000fb01a7f3745a717f8caebee056c484e6e0bfe4a9591c235bb70506fb",
+   "chainHeight" : 325347,
+   "utxos" : [
+      {
+         "scriptPubKey" : {
+            "addresses" : [
+               "mi7as51dvLJsizWnTMurtRmrP8hG2m1XvD"
+            ],
+            "type" : "pubkeyhash",
+            "hex" : "76a9141c7cebb529b86a04c683dfa87be49de35bcf589e88ac",
+            "reqSigs" : 1,
+            "asm" : "OP_DUP OP_HASH160 1c7cebb529b86a04c683dfa87be49de35bcf589e OP_EQUALVERIFY OP_CHECKSIG"
+         },
+         "value" : 8.8687,
+         "height" : 2147483647,
+         "txvers" : 1
+      }
+   ],
+   "bitmap" : "1"
+}
+```
+
+#### Memory pool
+`GET /rest/mempool/info.json`
+
+Returns various information about the TX mempool.
+Only supports JSON as output format.
+* size : (numeric) the number of transactions in the TX mempool
+* bytes : (numeric) size of the TX mempool in bytes
+
+`GET /rest/mempool/contents.json`
+
+Returns transactions in the TX mempool.
+Only supports JSON as output format.
+
+Risks
+-------------
+Running a web browser on the same node with a REST enabled agrariand can be a risk. Accessing prepared XSS websites could read out tx/block data of your node by placing links like `<script src="http://127.0.0.1:51335/rest/tx/1234567890.json">` which might break the nodes privacy.
@@ -0,0 +1,103 @@
+The following is a list of assets used in the bitcoin source and their proper attribution.
+
+[Wladimir van der Laan](https://github.com/laanwj)
+-----------------------
+#### Info
+* License: MIT
+
+### Assets Used
+	src/qt/res/icons/clock*.png, src/qt/res/icons/tx*.png,
+	src/qt/res/src/clock_green.svg, src/qt/res/src/clock1.svg,
+	src/qt/res/src/clock2.svg, src/qt/res/src/clock3.svg,
+	src/qt/res/src/clock4.svg, src/qt/res/src/clock5.svg,
+	src/qt/res/src/inout.svg, src/qt/res/src/questionmark.svg
+
+[David Vignoni](http://www.icon-king.com)
+-----------------------
+
+### Info
+* Icon Pack: NUVOLA ICON THEME for KDE 3.x
+* Designer: David Vignoni (david@icon-king.com)
+* License: LGPL
+* Site: [http://www.icon-king.com/projects/nuvola](http://www.icon-king.com/projects/nuvola)
+
+### Assets Used
+	src/qt/res/icons/address-book.png, src/qt/res/icons/export.png,
+	src/qt/res/icons/history.png, src/qt/res/icons/key.png,
+	src/qt/res/icons/lock_*.png, src/qt/res/icons/overview.png,
+	src/qt/res/icons/receive.png, src/qt/res/icons/send.png,
+	src/qt/res/icons/synced.png, src/qt/res/icons/filesave.png
+
+schollidesign
+-----------------------
+
+### Info
+* Icon Pack: Human-O2
+* Designer: schollidesign
+* License: GNU/GPL
+* Site: [http://findicons.com/icon/93743/blocks_gnome_netstatus_0](http://findicons.com/icon/93743/blocks_gnome_netstatus_0)
+
+### Assets Used
+	src/qt/res/icons/connect*.png
+
+md2k7
+-----------------------
+
+### Info
+* Designer: md2k7
+* License: You are free to do with these icons as you wish, including selling, copying, modifying etc.
+* License: MIT
+* Site: [https://bitcointalk.org/index.php?topic=15276.0](https://bitcointalk.org/index.php?topic=15276.0)
+
+### Assets Used
+	src/qt/res/icons/transaction*.png
+
+[Everaldo.com](http://www.everaldo.com)
+-----------------------
+
+### Info
+* Icon Pack: Crystal SVG
+* Designer: [http://www.everaldo.com](http://www.everaldo.com)
+* License: LGPL
+
+### Assets Used
+	src/qt/res/icons/configure.png, src/qt/res/icons/quit.png,
+	src/qt/res/icons/editcopy.png, src/qt/res/icons/editpaste.png,
+	src/qt/res/icons/add.png, src/qt/res/icons/edit.png,
+	src/qt/res/icons/remove.png (edited)
+
+Everaldo (Everaldo Coelho)
+-----------------------
+
+### Info
+* Icon Pack: Kids
+* Designer: Everaldo (Everaldo Coelho)
+* License: GNU/GPL 
+* Site: [http://findicons.com/icon/17102/reload?id=17102](http://findicons.com/icon/17102/reload?id=17102)
+
+### Assets Used
+	scripts/img/reload.xcf (modified), src/qt/res/movies/*.png
+
+[Vignoni David](http://techbase.kde.org/Projects/Oxygen)
+-----------------------
+
+### Info
+* Designer: Vignoni David
+* License: Oxygen icon theme is dual licensed. You may copy it under the Creative Common Attribution-ShareAlike 3.0 License or the GNU Library General Public License.
+* Site: [http://techbase.kde.org/Projects/Oxygen](http://techbase.kde.org/Projects/Oxygen)
+
+### Assets Used
+	src/qt/res/icons/debugwindow.png
+
+Jonas Schnelli
+-----------------------
+
+### Info
+* Designer: Jonas Schnelli (based on the original bitcoin logo from Bitboy)
+* License: MIT
+
+### Assets Used
+	src/qt/res/icons/bitcoin.icns, src/qt/res/src/bitcoin.svg,
+	src/qt/res/src/bitcoin.ico, src/qt/res/src/bitcoin.png,
+	src/qt/res/src/bitcoin_testnet.png, docs/bitcoin_logo_doxygen.png,
+	src/qt/res/images/splash.png, src/qt/res/images/splash_testnet.png
@@ -0,0 +1,210 @@
+macOS Build Instructions and Notes
+====================================
+The commands in this guide should be executed in a Terminal application.
+The built-in one is located in `/Applications/Utilities/Terminal.app`.
+
+Preparation
+-----------
+Install the macOS command line tools:
+
+`xcode-select --install`
+
+When the popup appears, click `Install`.
+
+Then install [Homebrew](https://brew.sh).
+
+Dependencies
+----------------------
+
+    brew install autoconf automake berkeley-db4 libtool boost miniupnpc openssl pkg-config protobuf python3 qt5 zmq libevent qrencode gmp
+
+See [dependencies.md](dependencies.md) for a complete overview.
+
+If you want to build the disk image with `make deploy` (.dmg / optional), you need RSVG:
+
+    brew install librsvg
+
+Berkeley DB
+-----------
+It is recommended to use Berkeley DB 4.8. If you have to build it yourself,
+you can use [the installation script included in contrib/](/contrib/install_db4.sh)
+like so:
+
+```shell
+./contrib/install_db4.sh .
+```
+
+from the root of the repository.
+
+**Note**: You only need Berkeley DB if the wallet is enabled (see [*Disable-wallet mode*](/doc/build-osx.md#disable-wallet-mode)).
+
+Build Agrarian Core
+------------------------
+
+1. Clone the Agrarian Core source code:
+
+        git clone https://github.com/agrarian-project/agrarian
+        cd agrarian
+
+2.  Make the Homebrew OpenSSL headers visible to the configure script  (do ```brew info openssl``` to find out why this is necessary, or if you use Homebrew with installation folders different from the default).
+
+        export LDFLAGS+=-L/usr/local/opt/openssl/lib
+        export CPPFLAGS+=-I/usr/local/opt/openssl/include
+
+3.  Build Agrarian Core:
+
+        ./autogen.sh
+        ./configure
+        make
+
+4.  It is recommended to build and run the unit tests:
+
+        make check
+
+5.  You can also create a .dmg that contains the .app bundle (optional):
+
+        make deploy
+
+Disable-wallet mode
+--------------------
+**Note:** This functionality is not yet completely implemented, and compilation using the below option will currently fail.
+
+When the intention is to run only a P2P node without a wallet, Agrarian Core may be compiled in
+disable-wallet mode with:
+
+    ./configure --disable-wallet
+
+In this case there is no dependency on Berkeley DB 4.8.
+
+Running
+-------
+
+Agrarian Core is now available at `./src/agrariand`
+
+Before running, you may create an empty configuration file:
+
+    mkdir -p "/Users/${USER}/Library/Application Support/Agrarian"
+
+    touch "/Users/${USER}/Library/Application Support/Agrarian/agrarian.conf"
+
+    chmod 600 "/Users/${USER}/Library/Application Support/Agrarian/agrarian.conf"
+
+The first time you run agrariand, it will start downloading the blockchain. This process could take many hours, or even days on slower than average systems.
+
+You can monitor the download process by looking at the debug.log file:
+
+    tail -f $HOME/Library/Application\ Support/Agrarian/debug.log
+
+Other commands:
+-------
+
+    ./src/agrariand -daemon # Starts the agrarian daemon.
+    ./src/agrarian-cli --help # Outputs a list of command-line options.
+    ./src/agrarian-cli help # Outputs a list of RPC commands when the daemon is running.
+
+Notes
+-----
+
+* Tested on OS X 10.10 Yosemite through macOS 10.13 High Sierra on 64-bit Intel processors only.
+
+* Building with downloaded Qt binaries is not officially supported. See the notes in [#7714](https://github.com/bitcoin/bitcoin/issues/7714)
+
+Deterministic macOS DMG Notes
+-----------------------------
+
+Working macOS DMGs are created in Linux by combining a recent clang,
+the Apple binutils (ld, ar, etc) and DMG authoring tools.
+
+Apple uses clang extensively for development and has upstreamed the necessary
+functionality so that a vanilla clang can take advantage. It supports the use
+of -F, -target, -mmacosx-version-min, and --sysroot, which are all necessary
+when building for macOS.
+
+Apple's version of binutils (called cctools) contains lots of functionality
+missing in the FSF's binutils. In addition to extra linker options for
+frameworks and sysroots, several other tools are needed as well such as
+install_name_tool, lipo, and nmedit. These do not build under linux, so they
+have been patched to do so. The work here was used as a starting point:
+[mingwandroid/toolchain4](https://github.com/mingwandroid/toolchain4).
+
+In order to build a working toolchain, the following source packages are needed
+from Apple: cctools, dyld, and ld64.
+
+These tools inject timestamps by default, which produce non-deterministic
+binaries. The ZERO_AR_DATE environment variable is used to disable that.
+
+This version of cctools has been patched to use the current version of clang's
+headers and its libLTO.so rather than those from llvmgcc, as it was
+originally done in toolchain4.
+
+To complicate things further, all builds must target an Apple SDK. These SDKs
+are free to download, but not redistributable.
+To obtain it, register for a developer account, then download the [Xcode 7.3.1 dmg](https://developer.apple.com/devcenter/download.action?path=/Developer_Tools/Xcode_7.3.1/Xcode_7.3.1.dmg).
+
+This file is several gigabytes in size, but only a single directory inside is
+needed:
+```
+Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
+```
+
+Unfortunately, the usual linux tools (7zip, hpmount, loopback mount) are incapable of opening this file.
+To create a tarball suitable for Gitian input, there are two options:
+
+Using macOS, you can mount the dmg, and then create it with:
+```
+  $ hdiutil attach Xcode_7.3.1.dmg
+  $ tar -C /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -czf MacOSX10.11.sdk.tar.gz MacOSX10.11.sdk
+```
+
+Alternatively, you can use 7zip and SleuthKit to extract the files one by one.
+The script contrib/macdeploy/extract-osx-sdk.sh automates this. First ensure
+the dmg file is in the current directory, and then run the script. You may wish
+to delete the intermediate 5.hfs file and MacOSX10.11.sdk (the directory) when
+you've confirmed the extraction succeeded.
+
+```bash
+apt-get install p7zip-full sleuthkit
+contrib/macdeploy/extract-osx-sdk.sh
+rm -rf 5.hfs MacOSX10.11.sdk
+```
+
+The Gitian descriptors build 2 sets of files: Linux tools, then Apple binaries
+which are created using these tools. The build process has been designed to
+avoid including the SDK's files in Gitian's outputs. All interim tarballs are
+fully deterministic and may be freely redistributed.
+
+genisoimage is used to create the initial DMG. It is not deterministic as-is,
+so it has been patched. A system genisoimage will work fine, but it will not
+be deterministic because the file-order will change between invocations.
+The patch can be seen here:  [theuni/osx-cross-depends](https://raw.githubusercontent.com/theuni/osx-cross-depends/master/patches/cdrtools/genisoimage.diff).
+No effort was made to fix this cleanly, so it likely leaks memory badly. But
+it's only used for a single invocation, so that's no real concern.
+
+genisoimage cannot compress DMGs, so afterwards, the 'dmg' tool from the
+libdmg-hfsplus project is used to compress it. There are several bugs in this
+tool and its maintainer has seemingly abandoned the project. It has been forked
+and is available (with fixes) here: [theuni/libdmg-hfsplus](https://github.com/theuni/libdmg-hfsplus).
+
+The 'dmg' tool has the ability to create DMGs from scratch as well, but this
+functionality is broken. Only the compression feature is currently used.
+Ideally, the creation could be fixed and genisoimage would no longer be necessary.
+
+Background images and other features can be added to DMG files by inserting a
+.DS_Store before creation. This is generated by the script
+contrib/macdeploy/custom_dsstore.py.
+
+As of OS X 10.9 Mavericks, using an Apple-blessed key to sign binaries is a
+requirement in order to satisfy the new Gatekeeper requirements. Because this
+private key cannot be shared, we'll have to be a bit creative in order for the
+build process to remain somewhat deterministic. Here's how it works:
+
+- Builders use Gitian to create an unsigned release. This outputs an unsigned
+  dmg which users may choose to bless and run. It also outputs an unsigned app
+  structure in the form of a tarball, which also contains all of the tools
+  that have been previously (deterministically) built in order to create a
+  final dmg.
+- The Apple keyholder uses this unsigned app to create a detached signature,
+  using the script that is also included there. Detached signatures are available from this [repository](https://github.com/bitcoin-core/bitcoin-detached-sigs).
+- Builders feed the unsigned app + detached signature back into Gitian. It
+  uses the pre-built tools to recombine the pieces into a deterministic dmg.
+
@@ -0,0 +1,283 @@
+UNIX BUILD NOTES
+====================
+Some notes on how to build Agrarian Core in Unix.
+
+Note
+---------------------
+Always use absolute paths to configure and compile Agrarian Core and the dependencies,
+For example, when specifying the path of the dependency:
+
+	../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX
+
+Here BDB_PREFIX must be an absolute path - it is defined using $(pwd) which ensures
+the usage of the absolute path.
+
+To Build
+---------------------
+
+```bash
+./autogen.sh
+./configure
+make
+make install # optional
+```
+
+This will build agrarian-qt as well, if the dependencies are met.
+
+Dependencies
+---------------------
+
+These dependencies are required:
+
+ Library     | Purpose            | Description
+ ------------|--------------------|----------------------
+ libssl      | Crypto             | Random Number Generation, Elliptic Curve Cryptography
+ libboost    | Utility            | Library for threading, data structures, etc
+ libevent    | Networking         | OS independent asynchronous networking
+ libgmp      | Bignum Arithmetic  | Precision arithmetic
+
+Optional dependencies:
+
+ Library     | Purpose          | Description
+ ------------|------------------|----------------------
+ miniupnpc   | UPnP Support     | Firewall-jumping support
+ libdb4.8    | Berkeley DB      | Wallet storage (only needed when wallet enabled)
+ qt          | GUI              | GUI toolkit (only needed when GUI enabled)
+ protobuf    | Payments in GUI  | Data interchange format used for payment protocol (only needed when GUI enabled)
+ libqrencode | QR codes in GUI  | Optional for generating QR codes (only needed when GUI enabled)
+ univalue    | Utility          | JSON parsing and encoding (bundled version will be used unless --with-system-univalue passed to configure)
+ libzmq3     | ZMQ notification | Optional, allows generating ZMQ notifications (requires ZMQ version >= 4.0.0)
+
+For the versions used, see [dependencies.md](dependencies.md)
+
+Memory Requirements
+--------------------
+
+C++ compilers are memory-hungry. It is recommended to have at least 1.5 GB of
+memory available when compiling Agrarian Core. On systems with less, gcc can be
+tuned to conserve memory with additional CXXFLAGS:
+
+
+    ./configure CXXFLAGS="--param ggc-min-expand=1 --param ggc-min-heapsize=32768"
+
+
+## Linux Distribution Specific Instructions
+
+### Ubuntu & Debian
+
+#### Dependency Build Instructions
+
+Build requirements:
+
+    sudo apt-get install build-essential libtool bsdmainutils autotools-dev autoconf pkg-config automake python3
+
+Now, you can either build from self-compiled [depends](/depends/README.md) or install the required dependencies:
+
+    sudo apt-get install libssl-dev libgmp-dev libevent-dev libboost-all-dev
+
+**Note:** For Ubuntu versions starting with Bionic (18.04), or Debian versions starting with Stretch, use `libssl1.0-dev`
+above instead of `libssl-dev`. Agrarian Core does not support the use of OpenSSL 1.1, though compilation is still possible
+by passing `--with-incompatible-ssl` to configure (NOT RECOMMENDED!).
+
+BerkeleyDB is required for the wallet.
+
+ **For Ubuntu only:** db4.8 packages are available [here](https://launchpad.net/~bitcoin/+archive/bitcoin).
+ You can add the repository using the following command:
+
+    sudo apt-get install software-properties-common
+    sudo add-apt-repository ppa:bitcoin/bitcoin
+    sudo apt-get update
+    sudo apt-get install libdb4.8-dev libdb4.8++-dev
+
+Ubuntu and Debian have their own libdb-dev and libdb++-dev packages, but these will install
+BerkeleyDB 5.1 or later. This will break binary wallet compatibility with the distributed executables, which
+are based on BerkeleyDB 4.8. If you do not care about wallet compatibility,
+pass `--with-incompatible-bdb` to configure.
+
+Otherwise, you can build from self-compiled `depends` (see above).
+
+To build Agrarian Core without wallet, see [*Disable-wallet mode*](/doc/build-unix.md#disable-wallet-mode)
+
+
+Optional (see --with-miniupnpc and --enable-upnp-default):
+
+    sudo apt-get install libminiupnpc-dev
+
+ZMQ dependencies (provides ZMQ API):
+
+    sudo apt-get install libzmq3-dev
+
+GUI dependencies:
+
+If you want to build agrarian-qt, make sure that the required packages for Qt development
+are installed. Qt 5 is necessary to build the GUI.
+To build without GUI pass `--without-gui`.
+
+To build with Qt 5 you need the following:
+
+    sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler
+
+libqrencode (optional) can be installed with:
+
+    sudo apt-get install libqrencode-dev
+
+Once these are installed, they will be found by configure and a agrarian-qt executable will be
+built by default.
+
+
+### Fedora
+
+#### Dependency Build Instructions
+
+Build requirements:
+
+    sudo dnf install which gcc-c++ libtool make autoconf automake compat-openssl10-devel libevent-devel boost-devel libdb4-devel libdb4-cxx-devel gmp-devel python3
+
+Optional:
+
+    sudo dnf install miniupnpc-devel zeromq-devel
+
+To build with Qt 5 you need the following:
+
+    sudo dnf install qt5-qttools-devel qt5-qtbase-devel protobuf-devel
+
+libqrencode (optional) can be installed with:
+
+    sudo dnf install qrencode-devel
+
+Notes
+-----
+The release is built with GCC and then "strip agrariand" to strip the debug
+symbols, which reduces the executable size by about 90%.
+
+
+miniupnpc
+---------
+
+[miniupnpc](http://miniupnp.free.fr/) may be used for UPnP port mapping.  It can be downloaded from [here](
+http://miniupnp.tuxfamily.org/files/).  UPnP support is compiled in and
+turned off by default.  See the configure options for upnp behavior desired:
+
+	--without-miniupnpc      No UPnP support miniupnp not required
+	--disable-upnp-default   (the default) UPnP support turned off by default at runtime
+	--enable-upnp-default    UPnP support turned on by default at runtime
+
+To build:
+
+    tar -xzvf miniupnpc-1.6.tar.gz
+    cd miniupnpc-1.6
+    make
+    sudo su
+    make install
+
+
+Berkeley DB
+-----------
+It is recommended to use Berkeley DB 4.8. If you have to build it yourself,
+you can use [the installation script included in contrib/](/contrib/install_db4.sh)
+like so:
+
+```shell
+./contrib/install_db4.sh `pwd`
+```
+
+from the root of the repository.
+
+**Note**: You only need Berkeley DB if the wallet is enabled (see [*Disable-wallet mode*](/doc/build-unix.md#disable-wallet-mode)).
+
+Boost
+-----
+If you need to build Boost yourself:
+
+	sudo su
+	./bootstrap.sh
+	./bjam install
+
+
+Security
+--------
+To help make your Agrarian Core installation more secure by making certain attacks impossible to
+exploit even if a vulnerability is found, binaries are hardened by default.
+This can be disabled with:
+
+Hardening Flags:
+
+	./configure --enable-hardening
+	./configure --disable-hardening
+
+
+Hardening enables the following features:
+* _Position Independent Executable_: Build position independent code to take advantage of Address Space Layout Randomization
+    offered by some kernels. Attackers who can cause execution of code at an arbitrary memory
+    location are thwarted if they don't know where anything useful is located.
+    The stack and heap are randomly located by default, but this allows the code section to be
+    randomly located as well.
+
+    On an AMD64 processor where a library was not compiled with -fPIC, this will cause an error
+    such as: "relocation R_X86_64_32 against `......' can not be used when making a shared object;"
+
+    To test that you have built PIE executable, install scanelf, part of paxutils, and use:
+
+    	scanelf -e ./agrariand
+
+    The output should contain:
+
+     TYPE
+    ET_DYN
+
+* _Non-executable Stack_: If the stack is executable then trivial stack-based buffer overflow exploits are possible if
+    vulnerable buffers are found. By default, Agrarian Core should be built with a non-executable stack
+    but if one of the libraries it uses asks for an executable stack or someone makes a mistake
+    and uses a compiler extension which requires an executable stack, it will silently build an
+    executable without the non-executable stack protection.
+
+    To verify that the stack is non-executable after compiling use:
+    `scanelf -e ./agrariand`
+
+    The output should contain:
+	STK/REL/PTL
+	RW- R-- RW-
+
+    The STK RW- means that the stack is readable and writeable but not executable.
+
+Disable-wallet mode
+--------------------
+**Note:** This functionality is not yet completely implemented, and compilation using the below option will currently fail.
+
+When the intention is to run only a P2P node without a wallet, Agrarian Core may be compiled in
+disable-wallet mode with:
+
+    ./configure --disable-wallet
+
+In this case there is no dependency on Berkeley DB 4.8.
+
+
+Additional Configure Flags
+--------------------------
+A list of additional configure flags can be displayed with:
+
+    ./configure --help
+
+
+ARM Cross-compilation
+-------------------
+These steps can be performed on, for example, an Ubuntu VM. The depends system
+will also work on other Linux distributions, however the commands for
+installing the toolchain will be different.
+
+Make sure you install the build requirements mentioned above.
+Then, install the toolchain and curl:
+
+    sudo apt-get install g++-arm-linux-gnueabihf curl
+
+To build executables for ARM:
+
+    cd depends
+    make HOST=arm-linux-gnueabihf NO_QT=1
+    cd ..
+    ./autogen.sh
+    ./configure --prefix=$PWD/depends/arm-linux-gnueabihf --enable-glibc-back-compat --enable-reduce-exports LDFLAGS=-static-libstdc++
+    make
+
+
+For further documentation on the depends system see [README.md](../depends/README.md) in the depends directory.
@@ -0,0 +1,151 @@
+WINDOWS BUILD NOTES
+====================
+
+Below are some notes on how to build Agrarian Core for Windows.
+
+The options known to work for building Agrarian Core on Windows are:
+
+* On Linux, using the [Mingw-w64](https://mingw-w64.org/doku.php) cross compiler tool chain. Ubuntu Bionic 18.04 is required
+and is the platform used to build the Agrarian Core Windows release binaries.
+* On Windows, using [Windows
+Subsystem for Linux (WSL)](https://msdn.microsoft.com/commandline/wsl/about) and the Mingw-w64 cross compiler tool chain.
+
+Other options which may work, but which have not been extensively tested are (please contribute instructions):
+
+* On Windows, using a POSIX compatibility layer application such as [cygwin](http://www.cygwin.com/) or [msys2](http://www.msys2.org/).
+* On Windows, using a native compiler tool chain such as [Visual Studio](https://www.visualstudio.com).
+
+Installing Windows Subsystem for Linux
+---------------------------------------
+
+With Windows 10, Microsoft has released a new feature named the [Windows
+Subsystem for Linux (WSL)](https://msdn.microsoft.com/commandline/wsl/about). This
+feature allows you to run a bash shell directly on Windows in an Ubuntu-based
+environment. Within this environment you can cross compile for Windows without
+the need for a separate Linux VM or server. Note that while WSL can be installed with
+other Linux variants, such as OpenSUSE, the following instructions have only been
+tested with Ubuntu.
+
+This feature is not supported in versions of Windows prior to Windows 10 or on
+Windows Server SKUs. In addition, it is available [only for 64-bit versions of
+Windows](https://msdn.microsoft.com/en-us/commandline/wsl/install_guide).
+
+Full instructions to install WSL are available on the above link.
+To install WSL on Windows 10 with Fall Creators Update installed (version >= 16215.0) do the following:
+
+1. Enable the Windows Subsystem for Linux feature
+  * Open the Windows Features dialog (`OptionalFeatures.exe`)
+  * Enable 'Windows Subsystem for Linux'
+  * Click 'OK' and restart if necessary
+2. Install Ubuntu
+  * Open Microsoft Store and search for "Ubuntu 18.04" or use [this link](https://www.microsoft.com/store/productId/9N9TNGVNDL3Q)
+  * Click Install
+3. Complete Installation
+  * Open a cmd prompt and type "Ubuntu1804"
+  * Create a new UNIX user account (this is a separate account from your Windows account)
+
+After the bash shell is active, you can follow the instructions below, starting
+with the "Cross-compilation" section. Compiling the 64-bit version is
+recommended, but it is possible to compile the 32-bit version.
+
+Cross-compilation for Ubuntu and Windows Subsystem for Linux
+------------------------------------------------------------
+
+The steps below can be performed on Ubuntu (including in a VM) or WSL. The depends system
+will also work on other Linux distributions, however the commands for
+installing the toolchain will be different.
+
+First, install the general dependencies:
+
+    sudo apt update
+    sudo apt upgrade
+    sudo apt install build-essential libtool autotools-dev automake pkg-config bsdmainutils curl git
+
+A host toolchain (`build-essential`) is necessary because some dependency
+packages (such as `protobuf`) need to build host utilities that are used in the
+build process.
+
+See [dependencies.md](dependencies.md) for a complete overview.
+
+If you want to build the windows installer with `make deploy` you need [NSIS](https://nsis.sourceforge.io/Main_Page):
+
+    sudo apt install nsis
+
+Acquire the source in the usual way:
+
+    git clone https://github.com/agrarian-project/agrarian.git
+    cd agrarian
+
+## Building for 64-bit Windows
+
+The first step is to install the mingw-w64 cross-compilation tool chain:
+
+    sudo apt install g++-mingw-w64-x86-64
+
+Ubuntu Bionic 18.04 <sup>[1](#footnote1)</sup>:
+
+    sudo update-alternatives --config x86_64-w64-mingw32-g++ # Set the default mingw32 g++ compiler option to posix.
+
+Once the toolchain is installed the build steps are common:
+
+Note that for WSL the Agrarian Core source path MUST be somewhere in the default mount file system, for
+example /usr/src/agrarian, AND not under /mnt/d/. If this is not the case the dependency autoconf scripts will fail.
+This means you cannot use a directory that is located directly on the host Windows file system to perform the build.
+
+Build using:
+
+    PATH=$(echo "$PATH" | sed -e 's/:\/mnt.*//g') # strip out problematic Windows %PATH% imported var
+    cd depends
+    make HOST=x86_64-w64-mingw32
+    cd ..
+    ./autogen.sh # not required when building from tarball
+    CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure --prefix=/
+    make
+
+## Building for 32-bit Windows
+
+To build executables for Windows 32-bit, install the following dependencies:
+
+    sudo apt install g++-mingw-w64-i686 mingw-w64-i686-dev
+
+Ubuntu Bionic 18.04 <sup>[1](#footnote1)</sup>:
+
+    sudo update-alternatives --config i686-w64-mingw32-g++  # Set the default mingw32 g++ compiler option to posix.
+
+Build using:
+
+    PATH=$(echo "$PATH" | sed -e 's/:\/mnt.*//g') # strip out problematic Windows %PATH% imported var
+    cd depends
+    make HOST=i686-w64-mingw32
+    cd ..
+    ./autogen.sh # not required when building from tarball
+    CONFIG_SITE=$PWD/depends/i686-w64-mingw32/share/config.site ./configure --prefix=/
+    make
+
+## Depends system
+
+For further documentation on the depends system see [README.md](../depends/README.md) in the depends directory.
+
+Installation
+-------------
+
+After building using the Windows subsystem it can be useful to copy the compiled
+executables to a directory on the Windows drive in the same directory structure
+as they appear in the release `.zip` archive. This can be done in the following
+way. This will install to `c:\workspace\agrarian`, for example:
+
+    make install DESTDIR=/mnt/c/workspace/agrarian
+
+You can also create an installer using:
+
+    make deploy
+
+Footnotes
+---------
+
+<a name="footnote1">1</a>: Starting from Ubuntu Xenial 16.04, both the 32 and 64 bit Mingw-w64 packages install two different
+compiler options to allow a choice between either posix or win32 threads. The default option is win32 threads which is the more
+efficient since it will result in binary code that links directly with the Windows kernel32.lib. Unfortunately, the headers
+required to support win32 threads conflict with some of the classes in the C++11 standard library, in particular std::mutex.
+It's not possible to build the Agrarian Core code using the win32 version of the Mingw-w64 cross compilers (at least not without
+modifying headers in the Agrarian Core source code).
@@ -0,0 +1,46 @@
+Dependencies
+============
+
+These are the dependencies currently used by Agrarian Core. You can find instructions for installing them in the `build-*.md` file for your platform.
+
+| Dependency | Version used | Minimum required | CVEs | Shared | [Bundled Qt library](https://doc.qt.io/qt-5/configure-options.html#third-party-libraries) |
+| --- | --- | --- | --- | --- | --- |
+| Berkeley DB | [4.8.30](https://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index.html) | 4.8.x | No |  |  |
+| Boost | [1.64.0](https://www.boost.org/users/download/) | [1.47.0](https://github.com/bitcoin/bitcoin/pull/8920) | No |  |  |
+| Clang |  | [3.3+](https://llvm.org/releases/download.html) (C++11 support) |  |  |  |
+| D-Bus | [1.10.18](https://cgit.freedesktop.org/dbus/dbus/tree/NEWS?h=dbus-1.10) |  | No | Yes |  |
+| Expat | [2.2.6](https://libexpat.github.io/) |  | No | Yes |  |
+| fontconfig | [2.12.1](https://www.freedesktop.org/software/fontconfig/release/) |  | No | Yes |  |
+| FreeType | [2.7.1](https://download.savannah.gnu.org/releases/freetype) |  | No |  |  |
+| GCC |  | [4.8+](https://gcc.gnu.org/) (C++11 support) |  |  |  |
+| HarfBuzz-NG |  |  |  |  |  |
+| libevent | [2.1.8-stable](https://github.com/libevent/libevent/releases) | 2.0.22 | No |  |  |
+| libjpeg |  |  |  |  | [Yes](https://github.com/agrarian-project/agrarian/blob/master/depends/packages/qt.mk#L65) |
+| libpng |  |  |  |  | [Yes](https://github.com/agrarian-project/agrarian/blob/master/depends/packages/qt.mk#L64) |
+| librsvg | |  |  |  |  |
+| MiniUPnPc | [2.0.20180203](http://miniupnp.free.fr/files) |  | No |  |  |
+| OpenSSL | [1.0.1k](https://www.openssl.org/source) |  | Yes |  |  |
+| GMP | [6.1.2](https://gmplib.org/) | | No | | |
+| PCRE |  |  |  |  | [Yes](https://github.com/agrarian-project/agrarian/blob/master/depends/packages/qt.mk#L66) |
+| protobuf | [2.6.1](https://github.com/google/protobuf/releases) |  | No |  |  |
+| Python (tests) |  | [3.5](https://www.python.org/downloads) |  |  |  |
+| qrencode | [3.4.4](https://fukuchi.org/works/qrencode) |  | No |  |  |
+| Qt | [5.9.7](https://download.qt.io/official_releases/qt/) | [5.5.1](https://github.com/bitcoin/bitcoin/issues/13478) | No |  |  |
+| XCB |  |  |  |  | [Yes](https://github.com/agrarian-project/agrarian/blob/master/depends/packages/qt.mk#L87) (Linux only) |
+| xkbcommon |  |  |  |  | [Yes](https://github.com/agrarian-project/agrarian/blob/master/depends/packages/qt.mk#L86) (Linux only) |
+| ZeroMQ | [4.3.1](https://github.com/zeromq/libzmq/releases) | 4.0.0 | No |  |  |
+| zlib | [1.2.11](https://zlib.net/) |  |  |  | No |
+
+Controlling dependencies
+------------------------
+Some dependencies are not needed in all configurations. The following are some factors that affect the dependency list.
+
+#### Options passed to `./configure`
+* MiniUPnPc is not needed with  `--with-miniupnpc=no`.
+* Berkeley DB is not needed with `--disable-wallet`.
+* Qt is not needed with `--without-gui`.
+* If the qrencode dependency is absent, QR support won't be added. To force an error when that happens, pass `--with-qrencode`.
+* ZeroMQ is needed only with the `--with-zmq` option.
+
+#### Other
+* librsvg is only needed if you need to run `make deploy` on (cross-compilation to) macOS.
@@ -0,0 +1,905 @@
+Developer Notes
+===============
+
+<!-- markdown-toc start -->
+**Table of Contents**
+
+- [Developer Notes](#developer-notes)
+    - [Coding Style (General)](#coding-style-general)
+    - [Coding Style (C++)](#coding-style-c)
+    - [Coding Style (Python)](#coding-style-python)
+    - [Coding Style (Doxygen-compatible comments)](#coding-style-doxygen-compatible-comments)
+    - [Development tips and tricks](#development-tips-and-tricks)
+        - [Compiling for debugging](#compiling-for-debugging)
+        - [Compiling for gprof profiling](#compiling-for-gprof-profiling)
+        - [debug.log](#debuglog)
+        - [Testnet and Regtest modes](#testnet-and-regtest-modes)
+        - [DEBUG_LOCKORDER](#debug_lockorder)
+        - [Valgrind suppressions file](#valgrind-suppressions-file)
+        - [Compiling for test coverage](#compiling-for-test-coverage)
+        - [Performance profiling with perf](#performance-profiling-with-perf)
+    - [Locking/mutex usage notes](#lockingmutex-usage-notes)
+    - [Threads](#threads)
+    - [Ignoring IDE/editor files](#ignoring-ideeditor-files)
+- [Development guidelines](#development-guidelines)
+    - [General Agrarian Core](#general-agrarian-core)
+    - [Wallet](#wallet)
+    - [General C++](#general-c)
+    - [C++ data structures](#c-data-structures)
+    - [Strings and formatting](#strings-and-formatting)
+    - [Variable names](#variable-names)
+    - [Threads and synchronization](#threads-and-synchronization)
+    - [Scripts](#scripts)
+        - [Shebang](#shebang)
+    - [Source code organization](#source-code-organization)
+    - [GUI](#gui)
+    - [Subtrees](#subtrees)
+    - [Upgrading LevelDB](#upgrading-leveldb)
+    - [Scripted diffs](#scripted-diffs)
+    - [Git and GitHub tips](#git-and-github-tips)
+    - [Release notes](#release-notes)
+    - [RPC interface guidelines](#rpc-interface-guidelines)
+
+<!-- markdown-toc end -->
+
+Coding Style (General)
+----------------------
+
+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, which is specified below. When writing patches, favor the new
+style over attempting to mimic the surrounding style, except for move-only
+commits.
+
+Coding Style (C++)
+------------------
+
+- **Indentation and whitespace rules** as specified in
+[src/.clang-format](/src/.clang-format). You can use the provided
+[clang-format-diff script](/contrib/devtools/README.md#clang-format-diffpy)
+tool to clean up patches automatically before submission.
+  - Braces on new lines for classes, functions, methods.
+  - Braces on the same line for everything else.
+  - 4 space indentation (no tabs) for every block except namespaces.
+  - No indentation for `public`/`protected`/`private` or for `namespace`.
+  - No extra spaces inside parenthesis; don't do ( this )
+  - No space after function names; one space after `if`, `for` and `while`.
+  - If an `if` only has a single-statement `then`-clause, it can appear
+    on the same line as the `if`, without braces. In every other case,
+    braces are required, and the `then` and `else` clauses must appear
+    correctly indented on a new line.
+
+- **Symbol naming conventions**. These are preferred in new code, but are not
+required when doing so would need changes to significant pieces of existing
+code.
+  - Constant names are all uppercase, and use `_` to separate words.
+  - Class names, function names and method names are UpperCamelCase
+    (PascalCase). Do not prefix class names with `C`.
+  - Test suite naming convention: The Boost test suite in file
+    `src/test/foo_tests.cpp` should be named `foo_tests`. Test suite names
+    must be unique.
+
+- **Miscellaneous**
+  - `++i` is preferred over `i++`.
+  - `nullptr` is preferred over `NULL` or `(void*)0`.
+  - `static_assert` is preferred over `assert` where possible. Generally; compile-time checking is preferred over run-time checking.
+  - `enum class` is preferred over `enum` where possible. Scoped enumerations avoid two potential pitfalls/problems with traditional C++ enumerations: implicit conversions to int, and name clashes due to enumerators being exported to the surrounding scope.
+
+Block style example:
+```c++
+int g_count = 0;
+
+namespace foo {
+class Class
+{
+    std::string m_name;
+
+public:
+    bool Function(const std::string& s, int n)
+    {
+        // Comment summarising what this section of code does
+        for (int i = 0; i < n; ++i) {
+            int total_sum = 0;
+            // When something fails, return early
+            if (!Something()) return false;
+            ...
+            if (SomethingElse(i)) {
+                total_sum += ComputeSomething(g_count);
+            } else {
+                DoSomething(m_name, total_sum);
+            }
+        }
+
+        // Success return is usually at the end
+        return true;
+    }
+}
+} // namespace foo
+```
+
+Coding Style (Python)
+---------------------
+
+Refer to [/test/functional/README.md#style-guidelines](/test/functional/README.md#style-guidelines).
+
+Coding Style (Doxygen-compatible comments)
+------------------------------------------
+
+Agrarian Core uses [Doxygen](http://www.doxygen.nl/) to generate its official documentation.
+
+Use Doxygen-compatible comment blocks for functions, methods, and fields.
+
+For example, to describe a function use:
+```c++
+/**
+ * ... text ...
+ * @param[in] arg1    A description
+ * @param[in] arg2    Another argument description
+ * @pre Precondition for function...
+ */
+bool function(int arg1, const char *arg2)
+```
+A complete list of `@xxx` commands can be found at http://www.doxygen.nl/manual/commands.html.
+As Doxygen recognizes the comments by the delimiters (`/**` and `*/` in this case), you don't
+*need* to provide any commands for a comment to be valid; just a description text is fine.
+
+To describe a class use the same construct above the class definition:
+```c++
+/**
+ * Alerts are for notifying old versions if they become too obsolete and
+ * need to upgrade. The message is displayed in the status bar.
+ * @see GetWarnings()
+ */
+class CAlert
+{
+```
+
+To describe a member or variable use:
+```c++
+int var; //!< Detailed description after the member
+```
+
+or
+```c++
+//! Description before the member
+int var;
+```
+
+Also OK:
+```c++
+///
+/// ... text ...
+///
+bool function2(int arg1, const char *arg2)
+```
+
+Not OK (used plenty in the current source, but not picked up):
+```c++
+//
+// ... text ...
+//
+```
+
+A full list of comment syntaxes picked up by Doxygen can be found at http://www.doxygen.nl/manual/docblocks.html,
+but the above styles are favored.
+
+Documentation can be generated with `make docs` and cleaned up with `make clean-docs`. The resulting files are located in `doc/doxygen/html`; open `index.html` to view the homepage.
+
+Before running `make docs`, you will need to install dependencies `doxygen` and `dot`. For example, on MacOS via Homebrew:
+```
+brew install doxygen
+```
+
+Development tips and tricks
+---------------------------
+
+### Compiling for debugging
+
+Run configure with `--enable-debug` to add additional compiler flags that
+produce better debugging builds.
+
+### Compiling for gprof profiling
+
+Run configure with the `--enable-gprof` option, then make.
+
+### debug.log
+
+If the code is behaving strangely, take a look in the debug.log file in the data directory;
+error and debugging messages are written there.
+
+The `-debug=...` command-line option controls debugging; running with just `-debug` or `-debug=1` will turn
+on all categories (and give you a very large debug.log file).
+
+The Qt code routes `qDebug()` output to debug.log under category "qt": run with `-debug=qt`
+to see it.
+
+### Testnet and Regtest modes
+
+Run with the `-testnet` option to run with "play AGRs (tAGR)" on the test network, if you
+are testing multi-machine code that needs to operate across the internet.
+
+If you are testing something that can run on one machine, run with the `-regtest` option.
+In regression test mode, blocks can be created on-demand; see [test/functional/](/test/functional) for tests
+that run in `-regtest` mode.
+
+### DEBUG_LOCKORDER
+
+Agrarian Core is a multi-threaded application, and deadlocks or other
+multi-threading bugs can be very difficult to track down. The `--enable-debug`
+configure option adds `-DDEBUG_LOCKORDER` to the compiler flags. This inserts
+run-time checks to keep track of which locks are held, and adds warnings to the
+debug.log file if inconsistencies are detected.
+
+### Valgrind suppressions file
+
+Valgrind is a programming tool for memory debugging, memory leak detection, and
+profiling. The repo contains a Valgrind suppressions file
+([`valgrind.supp`](https://github.com/agrarian-project/agrarian/blob/master/contrib/valgrind.supp))
+which includes known Valgrind warnings in our dependencies that cannot be fixed
+in-tree. Example use:
+
+```shell
+$ valgrind --suppressions=contrib/valgrind.supp src/test/test_agrarian
+$ valgrind --suppressions=contrib/valgrind.supp --leak-check=full \
+      --show-leak-kinds=all src/test/test_agrarian --log_level=test_suite
+$ valgrind -v --leak-check=full src/agrariand -printtoconsole
+```
+
+### Compiling for test coverage
+
+LCOV can be used to generate a test coverage report based upon `make check`
+execution. LCOV must be installed on your system (e.g. the `lcov` package
+on Debian/Ubuntu).
+
+To enable LCOV report generation during test runs:
+
+```shell
+./configure --enable-lcov
+make
+make cov
+
+# A coverage report will now be accessible at `./test_agrarian.coverage/index.html`.
+```
+
+Locking/mutex usage notes
+-------------------------
+
+The code is multi-threaded, and uses mutexes and the
+`LOCK` and `TRY_LOCK` macros to protect data structures.
+
+Deadlocks due to inconsistent lock ordering (thread 1 locks `cs_main` and then
+`cs_wallet`, while thread 2 locks them in the opposite order: result, deadlock
+as each waits for the other to release its lock) are a problem. Compile with
+`-DDEBUG_LOCKORDER` (or use `--enable-debug`) to get lock order inconsistencies
+reported in the debug.log file.
+
+Re-architecting the core code so there are better-defined interfaces
+between the various components is a goal, with any necessary locking
+done by the components (e.g. see the self-contained `CKeyStore` class
+and its `cs_KeyStore` lock for example).
+
+Threads
+-------
+
+- ThreadScriptCheck : Verifies block scripts.
+
+- ThreadImport : Loads blocks from blk*.dat files or bootstrap.dat.
+
+- StartNode : Starts other threads.
+
+- ThreadDNSAddressSeed : Loads addresses of peers from the DNS.
+
+- ThreadMapPort : Universal plug-and-play startup/shutdown
+
+- ThreadSocketHandler : Sends/Receives data from peers on port 8333.
+
+- ThreadOpenAddedConnections : Opens network connections to added nodes.
+
+- ThreadOpenConnections : Initiates new connections to peers.
+
+- ThreadMessageHandler : Higher-level message handling (sending and receiving).
+
+- DumpAddresses : Dumps IP addresses of nodes to peers.dat.
+
+- ThreadFlushWalletDB : Close the wallet.dat file if it hasn't been used in 500ms.
+
+- ThreadRPCServer : Remote procedure call handler, listens on port 8332 for connections and services them.
+
+- BitcoinMiner : Generates AGRs (if wallet is enabled).
+
+- Shutdown : Does an orderly shutdown of everything.
+
+Ignoring IDE/editor files
+--------------------------
+
+In closed-source environments in which everyone uses the same IDE it is common
+to add temporary files it produces to the project-wide `.gitignore` file.
+
+However, in open source software such as Agrarian Core, where everyone uses
+their own editors/IDE/tools, it is less common. Only you know what files your
+editor produces and this may change from version to version. The canonical way
+to do this is thus to create your local gitignore. Add this to `~/.gitconfig`:
+
+```
+[core]
+        excludesfile = /home/.../.gitignore_global
+```
+
+(alternatively, type the command `git config --global core.excludesfile ~/.gitignore_global`
+on a terminal)
+
+Then put your favourite tool's temporary filenames in that file, e.g.
+```
+# NetBeans
+nbproject/
+```
+
+Another option is to create a per-repository excludes file `.git/info/exclude`.
+These are not committed but apply only to one repository.
+
+If a set of tools is used by the build system or scripts the repository (for
+example, lcov) it is perfectly acceptable to add its files to `.gitignore`
+and commit them.
+
+Development guidelines
+============================
+
+A few non-style-related recommendations for developers, as well as points to
+pay attention to for reviewers of Agrarian Core code.
+
+General Agrarian Core
+----------------------
+
+- New features should be exposed on RPC first, then can be made available in the GUI
+
+  - *Rationale*: RPC allows for better automatic testing. The test suite for
+    the GUI is very limited
+
+- Make sure pull requests pass Travis CI before merging
+
+  - *Rationale*: Makes sure that they pass thorough testing, and that the tester will keep passing
+     on the master branch. Otherwise all new pull requests will start failing the tests, resulting in
+     confusion and mayhem
+
+  - *Explanation*: If the test suite is to be updated for a change, this has to
+    be done first
+
+Wallet
+-------
+
+- Make sure that no crashes happen with run-time option `-disablewallet`.
+
+  - *Rationale*: In RPC code that conditionally uses the wallet (such as
+    `validateaddress`) it is easy to forget that global pointer `pwalletMain`
+    can be nullptr. See `test/functional/disablewallet.py` for functional tests
+    exercising the API with `-disablewallet`
+
+- Include `db_cxx.h` (BerkeleyDB header) only when `ENABLE_WALLET` is set
+
+  - *Rationale*: Otherwise compilation of the disable-wallet build will fail in environments without BerkeleyDB
+
+General C++
+-------------
+
+For general C++ guidelines, you may refer to the [C++ Core
+Guidelines](https://isocpp.github.io/CppCoreGuidelines/).
+
+Common misconceptions are clarified in those sections:
+
+- Passing (non-)fundamental types in the [C++ Core
+  Guideline](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-conventional)
+
+- Assertions should not have side-effects
+
+  - *Rationale*: Even though the source code is set to refuse to compile
+    with assertions disabled, having side-effects in assertions is unexpected and
+    makes the code harder to understand
+
+- If you use the `.h`, you must link the `.cpp`
+
+  - *Rationale*: Include files define the interface for the code in implementation files. Including one but
+      not linking the other is confusing. Please avoid that. Moving functions from
+      the `.h` to the `.cpp` should not result in build errors
+
+- Use the RAII (Resource Acquisition Is Initialization) paradigm where possible. For example by using
+  `unique_ptr` for allocations in a function.
+
+  - *Rationale*: This avoids memory and resource leaks, and ensures exception safety
+
+C++ data structures
+--------------------
+
+- Never use the `std::map []` syntax when reading from a map, but instead use `.find()`
+
+  - *Rationale*: `[]` does an insert (of the default element) if the item doesn't
+    exist in the map yet. This has resulted in memory leaks in the past, as well as
+    race conditions (expecting read-read behavior). Using `[]` is fine for *writing* to a map
+
+- Do not compare an iterator from one data structure with an iterator of
+  another data structure (even if of the same type)
+
+  - *Rationale*: Behavior is undefined. In C++ parlor this means "may reformat
+    the universe", in practice this has resulted in at least one hard-to-debug crash bug
+
+- Watch out for out-of-bounds vector access. `&vch[vch.size()]` is illegal,
+  including `&vch[0]` for an empty vector. Use `vch.data()` and `vch.data() +
+  vch.size()` instead.
+
+- Vector bounds checking is only enabled in debug mode. Do not rely on it
+
+- Initialize all non-static class members where they are defined.
+  If this is skipped for a good reason (i.e., optimization on the critical
+  path), add an explicit comment about this
+
+  - *Rationale*: Ensure determinism by avoiding accidental use of uninitialized
+    values. Also, static analyzers balk about this.
+    Initializing the members in the declaration makes it easy to
+    spot uninitialized ones.
+
+```cpp
+class A
+{
+    uint32_t m_count{0};
+}
+```
+
+- By default, declare single-argument constructors `explicit`.
+
+  - *Rationale*: This is a precaution to avoid unintended conversions that might
+    arise when single-argument constructors are used as implicit conversion
+    functions.
+
+- Use explicitly signed or unsigned `char`s, or even better `uint8_t` and
+  `int8_t`. Do not use bare `char` unless it is to pass to a third-party API.
+  This type can be signed or unsigned depending on the architecture, which can
+  lead to interoperability problems or dangerous conditions such as
+  out-of-bounds array accesses
+
+- Prefer explicit constructions over implicit ones that rely on 'magical' C++ behavior
+
+  - *Rationale*: Easier to understand what is happening, thus easier to spot mistakes, even for those
+  that are not language lawyers
+
+Strings and formatting
+------------------------
+
+- Be careful of `LogPrint` versus `LogPrintf`. `LogPrint` takes a `category` argument, `LogPrintf` does not.
+
+  - *Rationale*: Confusion of these can result in runtime exceptions due to
+    formatting mismatch, and it is easy to get wrong because of subtly similar naming
+
+- Use `std::string`, avoid C string manipulation functions
+
+  - *Rationale*: C++ string handling is marginally safer, less scope for
+    buffer overflows and surprises with `\0` characters. Also some C string manipulations
+    tend to act differently depending on platform, or even the user locale
+
+- Use `ParseInt32`, `ParseInt64`, `ParseUInt32`, `ParseUInt64`, `ParseDouble` from `utilstrencodings.h` for number parsing
+
+  - *Rationale*: These functions do overflow checking, and avoid pesky locale issues.
+
+- Avoid using locale dependent functions if possible. You can use the provided
+  [`lint-locale-dependence.sh`](/test/lint/lint-locale-dependence.sh)
+  to check for accidental use of locale dependent functions.
+
+  - *Rationale*: Unnecessary locale dependence can cause bugs that are very tricky to isolate and fix.
+
+  - These functions are known to be locale dependent:
+    `alphasort`, `asctime`, `asprintf`, `atof`, `atoi`, `atol`, `atoll`, `atoq`,
+    `btowc`, `ctime`, `dprintf`, `fgetwc`, `fgetws`, `fprintf`, `fputwc`,
+    `fputws`, `fscanf`, `fwprintf`, `getdate`, `getwc`, `getwchar`, `isalnum`,
+    `isalpha`, `isblank`, `iscntrl`, `isdigit`, `isgraph`, `islower`, `isprint`,
+    `ispunct`, `isspace`, `isupper`, `iswalnum`, `iswalpha`, `iswblank`,
+    `iswcntrl`, `iswctype`, `iswdigit`, `iswgraph`, `iswlower`, `iswprint`,
+    `iswpunct`, `iswspace`, `iswupper`, `iswxdigit`, `isxdigit`, `mblen`,
+    `mbrlen`, `mbrtowc`, `mbsinit`, `mbsnrtowcs`, `mbsrtowcs`, `mbstowcs`,
+    `mbtowc`, `mktime`, `putwc`, `putwchar`, `scanf`, `snprintf`, `sprintf`,
+    `sscanf`, `stoi`, `stol`, `stoll`, `strcasecmp`, `strcasestr`, `strcoll`,
+    `strfmon`, `strftime`, `strncasecmp`, `strptime`, `strtod`, `strtof`,
+    `strtoimax`, `strtol`, `strtold`, `strtoll`, `strtoq`, `strtoul`,
+    `strtoull`, `strtoumax`, `strtouq`, `strxfrm`, `swprintf`, `tolower`,
+    `toupper`, `towctrans`, `towlower`, `towupper`, `ungetwc`, `vasprintf`,
+    `vdprintf`, `versionsort`, `vfprintf`, `vfscanf`, `vfwprintf`, `vprintf`,
+    `vscanf`, `vsnprintf`, `vsprintf`, `vsscanf`, `vswprintf`, `vwprintf`,
+    `wcrtomb`, `wcscasecmp`, `wcscoll`, `wcsftime`, `wcsncasecmp`, `wcsnrtombs`,
+    `wcsrtombs`, `wcstod`, `wcstof`, `wcstoimax`, `wcstol`, `wcstold`,
+    `wcstoll`, `wcstombs`, `wcstoul`, `wcstoull`, `wcstoumax`, `wcswidth`,
+    `wcsxfrm`, `wctob`, `wctomb`, `wctrans`, `wctype`, `wcwidth`, `wprintf`
+
+- For `strprintf`, `LogPrint`, `LogPrintf` formatting characters don't need size specifiers
+
+  - *Rationale*: Agrarian Core uses tinyformat, which is type safe. Leave them out to avoid confusion
+
+Variable names
+--------------
+
+Although the shadowing warning (`-Wshadow`) is not enabled by default (it prevents issues rising
+from using a different variable with the same name),
+please name variables so that their names do not shadow variables defined in the source code.
+
+E.g. in member initializers, prepend `_` to the argument name shadowing the
+member name:
+
+```c++
+class AddressBookPage
+{
+    Mode m_mode;
+}
+
+AddressBookPage::AddressBookPage(Mode _mode)
+    : m_mode(_mode)
+...
+```
+
+When using nested cycles, do not name the inner cycle variable the same as in
+upper cycle etc.
+
+
+Threads and synchronization
+----------------------------
+
+- Build and run tests with `-DDEBUG_LOCKORDER` to verify that no potential
+  deadlocks are introduced. This is defined by default when configuring
+  with `--enable-debug`
+
+- When using `LOCK`/`TRY_LOCK` be aware that the lock exists in the context of
+  the current scope, so surround the statement and the code that needs the lock
+  with braces
+
+  OK:
+
+```c++
+{
+    TRY_LOCK(cs_vNodes, lockNodes);
+    ...
+}
+```
+
+  Wrong:
+
+```c++
+TRY_LOCK(cs_vNodes, lockNodes);
+{
+    ...
+}
+```
+
+Scripts
+--------------------------
+
+### Shebang
+
+- Use `#!/usr/bin/env bash` instead of obsolete `#!/bin/bash`.
+
+  - [*Rationale*](https://github.com/dylanaraps/pure-bash-bible#shebang):
+
+    `#!/bin/bash` assumes it is always installed to /bin/ which can cause issues;
+
+    `#!/usr/bin/env bash` searches the user's PATH to find the bash binary.
+
+  OK:
+
+```bash
+#!/usr/bin/env bash
+```
+
+  Wrong:
+
+```bash
+#!/bin/bash
+```
+
+Source code organization
+--------------------------
+
+- Implementation code should go into the `.cpp` file and not the `.h`, unless necessary due to template usage or
+  when performance due to inlining is critical
+
+  - *Rationale*: Shorter and simpler header files are easier to read, and reduce compile time
+
+- Use only the lowercase alphanumerics (`a-z0-9`), underscore (`_`) and hyphen (`-`) in source code filenames.
+
+  - *Rationale*: `grep`:ing and auto-completing filenames is easier when using a consistent
+    naming pattern. Potential problems when building on case-insensitive filesystems are
+    avoided when using only lowercase characters in source code filenames.
+
+- Every `.cpp` and `.h` file should `#include` every header file it directly uses classes, functions or other
+  definitions from, even if those headers are already included indirectly through other headers.
+
+  - *Rationale*: Excluding headers because they are already indirectly included results in compilation
+    failures when those indirect dependencies change. Furthermore, it obscures what the real code
+    dependencies are.
+
+- Don't import anything into the global namespace (`using namespace ...`). Use
+  fully specified types such as `std::string`.
+
+  - *Rationale*: Avoids symbol conflicts
+
+- Terminate namespaces with a comment (`// namespace mynamespace`). The comment
+  should be placed on the same line as the brace closing the namespace, e.g.
+
+```c++
+namespace mynamespace {
+...
+} // namespace mynamespace
+
+namespace {
+...
+} // namespace
+```
+
+  - *Rationale*: Avoids confusion about the namespace context
+
+- Use include guards to avoid the problem of double inclusion. The header file
+  `foo/bar.h` should use the include guard identifier `BITCOIN_FOO_BAR_H`, e.g.
+
+```c++
+#ifndef BITCOIN_FOO_BAR_H
+#define BITCOIN_FOO_BAR_H
+...
+#endif // BITCOIN_FOO_BAR_H
+```
+
+GUI
+-----
+
+- Do not display or manipulate dialogs in model code (classes `*Model`)
+
+  - *Rationale*: Model classes pass through events and data from the core, they
+    should not interact with the user. That's where View classes come in. The converse also
+    holds: try to not directly access core data structures from Views.
+
+Subtrees
+----------
+
+Several parts of the repository are subtrees of software maintained elsewhere.
+
+Some of these are maintained by active developers of Bitcoin Core, in which case changes should probably go
+directly upstream without being PRed directly against the project.  They will be merged back in the next
+subtree merge.
+
+Others are external projects without a tight relationship with our project.  Changes to these should also
+be sent upstream but bugfixes may also be prudent to PR against Agrarian Core so that they can be integrated
+quickly.  Cosmetic changes should be purely taken upstream.
+
+There is a tool in `test/lint/git-subtree-check.sh` to check a subtree directory for consistency with
+its upstream repository.
+
+Current subtrees include:
+
+- src/leveldb
+  - Upstream at https://github.com/google/leveldb ; Maintained by Google, but
+    open important PRs to Core to avoid delay.
+  - **Note**: Follow the instructions in [Upgrading LevelDB](#upgrading-leveldb) when
+    merging upstream changes to the LevelDB subtree.
+
+- src/libsecp256k1
+  - Upstream at https://github.com/bitcoin-core/secp256k1/ ; actively maintained by Core contributors.
+
+- src/univalue
+  - Upstream at https://github.com/bitcoin-core/univalue ; actively maintained by Core contributors, deviates from upstream https://github.com/jgarzik/univalue
+
+Upgrading LevelDB
+---------------------
+
+Extra care must be taken when upgrading LevelDB. This section explains issues
+you must be aware of.
+
+### File Descriptor Counts
+
+In most configurations we use the default LevelDB value for `max_open_files`,
+which is 1000 at the time of this writing. If LevelDB actually uses this many
+file descriptors it will cause problems with Agrarian's `select()` loop, because
+it may cause new sockets to be created where the fd value is >= 1024. For this
+reason, on 64-bit Unix systems we rely on an internal LevelDB optimization that
+uses `mmap()` + `close()` to open table files without actually retaining
+references to the table file descriptors. If you are upgrading LevelDB, you must
+sanity check the changes to make sure that this assumption remains valid.
+
+In addition to reviewing the upstream changes in `env_posix.cc`, you can use `lsof` to
+check this. For example, on Linux this command will show open `.ldb` file counts:
+
+```bash
+$ lsof -p $(pidof agrariand) |\
+    awk 'BEGIN { fd=0; mem=0; } /ldb$/ { if ($4 == "mem") mem++; else fd++ } END { printf "mem = %s, fd = %s\n", mem, fd}'
+mem = 119, fd = 0
+```
+
+The `mem` value shows how many files are mmap'ed, and the `fd` value shows you
+many file descriptors these files are using. You should check that `fd` is a
+small number (usually 0 on 64-bit hosts).
+
+See the notes in the `SetMaxOpenFiles()` function in `dbwrapper.cc` for more
+details.
+
+### Consensus Compatibility
+
+It is possible for LevelDB changes to inadvertently change consensus
+compatibility between nodes. This happened in Bitcoin 0.8 (when LevelDB was
+first introduced). When upgrading LevelDB you should review the upstream changes
+to check for issues affecting consensus compatibility.
+
+For example, if LevelDB had a bug that accidentally prevented a key from being
+returned in an edge case, and that bug was fixed upstream, the bug "fix" would
+be an incompatible consensus change. In this situation the correct behavior
+would be to revert the upstream fix before applying the updates to Bitcoin's
+copy of LevelDB. In general you should be wary of any upstream changes affecting
+what data is returned from LevelDB queries.
+
+Scripted diffs
+--------------
+
+For reformatting and refactoring commits where the changes can be easily automated using a bash script, we use
+scripted-diff commits. The bash script is included in the commit message and our Travis CI job checks that
+the result of the script is identical to the commit. This aids reviewers since they can verify that the script
+does exactly what it's supposed to do. It is also helpful for rebasing (since the same script can just be re-run
+on the new master commit).
+
+To create a scripted-diff:
+
+- start the commit message with `scripted-diff:` (and then a description of the diff on the same line)
+- in the commit message include the bash script between lines containing just the following text:
+    - `-BEGIN VERIFY SCRIPT-`
+    - `-END VERIFY SCRIPT-`
+
+The scripted-diff is verified by the tool `test/lint/commit-script-check.sh`. The tool's default behavior when supplied
+with a commit is to verify all scripted-diffs from the beginning of time up to said commit. Internally, the tool passes
+the first supplied argument to `git rev-list --reverse` to determine which commits to verify script-diffs for, ignoring
+commits that don't conform to the commit message format described above.
+
+For development, it might be more convenient to verify all scripted-diffs in a range `A..B`, for example:
+
+```bash
+test/lint/commit-script-check.sh origin/master..HEAD
+```
+
+Commit [`bb81e173`](https://github.com/bitcoin/bitcoin/commit/bb81e173) is an example of a scripted-diff.
+
+Git and GitHub tips
+-------------
+
+- For resolving merge/rebase conflicts, it can be useful to enable diff3 style using
+  `git config merge.conflictstyle diff3`. Instead of
+
+        <<<
+        yours
+        ===
+        theirs
+        >>>
+
+  you will see
+
+        <<<
+        yours
+        |||
+        original
+        ===
+        theirs
+        >>>
+
+  This may make it much clearer what caused the conflict. In this style, you can often just look
+  at what changed between *original* and *theirs*, and mechanically apply that to *yours* (or the other way around).
+
+- When reviewing patches which change indentation in C++ files, use `git diff -w` and `git show -w`. This makes
+  the diff algorithm ignore whitespace changes. This feature is also available on github.com, by adding `?w=1`
+  at the end of any URL which shows a diff.
+
+- When reviewing patches that change symbol names in many places, use `git diff --word-diff`. This will instead
+  of showing the patch as deleted/added *lines*, show deleted/added *words*.
+
+- When reviewing patches that move code around, try using
+  `git diff --patience commit~:old/file.cpp commit:new/file/name.cpp`, and ignoring everything except the
+  moved body of code which should show up as neither `+` or `-` lines. In case it was not a pure move, this may
+  even work when combined with the `-w` or `--word-diff` options described above.
+
+- When looking at other's pull requests, it may make sense to add the following section to your `.git/config`
+  file:
+
+        [remote "upstream-pull"]
+                fetch = +refs/pull/*:refs/remotes/upstream-pull/*
+                url = git@github.com:Agrarian-Project/Agrarian.git
+
+  This will add an `upstream-pull` remote to your git repository, which can be fetched using `git fetch --all`
+  or `git fetch upstream-pull`. Afterwards, you can use `upstream-pull/NUMBER/head` in arguments to `git show`,
+  `git checkout` and anywhere a commit id would be acceptable to see the changes from pull request NUMBER.
+
+Release notes
+-------------
+
+Release notes should be written for any PR that:
+
+- introduces a notable new feature
+- fixes a significant bug
+- changes an API or configuration model
+- makes any other visible change to the end-user experience.
+
+Release notes should be added to a PR-specific release note file at
+`/doc/release-notes-<PR number>.md` to avoid conflicts between multiple PRs.
+All `release-notes*` files are merged into a single
+[/doc/release-notes.md](/doc/release-notes.md) file prior to the release.
+
+RPC interface guidelines
+--------------------------
+
+A few guidelines for introducing and reviewing new RPC interfaces:
+
+- Method naming: use consecutive lower-case names such as `getrawtransaction` and `submitblock`
+
+  - *Rationale*: Consistency with existing interface.
+
+- Argument naming: use snake case `fee_delta` (and not, e.g. camel case `feeDelta`)
+
+  - *Rationale*: Consistency with existing interface.
+
+- Use the JSON parser for parsing, don't manually parse integers or strings from
+  arguments unless absolutely necessary.
+
+  - *Rationale*: Introduces hand-rolled string manipulation code at both the caller and callee sites,
+    which is error prone, and it is easy to get things such as escaping wrong.
+    JSON already supports nested data structures, no need to re-invent the wheel.
+
+  - *Exception*: AmountFromValue can parse amounts as string. This was introduced because many JSON
+    parsers and formatters hard-code handling decimal numbers as floating point
+    values, resulting in potential loss of precision. This is unacceptable for
+    monetary values. **Always** use `AmountFromValue` and `ValueFromAmount` when
+    inputting or outputting monetary values. The only exceptions to this are
+    `prioritisetransaction` and `getblocktemplate` because their interface
+    is specified as-is in BIP22.
+
+- Missing arguments and 'null' should be treated the same: as default values. If there is no
+  default value, both cases should fail in the same way. The easiest way to follow this
+  guideline is detect unspecified arguments with `params[x].isNull()` instead of
+  `params.size() <= x`. The former returns true if the argument is either null or missing,
+  while the latter returns true if is missing, and false if it is null.
+
+  - *Rationale*: Avoids surprises when switching to name-based arguments. Missing name-based arguments
+  are passed as 'null'.
+
+- Try not to overload methods on argument type. E.g. don't make `getblock(true)` and `getblock("hash")`
+  do different things.
+
+  - *Rationale*: This is impossible to use with `agrarian-cli`, and can be surprising to users.
+
+  - *Exception*: Some RPC calls can take both an `int` and `bool`, most notably when a bool was switched
+    to a multi-value, or due to other historical reasons. **Always** have false map to 0 and
+    true to 1 in this case.
+
+- Don't forget to fill in the argument names correctly in the RPC command table.
+
+  - *Rationale*: If not, the call can not be used with name-based arguments.
+
+- Set okSafeMode in the RPC command table to a sensible value: safe mode is when the
+  blockchain is regarded to be in a confused state, and the client deems it unsafe to
+  do anything irreversible such as send. Anything that just queries should be permitted.
+
+  - *Rationale*: Troubleshooting a node in safe mode is difficult if half the
+    RPCs don't work.
+
+- Add every non-string RPC argument `(method, idx, name)` to the table `vRPCConvertParams` in `rpc/client.cpp`.
+
+  - *Rationale*: `agrarian-cli` and the GUI debug console use this table to determine how to
+    convert a plaintext command line to JSON. If the types don't match, the method can be unusable
+    from there.
+
+- A RPC method must either be a wallet method or a non-wallet method. Do not
+  introduce new methods that differ in behavior based on presence of a wallet.
+
+  - *Rationale*: as well as complicating the implementation and interfering
+    with the introduction of multi-wallet, wallet and non-wallet code should be
+    separated to avoid introducing circular dependencies between code units.
+
+- Try to make the RPC response a JSON object.
+
+  - *Rationale*: If a RPC response is not a JSON object then it is harder to avoid API breakage if
+    new data in the response is needed.
+
+- Be aware of RPC method aliases and generally avoid registering the same
+  callback function pointer for different RPCs.
+
+  - *Rationale*: RPC methods registered with the same function pointer will be
+    considered aliases and only the first method name will show up in the
+    `help` rpc command list.
+
+  - *Exception*: Using RPC method aliases may be appropriate in cases where a
+    new RPC is replacing a deprecated RPC, to avoid both RPCs confusingly
+    showing up in the command list.
@@ -0,0 +1,54 @@
+Expectations for DNS Seed operators
+====================================
+
+Agrarian Core attempts to minimize the level of trust in DNS seeds,
+but DNS seeds still pose a small amount of risk for the network.
+As such, DNS seeds must be run by entities which have some minimum
+level of trust within the Agrarian community.
+
+Other implementations of Agrarian software may also use the same
+seeds and may be more exposed. In light of this exposure, this
+document establishes some basic expectations for operating dnsseeds.
+
+0. A DNS seed operating organization or person is expected to follow good
+host security practices, maintain control of applicable infrastructure,
+and not sell or transfer control of the DNS seed. Any hosting services
+contracted by the operator are equally expected to uphold these expectations.
+
+1. The DNS seed results must consist exclusively of fairly selected and
+functioning Agrarian nodes from the public network to the best of the
+operators understanding and capability.
+
+2. For the avoidance of doubt, the results may be randomized but must not
+single-out any group of hosts to receive different results unless due to an
+urgent technical necessity and disclosed.
+
+3. The results may not be served with a DNS TTL of less than one minute.
+
+4. Any logging of DNS queries should be only that which is necessary
+for the operation of the service or urgent health of the Agrarian
+network and must not be retained longer than necessary nor disclosed
+to any third party.
+
+5. Information gathered as a result of the operators node-spidering
+(not from DNS queries) may be freely published or retained, but only
+if this data was not made more complete by biasing node connectivity
+(a violation of expectation (1)).
+
+6. Operators are encouraged, but not required, to publicly document the
+details of their operating practices.
+
+7. A reachable email contact address must be published for inquiries
+related to the DNS seed operation.
+
+If these expectations cannot be satisfied the operator should
+discontinue providing services and contact the active Agrarian
+Core development team as well as posting on the
+[Agrarian Forum](https://forum.agrarian.org).
+
+Behavior outside of these expectations may be reasonable in some
+situations but should be discussed in public in advance.
+
+See also
+----------
+- [bitcoin-seeder](https://github.com/sipa/bitcoin-seeder) is a reference implementation of a DNS seed.
@@ -0,0 +1,22 @@
+Filename            | Description
+--------------------|----------------------------------------------------------------------------------------------------------------------------
+banlist.dat         | stores the IPs/Subnets of banned nodes
+agrarian.conf           | contains configuration settings for agrariand or agrarian-qt
+agrariand.pid           | stores the process id of agrariand while running
+blocks/blk000??.dat | block data (custom, 128 MiB per file); since 0.8.0
+blocks/rev000??.dat | block undo data (custom); since 0.8.0 (format changed since pre-0.8)
+blocks/index/*      | block index (LevelDB); since 0.8.0
+chainstate/*        | blockchain state database (LevelDB); since 0.8.0
+database/*          | BDB database environment; only used for wallet since 0.8.0; moved to wallets/ directory on new installs since 0.16.0
+db.log              | wallet database log file; moved to wallets/ directory on new installs since 0.16.0
+debug.log           | contains debug information and general logging generated by agrariand or agrarian-qt
+fee_estimates.dat   | stores statistics used to estimate minimum transaction fees and priorities required for confirmation; since 0.10.0
+budget.dat          | stores data for budget objects
+masternode.conf     | contains configuration settings for remote masternodes
+mncache.dat         | stores data for masternode list
+mnpayments.dat      | stores data for masternode payments
+peers.dat           | peer IP address database (custom format); since 0.7.0
+wallet.dat          | personal wallet (BDB) with keys and transactions; moved to wallets/ directory on new installs since 0.16.0
+.cookie             | session RPC authentication cookie (written at start when cookie authentication is used, deleted on shutdown): since 0.12.0
+onion_private_key   | cached Tor hidden service private key for `-listenonion`: since 0.12.0
+
@@ -0,0 +1,413 @@
+Gitian building
+================
+
+*Setup instructions for a gitian build of Agrarian using a Debian VM or physical system.*
+
+Gitian is the deterministic build process that is used to build the Agrarian
+Core executables. It provides a way to be reasonably sure that the
+executables are really built from source on GitHub. It also makes sure that
+the same, tested dependencies are used and statically built into the executable.
+
+Multiple developers build the source code by following a specific descriptor
+("recipe"), cryptographically sign the result, and upload the resulting signature.
+These results are compared and only if they match, the build is accepted and uploaded
+to agrarian-crypto.com.
+
+More independent gitian builders are needed, which is why I wrote this
+guide. It is preferred to follow these steps yourself instead of using someone else's
+VM image to avoid 'contaminating' the build.
+
+Table of Contents
+------------------
+
+- [Create a new VirtualBox VM](#create-a-new-virtualbox-vm)
+- [Connecting to the VM](#connecting-to-the-vm)
+- [Setting up Debian for gitian building](#setting-up-debian-for-gitian-building)
+- [Installing gitian](#installing-gitian)
+- [Setting up gitian images](#setting-up-gitian-images)
+- [Getting and building the inputs](#getting-and-building-the-inputs)
+- [Building Agrarian](#building-agrarian)
+- [Building an alternative repository](#building-an-alternative-repository)
+- [Signing externally](#signing-externally)
+- [Uploading signatures](#uploading-signatures)
+
+Preparing the Gitian builder host
+---------------------------------
+
+The first step is to prepare the host environment that will be used to perform the Gitian builds.
+This guide explains how to set up the environment, and how to start the builds.
+
+Debian Linux was chosen as the host distribution because it has a lightweight install (in contrast to Ubuntu) and is readily available.
+Any kind of virtualization can be used, for example:
+- [VirtualBox](https://www.virtualbox.org/), covered by this guide
+- [KVM](http://www.linux-kvm.org/page/Main_Page)
+- [LXC](https://linuxcontainers.org/), see also [Gitian host docker container](https://github.com/gdm85/tenku/tree/master/docker/gitian-bitcoin-host/README.md).
+
+You can also install on actual hardware instead of using virtualization.
+
+Create a new VirtualBox VM
+---------------------------
+In the VirtualBox GUI click "Create" and choose the following parameters in the wizard:
+
+![](gitian-building/create_vm_page1.png)
+
+- Type: Linux, Debian (64 bit)
+
+![](gitian-building/create_vm_memsize.png)
+
+- Memory Size: at least 1024MB, anything lower will really slow the build down
+
+![](gitian-building/create_vm_hard_drive.png)
+
+- Hard Drive: Create a virtual hard drive now
+    
+![](gitian-building/create_vm_hard_drive_file_type.png)
+
+- Hard Drive file type: Use the default, VDI (VirtualBox Disk Image) 
+
+![](gitian-building/create_vm_storage_physical_hard_drive.png)
+    
+- Storage on Physical hard drive: Dynamically Allocated 
+    
+![](gitian-building/create_vm_file_location_size.png)
+
+- Disk size: at least 40GB; as low as 20GB *may* be possible, but better to err on the safe side 
+- Push the `Create` button
+
+Get the [Debian 7.8 net installer](http://cdimage.debian.org/cdimage/archive/7.8.0/amd64/iso-cd/debian-7.8.0-amd64-netinst.iso) (a more recent minor version should also work, see also [Debian Network installation](https://www.debian.org/CD/netinst/)).
+This DVD image can be validated using a SHA256 hashing tool, for example on
+Unixy OSes by entering the following in a terminal:
+
+    echo "b712a141bc60269db217d3b3e456179bd6b181645f90e4aac9c42ed63de492e9  debian-7.4.0-amd64-netinst.iso" | sha256sum -c
+    # (must return OK)
+
+After creating the VM, we need to configure it. 
+
+- Click the `Settings` button, then go to the `Network` tab. Adapter 1 should be attacked to `NAT`.
+
+![](gitian-building/network_settings.png)
+
+- Click `Advanced`, then `Port Forwarding`. We want to set up a port through where we can reach the VM to get files in and out.
+- Create a new rule by clicking the plus icon.
+
+![](gitian-building/port_forwarding_rules.png)
+
+- Set up the new rule the following way:
+  - Name: `SSH`
+  - Protocol: `TCP`
+  - Leave Host IP empty
+  - Host Port: `22222`
+  - Leave Guest IP empty
+  - Guest Port: `22`
+
+- Click `Ok` twice to save.
+
+Then start the VM. On the first launch you will be asked for a CD or DVD image. Choose the downloaded iso.
+
+![](gitian-building/select_startup_disk.png)
+
+Installing Debian
+------------------
+
+In this section it will be explained how to install Debian on the newly created VM.
+
+- Choose the non-graphical installer.  We do not need the graphical environment, it will only increase installation time and disk usage.
+
+![](gitian-building/debian_install_1_boot_menu.png)
+
+**Note**: Navigation in the Debian installer: To keep a setting at the default
+and proceed, just press `Enter`. To select a different button, press `Tab`.
+
+- Choose locale and keyboard settings (doesn't matter, you can just go with the defaults or select your own information)
+
+![](gitian-building/debian_install_2_select_a_language.png)
+![](gitian-building/debian_install_3_select_location.png)
+![](gitian-building/debian_install_4_configure_keyboard.png)
+
+- The VM will detect network settings using DHCP, this should all proceed automatically
+- Configure the network: 
+  - System name `debian`.
+  - Leave domain name empty.
+
+![](gitian-building/debian_install_5_configure_the_network.png)
+
+- Choose a root password and enter it twice (remember it for later) 
+
+![](gitian-building/debian_install_6a_set_up_root_password.png)
+
+- Name the new user `debian` (the full name doesn't matter, you can leave it empty) 
+
+![](gitian-building/debian_install_7_set_up_user_fullname.png)
+![](gitian-building/debian_install_8_set_up_username.png)
+
+- Choose a user password and enter it twice (remember it for later) 
+
+![](gitian-building/debian_install_9_user_password.png)
+
+- The installer will set up the clock using a time server, this process should be automatic
+- Set up the clock: choose a time zone (depends on the locale settings that you picked earlier; specifics don't matter)  
+
+![](gitian-building/debian_install_10_configure_clock.png)
+
+- Disk setup
+  - Partitioning method: Guided - Use the entire disk 
+  
+![](gitian-building/debian_install_11_partition_disks.png)
+
+  - Select disk to partition: SCSI1 (0,0,0) 
+
+![](gitian-building/debian_install_12_choose_disk.png)
+
+  - Partitioning scheme: All files in one partition 
+  
+![](gitian-building/debian_install_13_partition_scheme.png)
+
+  - Finish partitioning and write changes to disk -> *Yes* (`Tab`, `Enter` to select the `Yes` button)
+
+![](gitian-building/debian_install_14_finish.png) 
+![](gitian-building/debian_install_15_write_changes.png)
+
+- The base system will be installed, this will take a minute or so
+- Choose a mirror (any will do) 
+
+![](gitian-building/debian_install_16_choose_a_mirror.png)
+
+- Enter proxy information (unless you are on an intranet, you can leave this empty)
+
+![](gitian-building/debian_install_18_proxy_settings.png)
+
+- Wait a bit while 'Select and install software' runs
+- Participate in popularity contest -> *No*
+- Choose software to install. We need just the base system. 
+
+![](gitian-building/debian_install_19_software_selection.png)
+
+- Make sure only 'SSH server' and 'Standard System Utilities' are checked
+- Uncheck 'Debian Desktop Environment' and 'Print Server'
+
+![](gitian-building/debian_install_20_install_grub.png)
+
+- Install the GRUB boot loader to the master boot record? -> Yes 
+
+![](gitian-building/debian_install_21_finish_installation.png)
+
+- Installation Complete -> *Continue*
+- After installation, the VM will reboot and you will have a working Debian VM. Congratulations!
+
+Connecting to the VM
+----------------------
+
+After the VM has booted you can connect to it using SSH, and files can be copied from and to the VM using a SFTP utility.
+Connect to `localhost`, port `22222` (or the port configured when installing the VM).
+On Windows you can use putty[1] and WinSCP[2].
+
+For example to connect as `root` from a Linux command prompt use
+
+    $ ssh root@localhost -p 22222
+    The authenticity of host '[localhost]:22222 ([127.0.0.1]:22222)' can't be established.
+    ECDSA key fingerprint is 8e:71:f9:5b:62:46:de:44:01:da:fb:5f:34:b5:f2:18.
+    Are you sure you want to continue connecting (yes/no)? yes
+    Warning: Permanently added '[localhost]:22222' (ECDSA) to the list of known hosts.
+    root@localhost's password: (enter root password configured during install)
+    Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64
+    root@debian:~#
+
+Replace `root` with `debian` to log in as user.
+
+[1] http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
+[2] http://winscp.net/eng/index.php
+
+Setting up Debian for gitian building
+--------------------------------------
+
+In this section we will be setting up the Debian installation for Gitian building.
+
+First we need to log in as `root` to set up dependencies and make sure that our
+user can use the sudo command. Type/paste the following in the terminal:
+
+```bash
+apt-get install make git ruby sudo apt-cacher-ng qemu-utils debootstrap lxc python-cheetah parted kpartx bridge-utils
+adduser debian sudo
+```
+
+When you get a colorful screen with a question about the 'LXC directory', just
+go with the default (`/var/lib/lxc`).
+
+Then set up LXC and the rest with the following, which is a complex jumble of settings and workarounds:
+
+```bash
+# the version of lxc-start in Debian 7.4 needs to run as root, so make sure
+# that the build script can exectute it without providing a password
+echo "%sudo ALL=NOPASSWD: /usr/bin/lxc-start" > /etc/sudoers.d/gitian-lxc
+# add cgroup for LXC
+echo "cgroup  /sys/fs/cgroup  cgroup  defaults  0   0" >> /etc/fstab
+# make /etc/rc.local script that sets up bridge between guest and host
+echo '#!/bin/sh -e' > /etc/rc.local
+echo 'brctl addbr br0' >> /etc/rc.local
+echo 'ifconfig br0 10.0.3.2/24 up' >> /etc/rc.local
+echo 'exit 0' >> /etc/rc.local
+# make sure that USE_LXC is always set when logging in as debian,
+# and configure LXC IP addresses
+echo 'export USE_LXC=1' >> /home/debian/.profile
+echo 'export GITIAN_HOST_IP=10.0.3.2' >> /home/debian/.profile
+echo 'export LXC_GUEST_IP=10.0.3.5' >> /home/debian/.profile
+reboot
+```
+
+At the end the VM is rebooted to make sure that the changes take effect. The steps in this
+section need only to be performed once.
+
+Installing gitian
+------------------
+
+Re-login as the user `debian` that was created during installation.
+The rest of the steps in this guide will be performed as that user.
+
+There is no `python-vm-builder` package in Debian, so we need to install it from source ourselves,
+
+```bash
+wget http://archive.ubuntu.com/ubuntu/pool/universe/v/vm-builder/vm-builder_0.12.4+bzr489.orig.tar.gz
+echo "ec12e0070a007989561bfee5862c89a32c301992dd2771c4d5078ef1b3014f03  vm-builder_0.12.4+bzr489.orig.tar.gz" | sha256sum -c
+# (verification -- must return OK)
+tar -zxvf vm-builder_0.12.4+bzr489.orig.tar.gz
+cd vm-builder-0.12.4+bzr489
+sudo python setup.py install
+cd ..
+```
+
+**Note**: When sudo asks for a password, enter the password for the user *debian* not for *root*.
+
+Clone the git repositories for agrarian and gitian and then checkout the agrarian version that you want to build.
+
+```bash
+git clone https://github.com/devrandom/gitian-builder.git
+git clone https://github.com/agrarian-crypto/agrarian.git
+cd agrarian
+git checkout v${VERSION}
+cd ..
+```
+
+**Note**: if you've installed Gitian before May 16, 2015, please update to the latest version, see https://github.com/devrandom/gitian-builder/issues/86
+
+
+Setting up gitian images
+-------------------------
+
+Gitian needs virtual images of the operating system to build in.
+Currently this is Ubuntu Precise for x86_64.
+These images will be copied and used every time that a build is started to
+make sure that the build is deterministic.
+Creating the images will take a while, but only has to be done once.
+
+Execute the following as user `debian`:
+
+```bash
+cd gitian-builder
+bin/make-base-vm --lxc --arch amd64 --suite precise
+```
+
+There will be a lot of warnings printed during build of the images. These can be ignored.
+
+**Note**: When sudo asks for a password, enter the password for the user *debian* not for *root*.
+
+**Note**: Repeat this step when you have upgraded to a newer version of Gitian.
+
+**Note**: if you get the error message *"bin/make-base-vm: mkfs.ext4: not found"* during this process you have to make the following change in file *"gitian-builder/bin/make-base-vm"* at line 117:
+```bash
+# mkfs.ext4 -F $OUT-lxc
+/sbin/mkfs.ext4 -F $OUT-lxc # (some Gitian environents do NOT find mkfs.ext4. Some do...)
+```
+
+Getting and building the inputs
+--------------------------------
+
+Follow the instructions in [doc/release-process.md](release-process.md) in the agrarian repository
+under 'Fetch and build inputs' to install sources which require manual intervention. Also follow
+the next step: 'Seed the Gitian sources cache', which will fetch all necessary source files allowing
+for gitian to work offline.
+
+Building Agrarian
+----------------
+
+To build Agrarian (for Linux, OSX and Windows) just follow the steps under 'perform
+gitian builds' in [doc/release-process.md](release-process.md) in the agrarian repository.
+
+This may take a long time as it also builds the dependencies needed for each descriptor.
+These dependencies will be cached after a successful build to avoid rebuilding them when possible.
+
+At any time you can check the package installation and build progress with
+
+```bash
+tail -f var/install.log
+tail -f var/build.log
+```
+
+Output from `gbuild` will look something like
+
+```bash
+    Initialized empty Git repository in /home/debian/gitian-builder/inputs/agrarian/.git/
+    remote: Reusing existing pack: 35606, done.
+    remote: Total 35606 (delta 0), reused 0 (delta 0)
+    Receiving objects: 100% (35606/35606), 26.52 MiB | 4.28 MiB/s, done.
+    Resolving deltas: 100% (25724/25724), done.
+    From https://github.com/agrarian-crypto/agrarian
+    ... (new tags, new branch etc)
+    --- Building for precise x86_64 ---
+    Stopping target if it is up
+    Making a new image copy
+    stdin: is not a tty
+    Starting target
+    Checking if target is up
+    Preparing build environment
+    Updating apt-get repository (log in var/install.log)
+    Installing additional packages (log in var/install.log)
+    Grabbing package manifest
+    stdin: is not a tty
+    Creating build script (var/build-script)
+    lxc-start: Connection refused - inotify event with no name (mask 32768)
+    Running build script (log in var/build.log)
+```
+
+Building an alternative repository
+-----------------------------------
+
+If you want to do a test build of a pull on GitHub it can be useful to point
+the gitian builder at an alternative repository, using the same descriptors
+and inputs.
+
+For example:
+```bash
+URL=https://github.com/crowning-/agrarian.git
+COMMIT=b616fb8ef0d49a919b72b0388b091aaec5849b96
+./bin/gbuild --commit agrarian=${COMMIT} --url agrarian=${URL} ../agrarian/contrib/gitian-descriptors/gitian-linux.yml
+./bin/gbuild --commit agrarian=${COMMIT} --url agrarian=${URL} ../agrarian/contrib/gitian-descriptors/gitian-win.yml
+./bin/gbuild --commit agrarian=${COMMIT} --url agrarian=${URL} ../agrarian/contrib/gitian-descriptors/gitian-osx.yml
+```
+
+Signing externally
+-------------------
+
+If you want to do the PGP signing on another device that's also possible; just define `SIGNER` as mentioned
+and follow the steps in the build process as normal.
+
+    gpg: skipped "crowning-": secret key not available
+
+When you execute `gsign` you will get an error from GPG, which can be ignored. Copy the resulting `.assert` files
+in `gitian.sigs` to your signing machine and do
+
+```bash
+    gpg --detach-sign ${VERSION}-linux/${SIGNER}/agrarian-build.assert
+    gpg --detach-sign ${VERSION}-win/${SIGNER}/agrarian-build.assert
+    gpg --detach-sign ${VERSION}-osx/${SIGNER}/agrarian-build.assert
+```
+
+This will create the `.sig` files that can be committed together with the `.assert` files to assert your
+gitian build.
+
+Uploading signatures (not yet implemented)
+---------------------
+
+In the future it will be possible to push your signatures (both the `.assert` and `.assert.sig` files) to the
+[agrarian/gitian.sigs](https://github.com/agrarian-crypto/gitian.sigs/) repository, or if that's not possible to create a pull
+request.
+There will be an official announcement when this repository is online.
@@ -0,0 +1,145 @@
+Sample init scripts and service configuration for agrariand
+==========================================================
+
+Sample scripts and configuration files for systemd, Upstart and OpenRC
+can be found in the contrib/init folder.
+
+    contrib/init/agrariand.service:    systemd service unit configuration
+    contrib/init/agrariand.openrc:     OpenRC compatible SysV style init script
+    contrib/init/agrariand.openrcconf: OpenRC conf.d file
+    contrib/init/agrariand.conf:       Upstart service configuration file
+    contrib/init/agrariand.init:       CentOS compatible SysV style init script
+
+Service User
+---------------------------------
+
+All three Linux startup configurations assume the existence of a "agrarian" user
+and group.  They must be created before attempting to use these scripts.
+The macOS configuration assumes agrariand will be set up for the current user.
+
+Configuration
+---------------------------------
+
+At a bare minimum, agrariand requires that the rpcpassword setting be set
+when running as a daemon.  If the configuration file does not exist or this
+setting is not set, agrariand will shutdown promptly after startup.
+
+This password does not have to be remembered or typed as it is mostly used
+as a fixed token that agrariand and client programs read from the configuration
+file, however it is recommended that a strong and secure password be used
+as this password is security critical to securing the wallet should the
+wallet be enabled.
+
+If agrariand is run with the "-server" flag (set by default), and no rpcpassword is set,
+it will use a special cookie file for authentication. The cookie is generated with random
+content when the daemon starts, and deleted when it exits. Read access to this file
+controls who can access it through RPC.
+
+By default the cookie is stored in the data directory, but it's location can be overridden
+with the option '-rpccookiefile'.
+
+This allows for running agrariand without having to do any manual configuration.
+
+`conf`, `pid`, and `wallet` accept relative paths which are interpreted as
+relative to the data directory. `wallet` *only* supports relative paths.
+
+For an example configuration file that describes the configuration settings,
+see contrib/debian/examples/agrarian.conf.
+
+Paths
+---------------------------------
+
+### Linux
+
+All three configurations assume several paths that might need to be adjusted.
+
+Binary:              /usr/bin/agrariand
+Configuration file:  /etc/agrarian/agrarian.conf
+Data directory:      /var/lib/agrariand
+PID file:            `/var/run/agrariand/agrariand.pid` (OpenRC and Upstart) or `/run/agrariand/agrariand.pid` (systemd)
+Lock file:           `/var/lock/subsys/agrariand` (CentOS)
+
+The configuration file, PID directory (if applicable) and data directory
+should all be owned by the agrarian user and group.  It is advised for security
+reasons to make the configuration file and data directory only readable by the
+agrarian user and group.  Access to agrarian-cli and other agrariand rpc clients
+can then be controlled by group membership.
+
+NOTE: When using the systemd .service file, the creation of the aforementioned
+directories and the setting of their permissions is automatically handled by
+systemd. Directories are given a permission of 710, giving the agrarian group
+access to files under it _if_ the files themselves give permission to the
+agrarian group to do so (e.g. when `-sysperms` is specified). This does not allow
+for the listing of files under the directory.
+
+NOTE: It is not currently possible to override `datadir` in
+`/etc/agrarian/agrarian.conf` with the current systemd, OpenRC, and Upstart init
+files out-of-the-box. This is because the command line options specified in the
+init files take precedence over the configurations in
+`/etc/agrarian/agrarian.conf`. However, some init systems have their own
+configuration mechanisms that would allow for overriding the command line
+options specified in the init files (e.g. setting `BITCOIND_DATADIR` for
+OpenRC).
+
+### macOS
+
+Binary:              `/usr/local/bin/agrariand`
+Configuration file:  `~/Library/Application Support/Agrarian/agrarian.conf`
+Data directory:      `~/Library/Application Support/Agrarian`
+Lock file:           `~/Library/Application Support/Agrarian/.lock`
+
+Installing Service Configuration
+-----------------------------------
+
+### systemd
+
+Installing this .service file consists of just copying it to
+/usr/lib/systemd/system directory, followed by the command
+`systemctl daemon-reload` in order to update running systemd configuration.
+
+To test, run `systemctl start agrariand` and to enable for system startup run
+`systemctl enable agrariand`
+
+NOTE: When installing for systemd in Debian/Ubuntu the .service file needs to be copied to the /lib/systemd/system directory instead.
+
+### OpenRC
+
+Rename agrariand.openrc to agrariand and drop it in /etc/init.d.  Double
+check ownership and permissions and make it executable.  Test it with
+`/etc/init.d/agrariand start` and configure it to run on startup with
+`rc-update add agrariand`
+
+### Upstart (for Debian/Ubuntu based distributions)
+
+Upstart is the default init system for Debian/Ubuntu versions older than 15.04. If you are using version 15.04 or newer and haven't manually configured upstart you should follow the systemd instructions instead.
+
+Drop agrariand.conf in /etc/init.  Test by running `service agrariand start`
+it will automatically start on reboot.
+
+NOTE: This script is incompatible with CentOS 5 and Amazon Linux 2014 as they
+use old versions of Upstart and do not supply the start-stop-daemon utility.
+
+### CentOS
+
+Copy agrariand.init to /etc/init.d/agrariand. Test by running `service agrariand start`.
+
+Using this script, you can adjust the path and flags to the agrariand program by
+setting the AgrarianD and FLAGS environment variables in the file
+/etc/sysconfig/agrariand. You can also use the DAEMONOPTS environment variable here.
+
+### macOS
+
+Copy org.agrarian.agrariand.plist into ~/Library/LaunchAgents. Load the launch agent by
+running `launchctl load ~/Library/LaunchAgents/org.agrarian.agrariand.plist`.
+
+This Launch Agent will cause agrariand to start whenever the user logs in.
+
+NOTE: This approach is intended for those wanting to run agrariand as the current user.
+You will need to modify org.agrarian.agrariand.plist if you intend to use it as a
+Launch Daemon with a dedicated agrarian user.
+
+Auto-respawn
+-----------------------------------
+
+Auto respawning is currently only configured for Upstart and systemd.
+Reasonable defaults have been chosen but YMMV.
@@ -0,0 +1,13 @@
+dist_man1_MANS=
+
+if BUILD_BITCOIND
+  dist_man1_MANS+=agrariand.1
+endif
+
+if ENABLE_QT
+  dist_man1_MANS+=agrarian-qt.1
+endif
+
+if BUILD_BITCOIN_UTILS
+  dist_man1_MANS+=agrarian-cli.1 agrarian-tx.1
+endif
@@ -0,0 +1,78 @@
+.\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.47.4.
+.TH Agrarian-CLI "1" "July 2018" "agrarian-cli v3.1.99.0" "User Commands"
+.SH NAME
+agrarian-cli \- manual page for agrarian-cli v3.1.99.0
+.SH DESCRIPTION
+Agrarian Core RPC client version v3.1.99.0\-11f4a2bba4\-dirty
+.SS "Usage:"
+.TP
+agrarian\-cli [options] <command> [params]
+Send command to Agrarian Core
+.TP
+agrarian\-cli [options] help
+List commands
+.TP
+agrarian\-cli [options] help <command>
+Get help for a command
+.SH OPTIONS
+.HP
+\-?
+.IP
+This help message
+.HP
+\fB\-conf=\fR<file>
+.IP
+Specify configuration file (default: agrarian.conf)
+.HP
+\fB\-datadir=\fR<dir>
+.IP
+Specify data directory
+.HP
+\fB\-testnet\fR
+.IP
+Use the test network
+.HP
+\fB\-regtest\fR
+.IP
+Enter regression test mode, which uses a special chain in which blocks
+can be solved instantly. This is intended for regression testing tools
+and app development.
+.HP
+\fB\-rpcconnect=\fR<ip>
+.IP
+Send commands to node running on <ip> (default: 127.0.0.1)
+.HP
+\fB\-rpcport=\fR<port>
+.IP
+Connect to JSON\-RPC on <port> (default: 51335 or testnet: 61335)
+.HP
+\fB\-rpcwait\fR
+.IP
+Wait for RPC server to start
+.HP
+\fB\-rpcuser=\fR<user>
+.IP
+Username for JSON\-RPC connections
+.HP
+\fB\-rpcpassword=\fR<pw>
+.IP
+Password for JSON\-RPC connections
+.HP
+\fB\-rpcclienttimeout=\fR<n>
+.IP
+Timeout during HTTP requests (default: 900)
+.SH COPYRIGHT
+Copyright (C) 2009-2018 The Bitcoin Core Developers
+
+Copyright (C) 2014-2018 The Dash Core Developers
+
+Copyright (C) 2015-2018 The PIVX Core Developers
+
+This is experimental software.
+
+Distributed under the MIT software license, see the accompanying file COPYING
+or <http://www.opensource.org/licenses/mit-license.php>.
+
+This product includes software developed by the OpenSSL Project for use in the
+OpenSSL Toolkit <https://www.openssl.org/> and cryptographic software written
+by Eric Young and UPnP software written by Thomas Bernard.
@@ -0,0 +1,593 @@
+.\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.47.4.
+.TH Agrarian-QT "1" "July 2018" "agrarian-qt v3.1.99.0" "User Commands"
+.SH NAME
+agrarian-qt \- manual page for agrarian-qt v3.1.99.0
+.SH DESCRIPTION
+Agrarian Core version v3.1.99.0\-11f4a2bba4\-dirty (64\-bit)
+Usage:
+.IP
+agrarian\-qt [command\-line options]
+.SH OPTIONS
+.HP
+\-?
+.IP
+This help message
+.HP
+\fB\-version\fR
+.IP
+Print version and exit
+.HP
+\fB\-alertnotify=\fR<cmd>
+.IP
+Execute command when a relevant alert is received or we see a really
+long fork (%s in cmd is replaced by message)
+.HP
+\fB\-alerts\fR
+.IP
+Receive and display P2P network alerts (default: 1)
+.HP
+\fB\-blocknotify=\fR<cmd>
+.IP
+Execute command when the best block changes (%s in cmd is replaced by
+block hash)
+.HP
+\fB\-blocksizenotify=\fR<cmd>
+.IP
+Execute command when the best block changes and its size is over (%s in
+cmd is replaced by block hash, %d with the block size)
+.HP
+\fB\-checkblocks=\fR<n>
+.IP
+How many blocks to check at startup (default: 500, 0 = all)
+.HP
+\fB\-conf=\fR<file>
+.IP
+Specify configuration file (default: agrarian.conf)
+.HP
+\fB\-datadir=\fR<dir>
+.IP
+Specify data directory
+.HP
+\fB\-dbcache=\fR<n>
+.IP
+Set database cache size in megabytes (4 to 4096, default: 100)
+.HP
+\fB\-loadblock=\fR<file>
+.IP
+Imports blocks from external blk000??.dat file on startup
+.HP
+\fB\-maxreorg=\fR<n>
+.IP
+Set the Maximum reorg depth (default: 100)
+.HP
+\fB\-maxorphantx=\fR<n>
+.IP
+Keep at most <n> unconnectable transactions in memory (default: 100)
+.HP
+\fB\-par=\fR<n>
+.IP
+Set the number of script verification threads (\fB\-8\fR to 16, 0 = auto, <0 =
+leave that many cores free, default: 0)
+.HP
+\fB\-pid=\fR<file>
+.IP
+Specify pid file (default: agrariand.pid)
+.HP
+\fB\-reindex\fR
+.IP
+Rebuild block chain index from current blk000??.dat files on startup
+.HP
+\fB\-reindexaccumulators\fR
+.IP
+Reindex the accumulator database on startup
+.HP
+\fB\-reindexmoneysupply\fR
+.IP
+Reindex the AGR and zAGR money supply statistics on startup
+.HP
+\fB\-resync\fR
+.IP
+Delete blockchain folders and resync from scratch on startup
+.HP
+\fB\-sysperms\fR
+.IP
+Create new files with system default permissions, instead of umask 077
+(only effective with disabled wallet functionality)
+.HP
+\fB\-txindex\fR
+.IP
+Maintain a full transaction index, used by the getrawtransaction rpc
+call (default: 0)
+.HP
+\fB\-forcestart\fR
+.IP
+Attempt to force blockchain corruption recovery on startup
+.PP
+Connection options:
+.HP
+\fB\-addnode=\fR<ip>
+.IP
+Add a node to connect to and attempt to keep the connection open
+.HP
+\fB\-banscore=\fR<n>
+.IP
+Threshold for disconnecting misbehaving peers (default: 100)
+.HP
+\fB\-bantime=\fR<n>
+.IP
+Number of seconds to keep misbehaving peers from reconnecting (default:
+86400)
+.HP
+\fB\-bind=\fR<addr>
+.IP
+Bind to given address and always listen on it. Use [host]:port notation
+for IPv6
+.HP
+\fB\-connect=\fR<ip>
+.IP
+Connect only to the specified node(s)
+.HP
+\fB\-discover\fR
+.IP
+Discover own IP address (default: 1 when listening and no \fB\-externalip\fR)
+.HP
+\fB\-dns\fR
+.IP
+Allow DNS lookups for \fB\-addnode\fR, \fB\-seednode\fR and \fB\-connect\fR (default: 1)
+.HP
+\fB\-dnsseed\fR
+.IP
+Query for peer addresses via DNS lookup, if low on addresses (default: 1
+unless \fB\-connect\fR)
+.HP
+\fB\-externalip=\fR<ip>
+.IP
+Specify your own public address
+.HP
+\fB\-forcednsseed\fR
+.IP
+Always query for peer addresses via DNS lookup (default: 0)
+.HP
+\fB\-listen\fR
+.IP
+Accept connections from outside (default: 1 if no \fB\-proxy\fR or \fB\-connect\fR)
+.HP
+\fB\-listenonion\fR
+.IP
+Automatically create Tor hidden service (default: 1)
+.HP
+\fB\-maxconnections=\fR<n>
+.IP
+Maintain at most <n> connections to peers (default: 125)
+.HP
+\fB\-maxreceivebuffer=\fR<n>
+.IP
+Maximum per\-connection receive buffer, <n>*1000 bytes (default: 5000)
+.HP
+\fB\-maxsendbuffer=\fR<n>
+.IP
+Maximum per\-connection send buffer, <n>*1000 bytes (default: 1000)
+.HP
+\fB\-onion=\fR<ip:port>
+.IP
+Use separate SOCKS5 proxy to reach peers via Tor hidden services
+(default: \fB\-proxy\fR)
+.HP
+\fB\-onlynet=\fR<net>
+.IP
+Only connect to nodes in network <net> (ipv4, ipv6 or onion)
+.HP
+\fB\-permitbaremultisig\fR
+.IP
+Relay non\-P2SH multisig (default: 1)
+.HP
+\fB\-peerbloomfilters\fR
+.IP
+Support filtering of blocks and transaction with bloom filters (default:
+1)
+.HP
+\fB\-port=\fR<port>
+.IP
+Listen for connections on <port> (default: 51336 or testnet: 61336)
+.HP
+\fB\-proxy=\fR<ip:port>
+.IP
+Connect through SOCKS5 proxy
+.HP
+\fB\-proxyrandomize\fR
+.IP
+Randomize credentials for every proxy connection. This enables Tor
+stream isolation (default: 1)
+.HP
+\fB\-seednode=\fR<ip>
+.IP
+Connect to a node to retrieve peer addresses, and disconnect
+.HP
+\fB\-timeout=\fR<n>
+.IP
+Specify connection timeout in milliseconds (minimum: 1, default: 5000)
+.HP
+\fB\-torcontrol=\fR<ip>:<port>
+.IP
+Tor control port to use if onion listening enabled (default:
+127.0.0.1:9051)
+.HP
+\fB\-torpassword=\fR<pass>
+.IP
+Tor control port password (default: empty)
+.HP
+\fB\-upnp\fR
+.IP
+Use UPnP to map the listening port (default: 0)
+.HP
+\fB\-whitebind=\fR<addr>
+.IP
+Bind to given address and whitelist peers connecting to it. Use
+[host]:port notation for IPv6
+.HP
+\fB\-whitelist=\fR<netmask>
+.IP
+Whitelist peers connecting from the given netmask or IP address. Can be
+specified multiple times. Whitelisted peers cannot be DoS banned and
+their transactions are always relayed, even if they are already in the
+mempool, useful e.g. for a gateway
+.PP
+Wallet options:
+.HP
+\fB\-backuppath=\fR<dir|file>
+.IP
+Specify custom backup path to add a copy of any wallet backup. If set as
+dir, every backup generates a timestamped file. If set as file, will
+rewrite to that file every backup.
+.HP
+\fB\-createwalletbackups=\fR<n>
+.IP
+Number of automatic wallet backups (default: 10)
+.HP
+\fB\-custombackupthreshold=\fR<n>
+.IP
+Number of custom location backups to retain (default: 1)
+.HP
+\fB\-disablewallet\fR
+.IP
+Do not load the wallet and disable wallet RPC calls
+.HP
+\fB\-keypool=\fR<n>
+.IP
+Set key pool size to <n> (default: 100)
+.HP
+\fB\-paytxfee=\fR<amt>
+.IP
+Fee (in AGR/kB) to add to transactions you send (default: 0.00)
+.HP
+\fB\-rescan\fR
+.IP
+Rescan the block chain for missing wallet transactions on startup
+.HP
+\fB\-salvagewallet\fR
+.IP
+Attempt to recover private keys from a corrupt wallet.dat on startup
+.HP
+\fB\-sendfreetransactions\fR
+.IP
+Send transactions as zero\-fee transactions if possible (default: 0)
+.HP
+\fB\-spendzeroconfchange\fR
+.IP
+Spend unconfirmed change when sending transactions (default: 1)
+.HP
+\fB\-disablesystemnotifications\fR
+.IP
+Disable OS notifications for incoming transactions (default: 0)
+.HP
+\fB\-txconfirmtarget=\fR<n>
+.IP
+If paytxfee is not set, include enough fee so transactions begin
+confirmation on average within n blocks (default: 1)
+.HP
+\fB\-maxtxfee=\fR<amt>
+.IP
+Maximum total fees to use in a single wallet transaction, setting too
+low may abort large transactions (default: 1.00)
+.HP
+\fB\-upgradewallet\fR
+.IP
+Upgrade wallet to latest format on startup
+.HP
+\fB\-wallet=\fR<file>
+.IP
+Specify wallet file (within data directory) (default: wallet.dat)
+.HP
+\fB\-walletnotify=\fR<cmd>
+.IP
+Execute command when a wallet transaction changes (%s in cmd is replaced
+by TxID)
+.HP
+\fB\-windowtitle=\fR<name>
+.IP
+Wallet window title
+.HP
+\fB\-zapwallettxes=\fR<mode>
+.IP
+Delete all wallet transactions and only recover those parts of the
+blockchain through \fB\-rescan\fR on startup (1 = keep tx meta data e.g.
+account owner and payment request information, 2 = drop tx meta data)
+.PP
+ZeroMQ notification options:
+.HP
+\fB\-zmqpubhashblock=\fR<address>
+.IP
+Enable publish hash block in <address>
+.HP
+\fB\-zmqpubhashtx=\fR<address>
+.IP
+Enable publish hash transaction in <address>
+.HP
+\fB\-zmqpubhashtxlock=\fR<address>
+.IP
+Enable publish hash transaction (locked via SwiftX) in <address>
+.HP
+\fB\-zmqpubrawblock=\fR<address>
+.IP
+Enable publish raw block in <address>
+.HP
+\fB\-zmqpubrawtx=\fR<address>
+.IP
+Enable publish raw transaction in <address>
+.HP
+\fB\-zmqpubrawtxlock=\fR<address>
+.IP
+Enable publish raw transaction (locked via SwiftX) in <address>
+.PP
+Debugging/Testing options:
+.HP
+\fB\-debug=\fR<category>
+.IP
+Output debugging information (default: 0, supplying <category> is
+optional). If <category> is not supplied, output all debugging
+information.<category> can be: addrman, alert, bench, coindb, db, lock,
+rand, rpc, selectcoins, tor, mempool, net, proxy, http, libevent, agrarian,
+(obfuscation, swiftx, masternode, mnpayments, mnbudget, zero), qt.
+.HP
+\fB\-gen\fR
+.IP
+Generate coins (default: 0)
+.HP
+\fB\-genproclimit=\fR<n>
+.IP
+Set the number of threads for coin generation if enabled (\fB\-1\fR = all
+cores, default: 1)
+.HP
+\fB\-help\-debug\fR
+.IP
+Show all debugging options (usage: \fB\-\-help\fR \fB\-help\-debug\fR)
+.HP
+\fB\-logips\fR
+.IP
+Include IP addresses in debug output (default: 0)
+.HP
+\fB\-logtimestamps\fR
+.IP
+Prepend debug output with timestamp (default: 1)
+.HP
+\fB\-minrelaytxfee=\fR<amt>
+.IP
+Fees (in AGR/Kb) smaller than this are considered zero fee for relaying
+(default: 0.0001)
+.HP
+\fB\-printtoconsole\fR
+.IP
+Send trace/debug info to console instead of debug.log file (default: 0)
+.HP
+\fB\-shrinkdebugfile\fR
+.IP
+Shrink debug.log file on client startup (default: 1 when no \fB\-debug\fR)
+.HP
+\fB\-testnet\fR
+.IP
+Use the test network
+.HP
+\fB\-litemode=\fR<n>
+.IP
+Disable all Agrarian specific functionality (Masternodes, Zerocoin, SwiftX,
+Budgeting) (0\-1, default: 0)
+.PP
+Staking options:
+.HP
+\fB\-staking=\fR<n>
+.IP
+Enable staking functionality (0\-1, default: 1)
+.HP
+\fB\-agrstake=\fR<n>
+.IP
+Enable or disable staking functionality for AGR inputs (0\-1, default: 1)
+.HP
+\fB\-zagrstake=\fR<n>
+.IP
+Enable or disable staking functionality for zAGR inputs (0\-1, default:
+1)
+.HP
+\fB\-reservebalance=\fR<amt>
+.IP
+Keep the specified amount available for spending at all times (default:
+0)
+.PP
+Masternode options:
+.HP
+\fB\-masternode=\fR<n>
+.IP
+Enable the client to act as a masternode (0\-1, default: 0)
+.HP
+\fB\-mnconf=\fR<file>
+.IP
+Specify masternode configuration file (default: masternode.conf)
+.HP
+\fB\-mnconflock=\fR<n>
+.IP
+Lock masternodes from masternode configuration file (default: 1)
+.HP
+\fB\-masternodeprivkey=\fR<n>
+.IP
+Set the masternode private key
+.HP
+\fB\-masternodeaddr=\fR<n>
+.IP
+Set external address:port to get to this masternode (example:
+128.127.106.235:51336)
+.HP
+\fB\-budgetvotemode=\fR<mode>
+.IP
+Change automatic finalized budget voting behavior. mode=auto: Vote for
+only exact finalized budget match to my generated budget. (string,
+default: auto)
+.PP
+Zerocoin options:
+.HP
+\fB\-enablezeromint=\fR<n>
+.IP
+Enable automatic Zerocoin minting (0\-1, default: 1)
+.HP
+\fB\-zeromintpercentage=\fR<n>
+.IP
+Percentage of automatically minted Zerocoin (1\-100, default: 10)
+.HP
+\fB\-preferredDenom=\fR<n>
+.IP
+Preferred Denomination for automatically minted Zerocoin
+(1/5/10/50/100/500/1000/5000), 0 for no preference. default: 0)
+.HP
+\fB\-backupzagr=\fR<n>
+.IP
+Enable automatic wallet backups triggered after each zAGR minting (0\-1,
+default: 1)
+.HP
+\fB\-zagrbackuppath=\fR<dir|file>
+.IP
+Specify custom backup path to add a copy of any automatic zAGR backup.
+If set as dir, every backup generates a timestamped file. If set as
+file, will rewrite to that file every backup. If backuppath is set as
+well, 4 backups will happen
+.HP
+\fB\-reindexzerocoin=\fR<n>
+.IP
+Delete all zerocoin spends and mints that have been recorded to the
+blockchain database and reindex them (0\-1, default: 0)
+.PP
+SwiftX options:
+.HP
+\fB\-enableswifttx=\fR<n>
+.IP
+Enable SwiftX, show confirmations for locked transactions (bool,
+default: true)
+.HP
+\fB\-swifttxdepth=\fR<n>
+.IP
+Show N confirmations for a successfully locked transaction (0\-9999,
+default: 5)
+.PP
+Node relay options:
+.HP
+\fB\-datacarrier\fR
+.IP
+Relay and mine data carrier transactions (default: 1)
+.HP
+\fB\-datacarriersize\fR
+.IP
+Maximum size of data in data carrier transactions we relay and mine
+(default: 83)
+.PP
+Block creation options:
+.HP
+\fB\-blockminsize=\fR<n>
+.IP
+Set minimum block size in bytes (default: 0)
+.HP
+\fB\-blockmaxsize=\fR<n>
+.IP
+Set maximum block size in bytes (default: 750000)
+.HP
+\fB\-blockprioritysize=\fR<n>
+.IP
+Set maximum size of high\-priority/low\-fee transactions in bytes
+(default: 50000)
+.PP
+RPC server options:
+.HP
+\fB\-server\fR
+.IP
+Accept command line and JSON\-RPC commands
+.HP
+\fB\-rest\fR
+.IP
+Accept public REST requests (default: 0)
+.HP
+\fB\-rpcbind=\fR<addr>
+.IP
+Bind to given address to listen for JSON\-RPC connections. Use
+[host]:port notation for IPv6. This option can be specified multiple
+times (default: bind to all interfaces)
+.HP
+\fB\-rpccookiefile=\fR<loc>
+.IP
+Location of the auth cookie (default: data dir)
+.HP
+\fB\-rpcuser=\fR<user>
+.IP
+Username for JSON\-RPC connections
+.HP
+\fB\-rpcpassword=\fR<pw>
+.IP
+Password for JSON\-RPC connections
+.HP
+\fB\-rpcport=\fR<port>
+.IP
+Listen for JSON\-RPC connections on <port> (default: 51335 or testnet:
+61335)
+.HP
+\fB\-rpcallowip=\fR<ip>
+.IP
+Allow JSON\-RPC connections from specified source. Valid for <ip> are a
+single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0)
+or a network/CIDR (e.g. 1.2.3.4/24). This option can be specified
+multiple times
+.HP
+\fB\-rpcthreads=\fR<n>
+.IP
+Set the number of threads to service RPC calls (default: 4)
+.PP
+UI Options:
+.HP
+\fB\-choosedatadir\fR
+.IP
+Choose data directory on startup (default: 0)
+.HP
+\fB\-lang=\fR<lang>
+.IP
+Set language, for example "de_DE" (default: system locale)
+.HP
+\fB\-min\fR
+.IP
+Start minimized
+.HP
+\fB\-rootcertificates=\fR<file>
+.IP
+Set SSL root certificates for payment request (default: \fB\-system\-\fR)
+.HP
+\fB\-splash\fR
+.IP
+Show splash screen on startup (default: 1)
+.SH COPYRIGHT
+Copyright (C) 2009-2018 The Bitcoin Core Developers
+
+Copyright (C) 2014-2018 The Dash Core Developers
+
+Copyright (C) 2015-2018 The PIVX Core Developers
+
+This is experimental software.
+
+Distributed under the MIT software license, see the accompanying file COPYING
+or <http://www.opensource.org/licenses/mit-license.php>.
+
+This product includes software developed by the OpenSSL Project for use in the
+OpenSSL Toolkit <https://www.openssl.org/> and cryptographic software written
+by Eric Young and UPnP software written by Thomas Bernard.
@@ -0,0 +1,100 @@
+.\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.47.4.
+.TH Agrarian-TX "1" "July 2018" "agrarian-tx v3.1.99.0" "User Commands"
+.SH NAME
+agrarian-tx \- manual page for agrarian-tx v3.1.99.0
+.SH DESCRIPTION
+Agrarian Core agrarian\-tx utility version v3.1.99.0\-11f4a2bba4\-dirty
+.SS "Usage:"
+.TP
+agrarian\-tx [options] <hex\-tx> [commands]
+Update hex\-encoded agrarian transaction
+.TP
+agrarian\-tx [options] \fB\-create\fR [commands]
+Create hex\-encoded agrarian transaction
+.SH OPTIONS
+.HP
+\-?
+.IP
+This help message
+.HP
+\fB\-create\fR
+.IP
+Create new, empty TX.
+.HP
+\fB\-json\fR
+.IP
+Select JSON output
+.HP
+\fB\-txid\fR
+.IP
+Output only the hex\-encoded transaction id of the resultant transaction.
+.HP
+\fB\-regtest\fR
+.IP
+Enter regression test mode, which uses a special chain in which blocks
+can be solved instantly.
+.HP
+\fB\-testnet\fR
+.IP
+Use the test network
+.PP
+Commands:
+.IP
+delin=N
+.IP
+Delete input N from TX
+.IP
+delout=N
+.IP
+Delete output N from TX
+.IP
+in=TXID:VOUT
+.IP
+Add input to TX
+.IP
+locktime=N
+.IP
+Set TX lock time to N
+.IP
+nversion=N
+.IP
+Set TX version to N
+.IP
+outaddr=VALUE:ADDRESS
+.IP
+Add address\-based output to TX
+.IP
+outscript=VALUE:SCRIPT
+.IP
+Add raw script output to TX
+.IP
+sign=SIGHASH\-FLAGS
+.IP
+Add zero or more signatures to transaction. This command requires JSON
+registers:prevtxs=JSON object, privatekeys=JSON object. See
+signrawtransaction docs for format of sighash flags, JSON objects.
+.PP
+Register Commands:
+.IP
+load=NAME:FILENAME
+.IP
+Load JSON file FILENAME into register NAME
+.IP
+set=NAME:JSON\-STRING
+.IP
+Set register NAME to given JSON\-STRING
+.SH COPYRIGHT
+Copyright (C) 2009-2018 The Bitcoin Core Developers
+
+Copyright (C) 2014-2018 The Dash Core Developers
+
+Copyright (C) 2015-2018 The PIVX Core Developers
+
+This is experimental software.
+
+Distributed under the MIT software license, see the accompanying file COPYING
+or <http://www.opensource.org/licenses/mit-license.php>.
+
+This product includes software developed by the OpenSSL Project for use in the
+OpenSSL Toolkit <https://www.openssl.org/> and cryptographic software written
+by Eric Young and UPnP software written by Thomas Bernard.
@@ -0,0 +1,572 @@
+.\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.47.4.
+.TH AgrarianD "1" "July 2018" "agrariand v3.1.99.0" "User Commands"
+.SH NAME
+agrariand \- manual page for agrariand v3.1.99.0
+.SH DESCRIPTION
+Agrarian Core Daemon version v3.1.99.0\-11f4a2bba4\-dirty
+.SS "Usage:"
+.TP
+agrariand [options]
+Start Agrarian Core Daemon
+.SH OPTIONS
+.HP
+\-?
+.IP
+This help message
+.HP
+\fB\-version\fR
+.IP
+Print version and exit
+.HP
+\fB\-alertnotify=\fR<cmd>
+.IP
+Execute command when a relevant alert is received or we see a really
+long fork (%s in cmd is replaced by message)
+.HP
+\fB\-alerts\fR
+.IP
+Receive and display P2P network alerts (default: 1)
+.HP
+\fB\-blocknotify=\fR<cmd>
+.IP
+Execute command when the best block changes (%s in cmd is replaced by
+block hash)
+.HP
+\fB\-blocksizenotify=\fR<cmd>
+.IP
+Execute command when the best block changes and its size is over (%s in
+cmd is replaced by block hash, %d with the block size)
+.HP
+\fB\-checkblocks=\fR<n>
+.IP
+How many blocks to check at startup (default: 500, 0 = all)
+.HP
+\fB\-conf=\fR<file>
+.IP
+Specify configuration file (default: agrarian.conf)
+.HP
+\fB\-daemon\fR
+.IP
+Run in the background as a daemon and accept commands
+.HP
+\fB\-datadir=\fR<dir>
+.IP
+Specify data directory
+.HP
+\fB\-dbcache=\fR<n>
+.IP
+Set database cache size in megabytes (4 to 4096, default: 100)
+.HP
+\fB\-loadblock=\fR<file>
+.IP
+Imports blocks from external blk000??.dat file on startup
+.HP
+\fB\-maxreorg=\fR<n>
+.IP
+Set the Maximum reorg depth (default: 100)
+.HP
+\fB\-maxorphantx=\fR<n>
+.IP
+Keep at most <n> unconnectable transactions in memory (default: 100)
+.HP
+\fB\-par=\fR<n>
+.IP
+Set the number of script verification threads (\fB\-8\fR to 16, 0 = auto, <0 =
+leave that many cores free, default: 0)
+.HP
+\fB\-pid=\fR<file>
+.IP
+Specify pid file (default: agrariand.pid)
+.HP
+\fB\-reindex\fR
+.IP
+Rebuild block chain index from current blk000??.dat files on startup
+.HP
+\fB\-reindexaccumulators\fR
+.IP
+Reindex the accumulator database on startup
+.HP
+\fB\-reindexmoneysupply\fR
+.IP
+Reindex the AGR and zAGR money supply statistics on startup
+.HP
+\fB\-resync\fR
+.IP
+Delete blockchain folders and resync from scratch on startup
+.HP
+\fB\-sysperms\fR
+.IP
+Create new files with system default permissions, instead of umask 077
+(only effective with disabled wallet functionality)
+.HP
+\fB\-txindex\fR
+.IP
+Maintain a full transaction index, used by the getrawtransaction rpc
+call (default: 0)
+.HP
+\fB\-forcestart\fR
+.IP
+Attempt to force blockchain corruption recovery on startup
+.PP
+Connection options:
+.HP
+\fB\-addnode=\fR<ip>
+.IP
+Add a node to connect to and attempt to keep the connection open
+.HP
+\fB\-banscore=\fR<n>
+.IP
+Threshold for disconnecting misbehaving peers (default: 100)
+.HP
+\fB\-bantime=\fR<n>
+.IP
+Number of seconds to keep misbehaving peers from reconnecting (default:
+86400)
+.HP
+\fB\-bind=\fR<addr>
+.IP
+Bind to given address and always listen on it. Use [host]:port notation
+for IPv6
+.HP
+\fB\-connect=\fR<ip>
+.IP
+Connect only to the specified node(s)
+.HP
+\fB\-discover\fR
+.IP
+Discover own IP address (default: 1 when listening and no \fB\-externalip\fR)
+.HP
+\fB\-dns\fR
+.IP
+Allow DNS lookups for \fB\-addnode\fR, \fB\-seednode\fR and \fB\-connect\fR (default: 1)
+.HP
+\fB\-dnsseed\fR
+.IP
+Query for peer addresses via DNS lookup, if low on addresses (default: 1
+unless \fB\-connect\fR)
+.HP
+\fB\-externalip=\fR<ip>
+.IP
+Specify your own public address
+.HP
+\fB\-forcednsseed\fR
+.IP
+Always query for peer addresses via DNS lookup (default: 0)
+.HP
+\fB\-listen\fR
+.IP
+Accept connections from outside (default: 1 if no \fB\-proxy\fR or \fB\-connect\fR)
+.HP
+\fB\-listenonion\fR
+.IP
+Automatically create Tor hidden service (default: 1)
+.HP
+\fB\-maxconnections=\fR<n>
+.IP
+Maintain at most <n> connections to peers (default: 125)
+.HP
+\fB\-maxreceivebuffer=\fR<n>
+.IP
+Maximum per\-connection receive buffer, <n>*1000 bytes (default: 5000)
+.HP
+\fB\-maxsendbuffer=\fR<n>
+.IP
+Maximum per\-connection send buffer, <n>*1000 bytes (default: 1000)
+.HP
+\fB\-onion=\fR<ip:port>
+.IP
+Use separate SOCKS5 proxy to reach peers via Tor hidden services
+(default: \fB\-proxy\fR)
+.HP
+\fB\-onlynet=\fR<net>
+.IP
+Only connect to nodes in network <net> (ipv4, ipv6 or onion)
+.HP
+\fB\-permitbaremultisig\fR
+.IP
+Relay non\-P2SH multisig (default: 1)
+.HP
+\fB\-peerbloomfilters\fR
+.IP
+Support filtering of blocks and transaction with bloom filters (default:
+1)
+.HP
+\fB\-port=\fR<port>
+.IP
+Listen for connections on <port> (default: 51336 or testnet: 61336)
+.HP
+\fB\-proxy=\fR<ip:port>
+.IP
+Connect through SOCKS5 proxy
+.HP
+\fB\-proxyrandomize\fR
+.IP
+Randomize credentials for every proxy connection. This enables Tor
+stream isolation (default: 1)
+.HP
+\fB\-seednode=\fR<ip>
+.IP
+Connect to a node to retrieve peer addresses, and disconnect
+.HP
+\fB\-timeout=\fR<n>
+.IP
+Specify connection timeout in milliseconds (minimum: 1, default: 5000)
+.HP
+\fB\-torcontrol=\fR<ip>:<port>
+.IP
+Tor control port to use if onion listening enabled (default:
+127.0.0.1:9051)
+.HP
+\fB\-torpassword=\fR<pass>
+.IP
+Tor control port password (default: empty)
+.HP
+\fB\-upnp\fR
+.IP
+Use UPnP to map the listening port (default: 0)
+.HP
+\fB\-whitebind=\fR<addr>
+.IP
+Bind to given address and whitelist peers connecting to it. Use
+[host]:port notation for IPv6
+.HP
+\fB\-whitelist=\fR<netmask>
+.IP
+Whitelist peers connecting from the given netmask or IP address. Can be
+specified multiple times. Whitelisted peers cannot be DoS banned and
+their transactions are always relayed, even if they are already in the
+mempool, useful e.g. for a gateway
+.PP
+Wallet options:
+.HP
+\fB\-backuppath=\fR<dir|file>
+.IP
+Specify custom backup path to add a copy of any wallet backup. If set as
+dir, every backup generates a timestamped file. If set as file, will
+rewrite to that file every backup.
+.HP
+\fB\-createwalletbackups=\fR<n>
+.IP
+Number of automatic wallet backups (default: 10)
+.HP
+\fB\-custombackupthreshold=\fR<n>
+.IP
+Number of custom location backups to retain (default: 1)
+.HP
+\fB\-disablewallet\fR
+.IP
+Do not load the wallet and disable wallet RPC calls
+.HP
+\fB\-keypool=\fR<n>
+.IP
+Set key pool size to <n> (default: 100)
+.HP
+\fB\-paytxfee=\fR<amt>
+.IP
+Fee (in AGR/kB) to add to transactions you send (default: 0.00)
+.HP
+\fB\-rescan\fR
+.IP
+Rescan the block chain for missing wallet transactions on startup
+.HP
+\fB\-salvagewallet\fR
+.IP
+Attempt to recover private keys from a corrupt wallet.dat on startup
+.HP
+\fB\-sendfreetransactions\fR
+.IP
+Send transactions as zero\-fee transactions if possible (default: 0)
+.HP
+\fB\-spendzeroconfchange\fR
+.IP
+Spend unconfirmed change when sending transactions (default: 1)
+.HP
+\fB\-disablesystemnotifications\fR
+.IP
+Disable OS notifications for incoming transactions (default: 0)
+.HP
+\fB\-txconfirmtarget=\fR<n>
+.IP
+If paytxfee is not set, include enough fee so transactions begin
+confirmation on average within n blocks (default: 1)
+.HP
+\fB\-maxtxfee=\fR<amt>
+.IP
+Maximum total fees to use in a single wallet transaction, setting too
+low may abort large transactions (default: 1.00)
+.HP
+\fB\-upgradewallet\fR
+.IP
+Upgrade wallet to latest format on startup
+.HP
+\fB\-wallet=\fR<file>
+.IP
+Specify wallet file (within data directory) (default: wallet.dat)
+.HP
+\fB\-walletnotify=\fR<cmd>
+.IP
+Execute command when a wallet transaction changes (%s in cmd is replaced
+by TxID)
+.HP
+\fB\-zapwallettxes=\fR<mode>
+.IP
+Delete all wallet transactions and only recover those parts of the
+blockchain through \fB\-rescan\fR on startup (1 = keep tx meta data e.g.
+account owner and payment request information, 2 = drop tx meta data)
+.PP
+ZeroMQ notification options:
+.HP
+\fB\-zmqpubhashblock=\fR<address>
+.IP
+Enable publish hash block in <address>
+.HP
+\fB\-zmqpubhashtx=\fR<address>
+.IP
+Enable publish hash transaction in <address>
+.HP
+\fB\-zmqpubhashtxlock=\fR<address>
+.IP
+Enable publish hash transaction (locked via SwiftX) in <address>
+.HP
+\fB\-zmqpubrawblock=\fR<address>
+.IP
+Enable publish raw block in <address>
+.HP
+\fB\-zmqpubrawtx=\fR<address>
+.IP
+Enable publish raw transaction in <address>
+.HP
+\fB\-zmqpubrawtxlock=\fR<address>
+.IP
+Enable publish raw transaction (locked via SwiftX) in <address>
+.PP
+Debugging/Testing options:
+.HP
+\fB\-debug=\fR<category>
+.IP
+Output debugging information (default: 0, supplying <category> is
+optional). If <category> is not supplied, output all debugging
+information.<category> can be: addrman, alert, bench, coindb, db, lock,
+rand, rpc, selectcoins, tor, mempool, net, proxy, http, libevent, agrarian,
+(obfuscation, swiftx, masternode, mnpayments, mnbudget, zero).
+.HP
+\fB\-gen\fR
+.IP
+Generate coins (default: 0)
+.HP
+\fB\-genproclimit=\fR<n>
+.IP
+Set the number of threads for coin generation if enabled (\fB\-1\fR = all
+cores, default: 1)
+.HP
+\fB\-help\-debug\fR
+.IP
+Show all debugging options (usage: \fB\-\-help\fR \fB\-help\-debug\fR)
+.HP
+\fB\-logips\fR
+.IP
+Include IP addresses in debug output (default: 0)
+.HP
+\fB\-logtimestamps\fR
+.IP
+Prepend debug output with timestamp (default: 1)
+.HP
+\fB\-minrelaytxfee=\fR<amt>
+.IP
+Fees (in AGR/Kb) smaller than this are considered zero fee for relaying
+(default: 0.0001)
+.HP
+\fB\-printtoconsole\fR
+.IP
+Send trace/debug info to console instead of debug.log file (default: 0)
+.HP
+\fB\-shrinkdebugfile\fR
+.IP
+Shrink debug.log file on client startup (default: 1 when no \fB\-debug\fR)
+.HP
+\fB\-testnet\fR
+.IP
+Use the test network
+.HP
+\fB\-litemode=\fR<n>
+.IP
+Disable all Agrarian specific functionality (Masternodes, Zerocoin, SwiftX,
+Budgeting) (0\-1, default: 0)
+.PP
+Staking options:
+.HP
+\fB\-staking=\fR<n>
+.IP
+Enable staking functionality (0\-1, default: 1)
+.HP
+\fB\-agrstake=\fR<n>
+.IP
+Enable or disable staking functionality for AGR inputs (0\-1, default: 1)
+.HP
+\fB\-zagrstake=\fR<n>
+.IP
+Enable or disable staking functionality for zAGR inputs (0\-1, default:
+1)
+.HP
+\fB\-reservebalance=\fR<amt>
+.IP
+Keep the specified amount available for spending at all times (default:
+0)
+.PP
+Masternode options:
+.HP
+\fB\-masternode=\fR<n>
+.IP
+Enable the client to act as a masternode (0\-1, default: 0)
+.HP
+\fB\-mnconf=\fR<file>
+.IP
+Specify masternode configuration file (default: masternode.conf)
+.HP
+\fB\-mnconflock=\fR<n>
+.IP
+Lock masternodes from masternode configuration file (default: 1)
+.HP
+\fB\-masternodeprivkey=\fR<n>
+.IP
+Set the masternode private key
+.HP
+\fB\-masternodeaddr=\fR<n>
+.IP
+Set external address:port to get to this masternode (example:
+128.127.106.235:51336)
+.HP
+\fB\-budgetvotemode=\fR<mode>
+.IP
+Change automatic finalized budget voting behavior. mode=auto: Vote for
+only exact finalized budget match to my generated budget. (string,
+default: auto)
+.PP
+Zerocoin options:
+.HP
+\fB\-enablezeromint=\fR<n>
+.IP
+Enable automatic Zerocoin minting (0\-1, default: 1)
+.HP
+\fB\-zeromintpercentage=\fR<n>
+.IP
+Percentage of automatically minted Zerocoin (1\-100, default: 10)
+.HP
+\fB\-preferredDenom=\fR<n>
+.IP
+Preferred Denomination for automatically minted Zerocoin
+(1/5/10/50/100/500/1000/5000), 0 for no preference. default: 0)
+.HP
+\fB\-backupzagr=\fR<n>
+.IP
+Enable automatic wallet backups triggered after each zAGR minting (0\-1,
+default: 1)
+.HP
+\fB\-zagrbackuppath=\fR<dir|file>
+.IP
+Specify custom backup path to add a copy of any automatic zAGR backup.
+If set as dir, every backup generates a timestamped file. If set as
+file, will rewrite to that file every backup. If backuppath is set as
+well, 4 backups will happen
+.HP
+\fB\-reindexzerocoin=\fR<n>
+.IP
+Delete all zerocoin spends and mints that have been recorded to the
+blockchain database and reindex them (0\-1, default: 0)
+.PP
+SwiftX options:
+.HP
+\fB\-enableswifttx=\fR<n>
+.IP
+Enable SwiftX, show confirmations for locked transactions (bool,
+default: true)
+.HP
+\fB\-swifttxdepth=\fR<n>
+.IP
+Show N confirmations for a successfully locked transaction (0\-9999,
+default: 5)
+.PP
+Node relay options:
+.HP
+\fB\-datacarrier\fR
+.IP
+Relay and mine data carrier transactions (default: 1)
+.HP
+\fB\-datacarriersize\fR
+.IP
+Maximum size of data in data carrier transactions we relay and mine
+(default: 83)
+.PP
+Block creation options:
+.HP
+\fB\-blockminsize=\fR<n>
+.IP
+Set minimum block size in bytes (default: 0)
+.HP
+\fB\-blockmaxsize=\fR<n>
+.IP
+Set maximum block size in bytes (default: 750000)
+.HP
+\fB\-blockprioritysize=\fR<n>
+.IP
+Set maximum size of high\-priority/low\-fee transactions in bytes
+(default: 50000)
+.PP
+RPC server options:
+.HP
+\fB\-server\fR
+.IP
+Accept command line and JSON\-RPC commands
+.HP
+\fB\-rest\fR
+.IP
+Accept public REST requests (default: 0)
+.HP
+\fB\-rpcbind=\fR<addr>
+.IP
+Bind to given address to listen for JSON\-RPC connections. Use
+[host]:port notation for IPv6. This option can be specified multiple
+times (default: bind to all interfaces)
+.HP
+\fB\-rpccookiefile=\fR<loc>
+.IP
+Location of the auth cookie (default: data dir)
+.HP
+\fB\-rpcuser=\fR<user>
+.IP
+Username for JSON\-RPC connections
+.HP
+\fB\-rpcpassword=\fR<pw>
+.IP
+Password for JSON\-RPC connections
+.HP
+\fB\-rpcport=\fR<port>
+.IP
+Listen for JSON\-RPC connections on <port> (default: 51335 or testnet:
+61335)
+.HP
+\fB\-rpcallowip=\fR<ip>
+.IP
+Allow JSON\-RPC connections from specified source. Valid for <ip> are a
+single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0)
+or a network/CIDR (e.g. 1.2.3.4/24). This option can be specified
+multiple times
+.HP
+\fB\-rpcthreads=\fR<n>
+.IP
+Set the number of threads to service RPC calls (default: 4)
+.SH COPYRIGHT
+Copyright (C) 2009-2018 The Bitcoin Core Developers
+
+Copyright (C) 2014-2018 The Dash Core Developers
+
+Copyright (C) 2015-2018 The PIVX Core Developers
+
+This is experimental software.
+
+Distributed under the MIT software license, see the accompanying file COPYING
+or <http://www.opensource.org/licenses/mit-license.php>.
+
+This product includes software developed by the OpenSSL Project for use in the
+OpenSSL Toolkit <https://www.openssl.org/> and cryptographic software written
+by Eric Young and UPnP software written by Thomas Bernard.
@@ -0,0 +1,217 @@
+Agrarian Core version *3.3.0* is now available from:  <https://github.com/agrarian-project/agrarian/releases>
+
+This is a new major version release, including various bug fixes and performance improvements, as well as updated translations.
+
+Please report bugs using the issue tracker at github: <https://github.com/agrarian-project/agrarian/issues>
+
+
+Mandatory Update
+==============
+
+Agrarian Core v3.3.0 is a mandatory update for all users. This release contains new consensus rules and improvements that are not backwards compatible with older versions. Users will have a grace period of approximately one week to update their clients before enforcement of this update goes into effect.
+
+Masternodes will need to be restarted once both the masternode daemon and the controller wallet have been upgraded.
+
+How to Upgrade
+==============
+
+If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Agrarian-Qt (on Mac) or agrariand/agrarian-qt (on Linux).
+
+
+Compatibility
+==============
+
+Agrarian Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.10+, and Windows 7 and later.
+
+Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support), No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk but be aware that there are known instabilities and issues. Please do not report issues about Windows XP to the issue tracker.
+
+Apple released it's last Mountain Lion update August 13, 2015, and officially ended support on [December 14, 2015](http://news.fnal.gov/2015/10/mac-os-x-mountain-lion-10-8-end-of-life-december-14/). Agrarian Core software starting with v3.2.0 will no longer run on MacOS versions prior to Yosemite (10.10). Please do not report issues about MacOS versions prior to Yosemite to the issue tracker.
+
+Agrarian Core should also work on most other Unix-like systems but is not frequently tested on them.
+
+ 
+Notable Changes
+==============
+
+## zAGR Public Spends
+
+Recent exploits of the Zerocoin protocol (Wrapped serials and broken P1 proof) required us to enable the zerocoin spork and deactivate zAGR functionality in order to secure the supply until the pertinent review process was completed.
+
+Moving forward from this undesired situation, we are enabling a secure and chain storage friendly solution for the zerocoin public spend (aka zAGR to AGR conversion).
+
+The explanation of how this works can be found in #891
+
+After block `1,880,000` has past, `SPORK_16` will be deactivated to allow zAGR spends to occur using this new public spend method for version 2 zAGR (version 1 zAGR won't be spendable, see note below). zAGR public spends, as the name suggests, are **NOT** private, they reveal the input mint that is being spent. The minting of **NEW** zAGR, as well as zAGR staking will remain disabled for the time being.
+
+It is advised that users spend/convert their existing zAGR to AGR, which can be done via the GUI or RPC as it was prior to the disabling of zAGR. Note that with the public spend method, the restriction on the number of denominations per transaction (previously 7) has been lifted, and now allows for several hundred denominations per transaction.
+
+*Note on version 1 zAGR*: Version 1 zAGR was only available to me minted between versions v3.0.0 (Oct 6, 2017) and v3.1.0 (May 8, 2018). The announcement that version 1 zAGR was deprecated went out on May 1, 2018 with a recommendation for users to spend/convert their version 1 zAGR.
+
+Version 1 zAGR will be made spendable at a later date due to the extra work required in order to make these version 1 mints spendable.
+
+## GUI Changes
+
+### Options Dialog Cleanup
+
+The options/settings UI dialog has been cleaned up to no longer show settings that are wallet related when running in "disable wallet" (`-disablewallet`) mode.
+
+### Privacy Tab
+
+Notice text has been added to the privacy tab indicating that zAGR minting is disabled, as well as the removal of UI elements that supported such functionality. Notice text has also been added indicating that zAGR spends are currently **NOT** private.
+
+## RPC Changes
+
+### Removal of Deprecated Commands
+
+The `masternode` and `mnbudget` RPC commands, which were marked as deprecated in Agrarian Core v2.3.1 (September 19, 2017), have now been completely removed from Agrarian Core.
+
+Several new commands were added in v2.3.1 to replace the two aforementioned commands, reference the [v2.3.1 Release Notes](https://github.com/Agrarian-Project/Agrarian/blob/master/doc/release-notes/release-notes-2.3.1.md#rpc-changes) for further details.
+
+### New `getblockindexstats` Command
+
+A new RPC command (`getblockindexstats`) has been introduced which serves the purpose of obtaining statistical information on a range of blocks. The information returned is as follows:
+  * transaction count (not including coinbase/coinstake txes)
+  * transaction count (including coinbase/coinstake txes)
+  * zAGR per-denom mint count
+  * zAGR per-denom spend count
+  * total transaction bytes
+  * total fees in block range
+  * average fee per kB
+
+Command Reference:
+```$xslt
+getblockindexstats height range ( fFeeOnly )
+nReturns aggregated BlockIndex data for blocks
+height, height+1, height+2, ..., height+range-1]
+
+nArguments:
+1. height             (numeric, required) block height where the search starts.
+2. range              (numeric, required) number of blocks to include.
+3. fFeeOnly           (boolean, optional, default=False) return only fee info.
+```
+Result:
+```
+{
+  first_block: x,              (integer) First counted block
+  last_block: x,               (integer) Last counted block
+  txcount: xxxxx,              (numeric) tx count (excluding coinbase/coinstake)
+  txcount_all: xxxxx,          (numeric) tx count (including coinbase/coinstake)
+  mintcount: {              [if fFeeOnly=False]
+        denom_1: xxxx,         (numeric) number of mints of denom_1 occurred over the block range
+        denom_5: xxxx,         (numeric) number of mints of denom_5 occurred over the block range
+         ...                    ... number of mints of other denominations: ..., 10, 50, 100, 500, 1000, 5000
+  },
+  spendcount: {             [if fFeeOnly=False]
+        denom_1: xxxx,         (numeric) number of spends of denom_1 occurred over the block range
+        denom_5: xxxx,         (numeric) number of spends of denom_5 occurred over the block range
+         ...                    ... number of spends of other denominations: ..., 10, 50, 100, 500, 1000, 5000
+  },
+  pubspendcount: {          [if fFeeOnly=False]
+        denom_1: xxxx,         (numeric) number of PUBLIC spends of denom_1 occurred over the block range
+        denom_5: xxxx,         (numeric) number of PUBLIC spends of denom_5 occurred over the block range
+         ...                   ... number of PUBLIC spends of other denominations: ..., 10, 50, 100, 500, 1000, 5000
+  },
+  txbytes: xxxxx,              (numeric) Sum of the size of all txes (zAGR excluded) over block range
+  ttlfee: xxxxx,               (numeric) Sum of the fee amount of all txes (zAGR mints excluded) over block range
+  ttlfee_all: xxxxx,           (numeric) Sum of the fee amount of all txes (zAGR mints included) over block range
+  feeperkb: xxxxx,             (numeric) Average fee per kb (excluding zc txes)
+}
+```
+
+## Build System Changes
+
+### New Architectures for Depends
+
+The depends system has new added support for the `s390x` and `ppc64el` architectures. This is done in order to support the future integration with [Snapcraft](https://www.snapcraft.io), as well as to support any developers who may use systems based on such architectures.
+
+### Basic CMake Support
+
+While the existing Autotools based build system is our standard build system, and will continue to be so, we have added basic support for compiling with CMake on macOS and linux systems.
+
+This is intended to be used in conjunction with IDEs like CLion (which relies heavily on CMake) in order to streamline the development process. Developers can now use, for example, CLion's internal debugger and profiling tools.
+
+Note that it is still required to have relevant dependencies installed on the system for this to function properly.
+
+*3.3.0* Change log
+==============
+
+Detailed release notes follow. This overview includes changes that affect behavior, not code moves, refactors and string updates. For convenience in locating the code changes and accompanying discussion, both the pull request and git merge commit are mentioned.
+
+### Core
+ - #875 `a99c2dd3bb` [Zerocoin] GMP BigNum: Fix limits for random number generators (random-zebra)
+ - #888 `0c071c3fd0` [Zerocoin] remove CTransaction::IsZerocoinSpend/IsZerocoinMint (random-zebra)
+ - #891 `855408c2c3` [ZAGR] Zerocoin public coin spend. (furszy)
+ - #897 `65bd788945` [zAGR] Disable zerocoin minting (random-zebra)
+ - #899 `4b22a09024` [zAGR] Disable zAGR staking (random-zebra)
+ - #909 `458b08c8f2` [Consensus] Mainnet public spend enforcement height set. (furszy)
+ - #924 `988b33dab8` [Backport] Max tip age to consider a node in IBD status customizable. (furszy)
+ - #925 `a9827a0e63` [Consensus] Time checks (warrows)
+
+### Build System
+ - #810 `a373fee908` [Depends] Fix archs (fixes s390x and ppc64el builds on snap) (cevap)
+ - #906 `8a47747b59` [Build] Add CMake Support (Fuzzbawls)
+ - #910 `07c8fb8f88` [Build] Clean all coverage files during make clean (Fuzzbawls)
+ - #913 `473976c619` [Depends] Update from upstream (Fuzzbawls)
+ - #914 `5a43ea790a` [Gitian] Bump gitian build versions (Fuzzbawls)
+ - #917 `b38ef04838` [Build] TravisCI Update (Fuzzbawls)
+ - #922 `0f98fd4d3f` [Build] Fix app name casing in mac deploy related files (Fuzzbawls)
+
+### P2P Protocol and Network Code
+ - #908 `95b584effd` [NET] Non-running dns servers removed from chainParams. (furszy)
+ - #929 `7e8855d910` [Net] Update hard-coded seeds (Fuzzbawls)
+ - #930 `5061b486c2` [Net] Add a couple new testnet checkpoints (Fuzzbawls)
+
+### GUI
+ - #874 `23f17ce021` [Qt] Add new budget colors (warrows)
+ - #895 `0417d52ef9` [QT] Options UI cleanup (Alko89)
+ - #896 `b2fcefee93` [UI] Simplify Qt margins. (warrows)
+ - #898 `3d496cc746` [Qt] Fixup duplicate label names (Fuzzbawls)
+ - #900 `5f7559bc7b` [UI] Fix improperly parented walletView and segmentation fault on QT 5.10 (Julian Meyer)
+ - #928 `2482572f89` [Qt] Update Translations (Fuzzbawls)
+
+### RPC/REST
+ - #877 `54c8832d80` [RPC] Remove deprecated masternode/budget RPC commands (Fuzzbawls)
+ - #901 `be3aab4a00` [RPC] Fix typos and oversights in listunspent (CaveSpectre11)
+ - #911 `484c070b22` [RPC] add 'getblockindexstats' function (random-zebra)
+
+### Wallet
+ - #813 `80bf51e7c9` [Refactoring] [Move Only] Move wallet files into their own folder (warrows)
+ - #916 `a4f02ed946` [Staking] Don't assert if we were beaten to the block (CaveSpectre11)
+
+### Unit Tests
+ - #806 `fc6b5a191d` [Test] Create new per-test fixtures (Wladimir J. van der Laan)
+ - #902 `8adeeb9727` [Tests] Add tests for CAddrMan (warrows)
+
+### Miscellaneous
+ - #744 `7e52f58b82` [Refactor] Refactor bignum header file into several files (warrows)
+ - #808 `8b54f7150b` [Scripts] Add optimize pngs python script (cevap)
+ - #824 `3323f26848` [Refactor] Remove stale obfuscation code (Fuzzbawls)
+ - #830 `81038da4f8` [Refactor] Remove BOOST_FOREACH (Fuzzbawls)
+ - #844 `0a0dcf0d4e` [Refactor] Replace deprecated auto_ptr with unique_ptr (cevap)
+ - #856 `da26ddeeb9` [Refactor] Move per-chain budget cycle blocks to chainparams (Fuzzbawls)
+ - #879 `5f0d72659c` [Refactor] Rename ui_interface.h file (Fuzzbawls)
+ - #890 `fddac44eab` [Refactor] Remove unused setStakeSeen variable (warrows)
+ - #903 `68c81c407a` [Log] Handle errors during log message formatting (warrows)
+ - #904 `6f597629d8` [zAGR] Free memory from ToString() (warrows)
+ - #912 `5f167c2c7e` [Cleanup] compiler warnings in coinSpend object. (furszy)
+ - #919 `c0233e4af6` [zAGR] Debug missing jump line. (Matias Furszyfer)
+ - #920 `a56cc2948d` [Docs] Overhaul documentation files (Fuzzbawls)
+ - #921 `893183339e` [Scripts] Overhaul supplemental python/shell scripts (Fuzzbawls)
+ - #926 `49a69b8931` [Doc] 3.3.0 Notable Changes (Fuzzbawls)
+ - #927 `048d1295dc` [Trivial] Update header copyright years (Fuzzbawls)
+ 
+## Credits
+
+Thanks to everyone who directly contributed to this release:
+
+ - Alko89
+ - CaveSpectre11
+ - Fuzzbawls
+ - Julian Meyer
+ - Matias Furszyfer
+ - cevap
+ - Wladimir J. van der Laan
+ - random-zebra
+ - warrows
+
+As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/agrarian-project-translations/), the QA team during Testing and the Node hosts supporting our Testnet.
@@ -0,0 +1,292 @@
+Release Process
+====================
+
+## Branch updates
+
+### Before every release candidate
+
+* Update translations (ping Fuzzbawls on Discord) see [translation_process.md](https://github.com/Agrarian-Project/Agrarian/blob/master/doc/translation_process.md#synchronising-translations).
+* Update manpages, see [gen-manpages.sh](https://github.com/agrarian-project/agrarian/blob/master/contrib/devtools/README.md#gen-manpagessh).
+
+### Before every major and minor release
+
+* Update version in `configure.ac` (don't forget to set `CLIENT_VERSION_IS_RELEASE` to `true`)
+* Write release notes (see below)
+
+### Before every major release
+
+* Update hardcoded [seeds](/contrib/seeds/README.md), see [this pull request](https://github.com/bitcoin/bitcoin/pull/7415) for an example.
+* Update [`BLOCK_CHAIN_SIZE`](/src/qt/intro.cpp) to the current size plus some overhead.
+* Update `src/chainparams.cpp` with statistics about the transaction count and rate.
+* On both the master branch and the new release branch:
+  - update `CLIENT_VERSION_MINOR` in [`configure.ac`](../configure.ac)
+* On the new release branch in [`configure.ac`](../configure.ac):
+  - set `CLIENT_VERSION_REVISION` to `0`
+  - set `CLIENT_VERSION_IS_RELEASE` to `true`
+
+
+#### After branch-off (on master)
+
+- Update the version of `contrib/gitian-descriptors/*.yml`.
+
+#### After branch-off (on the major release branch)
+
+- Update the versions and the link to the release notes draft in `doc/release-notes.md`.
+
+#### Before final release
+
+- Merge the release notes into the branch.
+- Ensure the "Needs release note" label is removed from all relevant pull requests and issues.
+
+
+## Building
+
+### First time / New builders
+
+If you're using the automated script (found in [contrib/gitian-build.py](/contrib/gitian-build.py)), then at this point you should run it with the "--setup" command. Otherwise ignore this.
+
+Check out the source code in the following directory hierarchy.
+
+    cd /path/to/your/toplevel/build
+    git clone https://github.com/agrarian-project/gitian.sigs.git
+    git clone https://github.com/agrarian-project/agrarian-detached-sigs.git
+    git clone https://github.com/devrandom/gitian-builder.git
+    git clone https://github.com/agrarian-project/agrarian.git
+
+### Agrarian maintainers/release engineers, suggestion for writing release notes
+
+Write release notes. git shortlog helps a lot, for example:
+
+    git shortlog --no-merges v(current version, e.g. 0.7.2)..v(new version, e.g. 0.8.0)
+
+
+Generate list of authors:
+
+    git log --format='- %aN' v(current version, e.g. 3.2.2)..v(new version, e.g. 3.2.3) | sort -fiu
+
+Tag the version (or release candidate) in git:
+
+    git tag -s v(new version, e.g. 0.8.0)
+
+### Setup and perform Gitian builds
+
+If you're using the automated script (found in [contrib/gitian-build.py](/contrib/gitian-build.py)), then at this point you should run it with the "--build" command. Otherwise ignore this.
+
+Setup Gitian descriptors:
+
+    pushd ./agrarian
+    export SIGNER=(your Gitian key, ie bluematt, sipa, etc)
+    export VERSION=(new version, e.g. 0.8.0)
+    git fetch
+    git checkout v${VERSION}
+    popd
+
+Ensure your gitian.sigs are up-to-date if you wish to gverify your builds against other Gitian signatures.
+
+    pushd ./gitian.sigs
+    git pull
+    popd
+
+Ensure gitian-builder is up-to-date:
+
+    pushd ./gitian-builder
+    git pull
+    popd
+
+### Fetch and create inputs: (first time, or when dependency versions change)
+
+    pushd ./gitian-builder
+    mkdir -p inputs
+    wget -P inputs https://bitcoincore.org/cfields/osslsigncode-Backports-to-1.7.1.patch
+    wget -P inputs http://downloads.sourceforge.net/project/osslsigncode/osslsigncode/osslsigncode-1.7.1.tar.gz
+    popd
+
+Create the macOS SDK tarball, see the [macOS build instructions](build-osx.md#deterministic-macos-dmg-notes) for details, and copy it into the inputs directory.
+
+### Optional: Seed the Gitian sources cache and offline git repositories
+
+NOTE: Gitian is sometimes unable to download files. If you have errors, try the step below.
+
+By default, Gitian will fetch source files as needed. To cache them ahead of time, make sure you have checked out the tag you want to build in agrarian, then:
+
+    pushd ./gitian-builder
+    make -C ../agrarian/depends download SOURCES_PATH=`pwd`/cache/common
+    popd
+
+Only missing files will be fetched, so this is safe to re-run for each build.
+
+NOTE: Offline builds must use the --url flag to ensure Gitian fetches only from local URLs. For example:
+
+    pushd ./gitian-builder
+    ./bin/gbuild --url agrarian=/path/to/agrarian,signature=/path/to/sigs {rest of arguments}
+    popd
+
+The gbuild invocations below <b>DO NOT DO THIS</b> by default.
+
+### Build and sign Agrarian Core for Linux, Windows, and macOS:
+
+    pushd ./gitian-builder
+    ./bin/gbuild --num-make 2 --memory 3000 --commit agrarian=v${VERSION} ../agrarian/contrib/gitian-descriptors/gitian-linux.yml
+    ./bin/gsign --signer "$SIGNER" --release ${VERSION}-linux --destination ../gitian.sigs/ ../agrarian/contrib/gitian-descriptors/gitian-linux.yml
+    mv build/out/agrarian-*.tar.gz build/out/src/agrarian-*.tar.gz ../
+
+    ./bin/gbuild --num-make 2 --memory 3000 --commit agrarian=v${VERSION} ../agrarian/contrib/gitian-descriptors/gitian-win.yml
+    ./bin/gsign --signer "$SIGNER" --release ${VERSION}-win-unsigned --destination ../gitian.sigs/ ../agrarian/contrib/gitian-descriptors/gitian-win.yml
+    mv build/out/agrarian-*-win-unsigned.tar.gz inputs/agrarian-win-unsigned.tar.gz
+    mv build/out/agrarian-*.zip build/out/agrarian-*.exe ../
+
+    ./bin/gbuild --num-make 2 --memory 3000 --commit agrarian=v${VERSION} ../agrarian/contrib/gitian-descriptors/gitian-osx.yml
+    ./bin/gsign --signer "$SIGNER" --release ${VERSION}-osx-unsigned --destination ../gitian.sigs/ ../agrarian/contrib/gitian-descriptors/gitian-osx.yml
+    mv build/out/agrarian-*-osx-unsigned.tar.gz inputs/agrarian-osx-unsigned.tar.gz
+    mv build/out/agrarian-*.tar.gz build/out/agrarian-*.dmg ../
+    popd
+
+Build output expected:
+
+  1. source tarball (`agrarian-${VERSION}.tar.gz`)
+  2. linux 32-bit and 64-bit dist tarballs (`agrarian-${VERSION}-linux[32|64].tar.gz`)
+  3. windows 32-bit and 64-bit unsigned installers and dist zips (`agrarian-${VERSION}-win[32|64]-setup-unsigned.exe`, `agrarian-${VERSION}-win[32|64].zip`)
+  4. macOS unsigned installer and dist tarball (`agrarian-${VERSION}-osx-unsigned.dmg`, `agrarian-${VERSION}-osx64.tar.gz`)
+  5. Gitian signatures (in `gitian.sigs/${VERSION}-<linux|{win,osx}-unsigned>/(your Gitian key)/`)
+
+### Verify other gitian builders signatures to your own. (Optional)
+
+Add other gitian builders keys to your gpg keyring, and/or refresh keys.
+
+    gpg --import agrarian/contrib/gitian-keys/*.pgp
+    gpg --refresh-keys
+
+Verify the signatures
+
+    pushd ./gitian-builder
+    ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-linux ../agrarian/contrib/gitian-descriptors/gitian-linux.yml
+    ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-unsigned ../agrarian/contrib/gitian-descriptors/gitian-win.yml
+    ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-unsigned ../agrarian/contrib/gitian-descriptors/gitian-osx.yml
+    popd
+
+### Next steps:
+
+Commit your signature to gitian.sigs:
+
+    pushd gitian.sigs
+    git add ${VERSION}-linux/"${SIGNER}"
+    git add ${VERSION}-win-unsigned/"${SIGNER}"
+    git add ${VERSION}-osx-unsigned/"${SIGNER}"
+    git commit -m "Add ${VERSION} unsigned sigs for ${SIGNER}"
+    git push  # Assuming you can push to the gitian.sigs tree
+    popd
+
+Codesigner only: Create Windows/macOS detached signatures:
+- Only one person handles codesigning. Everyone else should skip to the next step.
+- Only once the Windows/macOS builds each have 3 matching signatures may they be signed with their respective release keys.
+
+Codesigner only: Sign the macOS binary:
+
+    transfer agrarian-osx-unsigned.tar.gz to macOS for signing
+    tar xf agrarian-osx-unsigned.tar.gz
+    ./detached-sig-create.sh -s "Key ID"
+    Enter the keychain password and authorize the signature
+    Move signature-osx.tar.gz back to the gitian host
+
+Codesigner only: Sign the windows binaries:
+
+    tar xf agrarian-win-unsigned.tar.gz
+    ./detached-sig-create.sh -key /path/to/codesign.key
+    Enter the passphrase for the key when prompted
+    signature-win.tar.gz will be created
+
+Codesigner only: Commit the detached codesign payloads:
+
+    cd ~/agrarian-detached-sigs
+    checkout the appropriate branch for this release series
+    rm -rf *
+    tar xf signature-osx.tar.gz
+    tar xf signature-win.tar.gz
+    git add -a
+    git commit -m "point to ${VERSION}"
+    git tag -s v${VERSION} HEAD
+    git push the current branch and new tag
+
+Non-codesigners: wait for Windows/macOS detached signatures:
+
+- Once the Windows/macOS builds each have 3 matching signatures, they will be signed with their respective release keys.
+- Detached signatures will then be committed to the [agrarian-detached-sigs](https://github.com/agrarian-Project/agrarian-detached-sigs) repository, which can be combined with the unsigned apps to create signed binaries.
+
+Create (and optionally verify) the signed macOS binary:
+
+    pushd ./gitian-builder
+    ./bin/gbuild -i --commit signature=v${VERSION} ../agrarian/contrib/gitian-descriptors/gitian-osx-signer.yml
+    ./bin/gsign --signer "$SIGNER" --release ${VERSION}-osx-signed --destination ../gitian.sigs/ ../agrarian/contrib/gitian-descriptors/gitian-osx-signer.yml
+    ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-signed ../agrarian/contrib/gitian-descriptors/gitian-osx-signer.yml
+    mv build/out/agrarian-osx-signed.dmg ../agrarian-${VERSION}-osx.dmg
+    popd
+
+Create (and optionally verify) the signed Windows binaries:
+
+    pushd ./gitian-builder
+    ./bin/gbuild -i --commit signature=v${VERSION} ../agrarian/contrib/gitian-descriptors/gitian-win-signer.yml
+    ./bin/gsign --signer "$SIGNER" --release ${VERSION}-win-signed --destination ../gitian.sigs/ ../agrarian/contrib/gitian-descriptors/gitian-win-signer.yml
+    ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-signed ../agrarian/contrib/gitian-descriptors/gitian-win-signer.yml
+    mv build/out/agrarian-*win64-setup.exe ../agrarian-${VERSION}-win64-setup.exe
+    mv build/out/agrarian-*win32-setup.exe ../agrarian-${VERSION}-win32-setup.exe
+    popd
+
+Commit your signature for the signed macOS/Windows binaries:
+
+    pushd gitian.sigs
+    git add ${VERSION}-osx-signed/"${SIGNER}"
+    git add ${VERSION}-win-signed/"${SIGNER}"
+    git commit -m "Add ${SIGNER} ${VERSION} signed binaries signatures"
+    git push  # Assuming you can push to the gitian.sigs tree
+    popd
+
+### After 3 or more people have gitian-built and their results match:
+
+- Create `SHA256SUMS.asc` for the builds, and GPG-sign it:
+
+```bash
+sha256sum * > SHA256SUMS
+```
+
+The list of files should be:
+```
+agrarian-${VERSION}-aarch64-linux-gnu.tar.gz
+agrarian-${VERSION}-arm-linux-gnueabihf.tar.gz
+agrarian-${VERSION}-i686-pc-linux-gnu.tar.gz
+agrarian-${VERSION}-riscv64-linux-gnu.tar.gz
+agrarian-${VERSION}-x86_64-linux-gnu.tar.gz
+agrarian-${VERSION}-osx64.tar.gz
+agrarian-${VERSION}-osx.dmg
+agrarian-${VERSION}.tar.gz
+agrarian-${VERSION}-win32-setup.exe
+agrarian-${VERSION}-win32.zip
+agrarian-${VERSION}-win64-setup.exe
+agrarian-${VERSION}-win64.zip
+```
+The `*-debug*` files generated by the gitian build contain debug symbols
+for troubleshooting by developers. It is assumed that anyone that is interested
+in debugging can run gitian to generate the files for themselves. To avoid
+end-user confusion about which file to pick, as well as save storage
+space *do not upload these to github*.
+
+- GPG-sign it, delete the unsigned file:
+```
+gpg --digest-algo sha256 --clearsign SHA256SUMS # outputs SHA256SUMS.asc
+rm SHA256SUMS
+```
+(the digest algorithm is forced to sha256 to avoid confusion of the `Hash:` header that GPG adds with the SHA256 used for the files)
+Note: check that SHA256SUMS itself doesn't end up in SHA256SUMS, which is a spurious/nonsensical entry.
+
+- Upload zips and installers, as well as `SHA256SUMS.asc` from last step, to the GitHub release (see below)
+
+- Announce the release:
+
+  - bitcointalk announcement thread
+
+  - Optionally twitter, reddit /r/agrarian, ... but this will usually sort out itself
+
+  - Archive release notes for the new version to `doc/release-notes/` (branch `master` and branch of the release)
+
+  - Create a [new GitHub release](https://github.com/Agrarian-Project/Agrarian/releases/new) with a link to the archived release notes.
+
+  - Celebrate
@@ -0,0 +1,132 @@
+# TOR SUPPORT IN Agrarian
+
+It is possible to run Agrarian Core as a Tor hidden service, and connect to such services.
+
+The following directions assume you have a Tor proxy running on port 9050. Many distributions default to having a SOCKS proxy listening on port 9050, but others may not. In particular, the Tor Browser Bundle defaults to listening on port 9150. See [Tor Project FAQ:TBBSocksPort](https://www.torproject.org/docs/faq.html.en#TBBSocksPort) for how to properly
+configure Tor.
+
+
+## 1. Run Agrarian Core behind a Tor proxy
+----------------------------------
+
+The first step is running Agrarian behind a Tor proxy. This will already anonymize all
+outgoing connections, but more is possible.
+
+	-proxy=ip:port  Set the proxy server. If SOCKS5 is selected (default), this proxy
+	                server will be used to try to reach .onion addresses as well.
+
+	-onion=ip:port  Set the proxy server to use for Tor hidden services. You do not
+	                need to set this if it's the same as -proxy. You can use -noonion
+	                to explicitly disable access to hidden services.
+
+	-listen         When using -proxy, listening is disabled by default. If you want
+	                to run a hidden service (see next section), you'll need to enable
+	                it explicitly.
+
+	-connect=X      When behind a Tor proxy, you can specify .onion addresses instead
+	-addnode=X      of IP addresses or hostnames in these parameters. It requires
+	-seednode=X     SOCKS5. In Tor mode, such addresses can also be exchanged with
+	                other P2P nodes.
+
+	-onlynet=onion  Make outgoing connections only to .onion addresses. Incoming
+	                connections are not affected by this option. This option can be
+	                specified multiple times to allow multiple network types, e.g.
+	                ipv4, ipv6, or onion.
+
+In a typical situation, this suffices to run behind a Tor proxy:
+
+	./agrariand -proxy=127.0.0.1:9050
+
+
+## 2. Run a Agrarian Core hidden server
+
+If you configure your Tor system accordingly, it is possible to make your node also
+reachable from the Tor network. Add these lines to your /etc/tor/torrc (or equivalent
+config file): *Needed for Tor version 0.2.7.0 and older versions of Tor only. For newer
+versions of Tor see [Section 3](#3-automatically-listen-on-tor).*
+
+	HiddenServiceDir /var/lib/tor/agrarian-service/
+	HiddenServicePort 51336 127.0.0.1:51336
+	HiddenServicePort 61472 127.0.0.1:61472
+
+The directory can be different of course, but (both) port numbers should be equal to
+your agrariand's P2P listen port (51336 by default).
+
+	-externalip=X   You can tell agrarian about its publicly reachable address using
+	                this option, and this can be a .onion address. Given the above
+	                configuration, you can find your .onion address in
+	                /var/lib/tor/agrarian-service/hostname. For connections
+	                coming from unroutable addresses (such as 127.0.0.1, where the
+	                Tor proxy typically runs), .onion addresses are given
+	                preference for your node to advertise itself with.
+
+	-listen         You'll need to enable listening for incoming connections, as this
+	                is off by default behind a proxy.
+
+	-discover       When -externalip is specified, no attempt is made to discover local
+	                IPv4 or IPv6 addresses. If you want to run a dual stack, reachable
+	                from both Tor and IPv4 (or IPv6), you'll need to either pass your
+	                other addresses using -externalip, or explicitly enable -discover.
+	                Note that both addresses of a dual-stack system may be easily
+	                linkable using traffic analysis.
+
+In a typical situation, where you're only reachable via Tor, this should suffice:
+
+	./agrariand -proxy=127.0.0.1:9050 -externalip=agrarianzj6l4cvo2fxy.onion -listen
+
+(obviously, replace the .onion address with your own). It should be noted that you still
+listen on all devices and another node could establish a clearnet connection, when knowing
+your address. To mitigate this, additionally bind the address of your Tor proxy:
+
+	./agrariand ... -bind=127.0.0.1
+
+If you don't care too much about hiding your node, and want to be reachable on IPv4
+as well, use `discover` instead:
+
+	./agrariand ... -discover
+
+and open port 51336 on your firewall (or use -upnp).
+
+If you only want to use Tor to reach .onion addresses, but not use it as a proxy
+for normal IPv4/IPv6 communication, use:
+
+	./agrariand -onion=127.0.0.1:9050 -externalip=agrarianzj6l4cvo2fxy.onion -discover
+
+## 3. Automatically listen on Tor
+
+Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket
+API, to create and destroy 'ephemeral' hidden services programmatically.
+Agrarian Core has been updated to make use of this.
+
+This means that if Tor is running (and proper authentication has been configured),
+Agrarian Core automatically creates a hidden service to listen on. This will positively
+affect the number of available .onion nodes.
+
+This new feature is enabled by default if Agrarian Core is listening (`-listen`), and
+requires a Tor connection to work. It can be explicitly disabled with `-listenonion=0`
+and, if not disabled, configured using the `-torcontrol` and `-torpassword` settings.
+To show verbose debugging information, pass `-debug=tor`.
+
+Connecting to Tor's control socket API requires one of two authentication methods to be
+configured. It also requires the control socket to be enabled, e.g. put `ControlPort 9051`
+in `torrc` config file. For cookie authentication the user running agrariand must have read
+access to the `CookieAuthFile` specified in Tor configuration. In some cases this is
+preconfigured and the creation of a hidden service is automatic. If permission problems
+are seen with `-debug=tor` they can be resolved by adding both the user running Tor and
+the user running agrariand to the same group and setting permissions appropriately. On
+Debian-based systems the user running agrariand can be added to the debian-tor group,
+which has the appropriate permissions.
+
+An alternative authentication method is the use
+of the `-torpassword=password` option. The `password` is the clear text form that
+was used when generating the hashed password for the `HashedControlPassword` option
+in the tor configuration file. The hashed password can be obtained with the command
+`tor --hash-password password` (read the tor manual for more details).
+
+## 4. Privacy recommendations
+
+- Do not add anything but Agrarian Core ports to the hidden service created in section 2.
+  If you run a web service too, create a new hidden service for that.
+  Otherwise it is trivial to link them, which may reduce privacy. Hidden
+  services created automatically (as in section 3) always have only one port
+  open.
@@ -0,0 +1,109 @@
+Translations
+============
+
+The Agrarian Core project has been designed to support multiple localisations. This makes adding new phrases, and completely new languages easily achievable. For managing all application translations, Agrarian Core makes use of the Transifex online translation management tool.
+
+### Helping to translate (using Transifex)
+Transifex is setup to monitor the GitHub repo for updates, and when code containing new translations is found, Transifex will process any changes. It may take several hours after a pull-request has been merged, to appear in the Transifex web interface.
+
+Multiple language support is critical in assisting Agrarian's global adoption, and growth. One of Agrarian's greatest strengths is cross-border money transfers, any help making that easier is greatly appreciated.
+
+See the [Transifex Agrarian project](https://www.transifex.com/agrarian-project/agrarian-project-translations/) to assist in translations.
+
+### Writing code with translations
+We use automated scripts to help extract translations in both Qt, and non-Qt source files. It is rarely necessary to manually edit the files in `src/qt/locale/`. The translation source files must adhere to the following format:
+`agrarian_xx_YY.ts or agrarian_xx.ts`
+
+`src/qt/locale/agrarian_en.ts` is treated in a special way. It is used as the source for all other translations. Whenever a string in the source code is changed, this file must be updated to reflect those changes. A custom script is used to extract strings from the non-Qt parts. This script makes use of `gettext`, so make sure that utility is installed (ie, `apt-get install gettext` on Ubuntu/Debian). Once this has been updated, `lupdate` (included in the Qt SDK) is used to update `agrarian_en.ts`.
+
+To automatically regenerate the `agrarian_en.ts` file, run the following commands:
+```sh
+cd src/
+make translate
+```
+
+`contrib/agrarian-qt.pro` takes care of generating `.qm` (binary compiled) files from `.ts` (source files) files. It’s mostly automated, and you shouldn’t need to worry about it.
+
+**Example Qt translation**
+```cpp
+QToolBar *toolbar = addToolBar(tr("Tabs toolbar"));
+```
+
+### Creating a pull-request
+For general PRs, you shouldn’t include any updates to the translation source files. They will be updated periodically, primarily around pre-releases, allowing time for any new phrases to be translated before public releases. This is also important in avoiding translation related merge conflicts.
+
+When an updated source file is merged into the GitHub repo, Transifex will automatically detect it (although it can take several hours). Once processed, the new strings will show up as "Remaining" in the Transifex web interface and are ready for translators.
+
+To create the pull-request, use the following commands:
+```
+git add src/qt/agrarianstrings.cpp src/qt/locale/agrarian_en.ts
+git commit
+```
+
+### Creating a Transifex account
+Visit the [Transifex Signup](https://www.transifex.com/signup/) page to create an account. Take note of your username and password, as they will be required to configure the command-line tool.
+
+You can find the Agrarian translation project at [https://www.transifex.com/agrarian-project/agrarian-project-translations/](https://www.transifex.com/agrarian-project/agrarian-project-translations/).
+
+### Installing the Transifex client command-line tool
+The client is used to fetch updated translations. If you are having problems, or need more details, see [https://docs.transifex.com/client/installing-the-client](https://docs.transifex.com/client/installing-the-client)
+
+`pip install transifex-client`
+
+Setup your Transifex client config as follows. Please *ignore the token field*.
+
+```ini
+nano ~/.transifexrc
+
+[https://www.transifex.com]
+hostname = https://www.transifex.com
+password = PASSWORD
+token =
+username = USERNAME
+```
+
+The Transifex Agrarian project config file is included as part of the repo. It can be found at `.tx/config`, however you shouldn’t need to change anything.
+
+### Synchronising translations
+To assist in updating translations, we have created a script to help.
+
+1. `python contrib/devtools/update-translations.py`
+2. `git add` new translations from `src/qt/locale/`
+3. Update `src/qt/agrarian_locale.qrc` manually or via
+```bash
+git ls-files src/qt/locale/*ts|xargs -n1 basename|sed 's/\(agrarian_\(.*\)\).ts/<file alias="\2">locale\/\1.qm<\/file>/'
+```
+4. Update `src/Makefile.qt.include` manually or via
+```bash
+git ls-files src/qt/locale/*ts|xargs -n1 basename|sed 's/\(agrarian_\(.*\)\).ts/  qt\/locale\/\1.ts \\/'
+```
+
+**Do not directly download translations** one by one from the Transifex website, as we do a few post-processing steps before committing the translations.
+
+### Handling Plurals (in source files)
+When new plurals are added to the source file, it's important to do the following steps:
+
+1. Open `agrarian_en.ts` in Qt Linguist (included in the Qt SDK)
+2. Search for `%n`, which will take you to the parts in the translation that use plurals
+3. Look for empty `English Translation (Singular)` and `English Translation (Plural)` fields
+4. Add the appropriate strings for the singular and plural form of the base string
+5. Mark the item as done (via the green arrow symbol in the toolbar)
+6. Repeat from step 2, until all singular and plural forms are in the source file
+7. Save the source file
+
+### Translating a new language
+To create a new language template, you will need to edit the languages manifest file `src/qt/agrarian_locale.qrc` and add a new entry. Below is an example of the English language entry.
+
+```xml
+<qresource prefix="/translations">
+    <file alias="en">locale/agrarian_en.qm</file>
+    ...
+</qresource>
+```
+
+**Note:** that the language translation file **must end in `.qm`** (the compiled extension), and not `.ts`.
+
+### Questions and general assistance
+The Agrarian Core translation maintainers include *Fuzzbawls*. You can find them, and others, in the [Agrarian Discord](https://discord.agrarian.org).
+
+Announcements will be posted during application pre-releases to notify translators to check for updates.
@@ -0,0 +1,99 @@
+Translation Strings Policy
+===========================
+
+This document provides guidelines for internationalization of the Agrarian Core software.
+
+How to translate?
+------------------
+
+To mark a message as translatable
+
+- In GUI source code (under `src/qt`): use `tr("...")`
+
+- In non-GUI source code (under `src`): use `_("...")`
+
+No internationalization is used for e.g. developer scripts outside `src`.
+
+Strings to be translated
+-------------------------
+
+On a high level, these strings are to be translated:
+
+- GUI strings, anything that appears in a dialog or window
+
+### GUI strings
+
+Anything that appears to the user in the GUI is to be translated. This includes labels, menu items, button texts, tooltips and window titles.
+This includes messages passed to the GUI through the UI interface through `InitMessage`, `ThreadSafeMessageBox` or `ShowProgress`.
+
+General recommendations
+------------------------
+
+### Avoid unnecessary translation strings
+
+Try not to burden translators with translating messages that are e.g. slight variations of other messages.
+In the GUI, avoid the use of text where an icon or symbol will do.
+Make sure that placeholder texts in forms do not end up in the list of strings to be translated (use `<string notr="true">`).
+
+### Make translated strings understandable
+
+Try to write translation strings in an understandable way, for both the user and the translator. Avoid overly technical or detailed messages.
+
+### Do not translate internal errors
+
+Do not translate internal errors, log messages, or messages that appear on the RPC interface. If an error is to be shown to the user,
+use a translatable generic message, then log the detailed message to the log. E.g., "A fatal internal error occurred, see debug.log for details".
+This helps troubleshooting; if the error is the same for everyone, the likelihood is increased that it can be found using a search engine.
+
+### Avoid fragments
+
+Avoid dividing up a message into fragments. Translators see every string separately, so they may misunderstand the context if the messages are not self-contained.
+
+### Avoid HTML in translation strings
+
+There have been difficulties with the use of HTML in translation strings; translators should not be able to accidentally affect the formatting of messages.
+This may sometimes be at conflict with the recommendation in the previous section.
+
+### Plurals
+
+Plurals can be complex in some languages. A quote from the gettext documentation:
+
+    In Polish we use e.g. plik (file) this way:
+    1 plik,
+    2,3,4 pliki,
+    5-21 pliko'w,
+    22-24 pliki,
+    25-31 pliko'w
+    and so on
+
+In Qt code, use tr's third argument for optional plurality. For example:
+
+    tr("%n hour(s)","",secs/HOUR_IN_SECONDS);
+    tr("%n day(s)","",secs/DAY_IN_SECONDS);
+    tr("%n week(s)","",secs/WEEK_IN_SECONDS);
+
+This adds `<numerusform>`s to the respective `.ts` file, which can be translated separately depending on the language. In English, this is simply:
+
+    <message numerus="yes">
+        <source>%n active connection(s) to Agrarian network</source>
+        <translation>
+            <numerusform>%n active connection to Agrarian network</numerusform>
+            <numerusform>%n active connections to Agrarian network</numerusform>
+        </translation>
+    </message>
+
+Where possible, try to avoid embedding numbers into the flow of the string at all. E.g.,
+
+    WARNING: check your network connection, %d blocks received in the last %d hours (%d expected)
+
+versus
+
+    WARNING: check your network connection, less blocks (%d) were received in the last %n hours than expected (%d).
+
+The second example reduces the number of pluralized words that translators have to handle from three to one, at no cost to comprehensibility of the sentence.
+
+### String freezes
+
+During a string freeze (often before a major release), no translation strings are to be added, modified or removed.
+
+This can be checked by executing `make translate` in the `src` directory, then verifying that `agrarian_en.ts` remains unchanged.
@@ -0,0 +1,42 @@
+Travis CI
+=========
+
+Support for using travis-ci has been added in order to automate pull-testing.
+See [travis-ci.org](https://travis-ci.org/) for more info
+
+This procedure is different than the pull-tester that came before it in a few
+ways.
+
+There is nothing to administer. This is a major feature as it means
+that builds have no local state. Because there is no ability to login to the
+builders to install packages (tools, dependencies, etc), the entire build
+procedure must instead be controlled by a declarative script `.travis.yml`.
+This script declares each build configuration, creates virtual machines as
+necessary, builds, then discards the virtual machines.
+
+A build matrix is constructed to test a wide range of configurations, rather
+than a single pass/fail. This helps to catch build failures and logic errors
+that present on platforms other than the ones the author has tested. This
+matrix is defined in the build script and can be changed at any time.
+
+All builders use the dependency-generator in the [depends dir](/depends), rather than
+using apt-get to install build dependencies. This guarantees that the tester
+is using the same versions as Gitian, so the build results are nearly identical
+to what would be found in a final release. However, this also means that builds
+will fail if new dependencies are introduced without being added to the
+dependency generator.
+
+In order to avoid rebuilding all dependencies for each build, the binaries are
+cached and re-used when possible. Changes in the dependency-generator will
+trigger cache-invalidation and rebuilds as necessary.
+
+These caches can be manually removed if necessary. This is one of the very few
+manual operations that is possible with Travis, and it can be done by the
+Bitcoin Core committer via the Travis web interface.
+
+In some cases, secure strings may be needed for hiding sensitive info such as
+private keys or URLs. The travis client may be used to create these strings:
+http://docs.travis-ci.com/user/encryption-keys/
+
+For the details of the build descriptor, see the official docs:
+http://docs.travis-ci.com/user/build-configuration/
@@ -0,0 +1,110 @@
+# Block and Transaction Broadcasting with ZeroMQ
+
+[ZeroMQ](http://zeromq.org/) is a lightweight wrapper around TCP
+connections, inter-process communication, and shared-memory,
+providing various message-oriented semantics such as publish/subscribe,
+request/reply, and push/pull.
+
+The Agrarian Core daemon can be configured to act as a trusted "border
+router", implementing the agrarian wire protocol and relay, making
+consensus decisions, maintaining the local blockchain database,
+broadcasting locally generated transactions into the network, and
+providing a queryable RPC interface to interact on a polled basis for
+requesting blockchain related data. However, there exists only a
+limited service to notify external software of events like the arrival
+of new blocks or transactions.
+
+The ZeroMQ facility implements a notification interface through a set
+of specific notifiers. Currently there are notifiers that publish
+blocks and transactions. This read-only facility requires only the
+connection of a corresponding ZeroMQ subscriber port in receiving
+software; it is not authenticated nor is there any two-way protocol
+involvement. Therefore, subscribers should validate the received data
+since it may be out of date, incomplete or even invalid.
+
+ZeroMQ sockets are self-connecting and self-healing; that is,
+connections made between two endpoints will be automatically restored
+after an outage, and either end may be freely started or stopped in
+any order.
+
+Because ZeroMQ is message oriented, subscribers receive transactions
+and blocks all-at-once and do not need to implement any sort of
+buffering or reassembly.
+
+## Prerequisites
+
+The ZeroMQ feature in Agrarian Core requires the ZeroMQ API >= 4.0.0
+[libzmq](https://github.com/zeromq/libzmq/releases).
+For version information, see [dependencies.md](dependencies.md).
+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 *python3-zmq*, though this is not necessary for daemon
+operation.
+
+## Enabling
+
+By default, the ZeroMQ feature is automatically compiled in if the
+necessary prerequisites are found.  To disable, use --disable-zmq
+during the *configure* step of building agrariand:
+
+    $ ./configure --disable-zmq (other options)
+
+To actually enable operation, one must set the appropriate options on
+the command line or in the configuration file.
+
+## Usage
+
+Currently, the following notifications are supported:
+
+    -zmqpubhashtx=address
+    -zmqpubhashtxlock=address
+    -zmqpubhashblock=address
+    -zmqpubrawblock=address
+    -zmqpubrawtx=address
+    -zmqpubrawtxlock=address
+
+The socket type is PUB and the address must be a valid ZeroMQ socket
+address. The same address can be used in more than one notification.
+
+For instance:
+
+    $ agrariand -zmqpubhashtx=tcp://127.0.0.1:28332 \
+               -zmqpubrawtx=ipc:///tmp/agrariand.tx.raw
+
+Each PUB notification has a topic and body, where the header
+corresponds to the notification type. For instance, for the
+notification `-zmqpubhashtx` the topic is `hashtx` (no null
+terminator) and the body is the hexadecimal transaction hash (32
+bytes).
+
+These options can also be provided in agrarian.conf.
+
+ZeroMQ endpoint specifiers for TCP (and others) are documented in the
+[ZeroMQ API](http://api.zeromq.org/4-0:_start).
+
+Client side, then, the ZeroMQ subscriber socket must have the
+ZMQ_SUBSCRIBE option set to one or either of these prefixes (for
+instance, just `hash`); without doing so will result in no messages
+arriving. Please see `contrib/zmq/zmq_sub.py` for a working example.
+
+## Remarks
+
+From the perspective of agrariand, the ZeroMQ socket is write-only; PUB
+sockets don't even have a read function. Thus, there is no state
+introduced into agrariand directly. Furthermore, no information is
+broadcast that wasn't already received from the public P2P network.
+
+No authentication or authorization is done on connecting clients; it
+is assumed that the ZeroMQ port is exposed only to trusted entities,
+using other means such as firewalling.
+
+Note that when the block chain tip changes, a reorganisation may occur
+and just the tip will be notified. It is up to the subscriber to
+retrieve the chain from the last known block to the new tip.
+
+There are several possibilities that ZMQ notification can get lost
+during transmission depending on the communication type you are
+using. agrariand appends an up-counting sequence number to each
+notification which allows listeners to detect lost notifications.