Merge branch 'master' into 20150703_banlist_updates

author: Luke Dashjr <[email protected]> 2016-01-15 05:17:15 +0000
committer: Luke Dashjr <[email protected]> 2016-01-15 05:17:15 +0000
commit: 5bc4fb7b602c420be1c746442edad6b2d8e333ab (patch)
tree: 32ce1458f7fafdf4f9a1dcb09091f1a6de416625 /doc
parent: banlist (bugfix): allow CNode::SweepBanned() to run on interval (diff)
parent: Merge pull request #7327 (diff)
download: discoin-5bc4fb7b602c420be1c746442edad6b2d8e333ab.tar.xz
discoin-5bc4fb7b602c420be1c746442edad6b2d8e333ab.zip
26 files changed, 855 insertions, 325 deletions
diff --git a/doc/Doxyfile b/doc/Doxyfile
index 925a33ee8..428fba98e 100644
--- a/doc/Doxyfile
+++ b/doc/Doxyfile
@@ -34,7 +34,7 @@ PROJECT_NAME           = Bitcoin
 # This could be handy for archiving the generated documentation or 
 # if some version control system is used.
 
-PROJECT_NUMBER         = 0.11.99
+PROJECT_NUMBER         = 0.12.99
 
 # Using the PROJECT_BRIEF tag one can provide an optional one line description 
 # for a project that appears at the top of each page and should give viewer 
diff --git a/doc/README.md b/doc/README.md
index 3e3f4a294..c0f9ee522 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -1,4 +1,4 @@
-Bitcoin Core 0.11.99
+Bitcoin Core 0.12.99
 =====================
 
 Setup
@@ -7,7 +7,7 @@ Setup
 
 Running
 ---------------------
-The following are some helpful notes on how to run Bitcoin on your native platform. 
+The following are some helpful notes on how to run Bitcoin on your native platform.
 
 ### Unix
 
@@ -26,9 +26,9 @@ Unpack the files into a directory and run:
 
 Unpack the files into a directory, and then run bitcoin-qt.exe.
 
-### OSX
+### OS X
 
-Drag Bitcoin-Qt to your applications folder, and then run Bitcoin-Qt.
+Drag Bitcoin-Core to your applications folder, and then run Bitcoin-Core.
 
 ### Need Help?
 
@@ -41,8 +41,10 @@ Building
 ---------------------
 The following are developer notes on how to build Bitcoin on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.
 
-- [OSX Build Notes](build-osx.md)
+- [OS X Build Notes](build-osx.md)
 - [Unix Build Notes](build-unix.md)
+- [Windows Build Notes](build-windows.md)
+- [OpenBSD Build Notes](build-openbsd.md)
 - [Gitian Building Guide](gitian-building.md)
 
 Development
diff --git a/doc/README_osx.txt b/doc/README_osx.txt
index a572c7a24..f589bfc67 100644
--- a/doc/README_osx.txt
+++ b/doc/README_osx.txt
@@ -1,12 +1,12 @@
-Deterministic OSX Dmg Notes.
+Deterministic OS X Dmg Notes.
 
-Working OSX DMGs are created in Linux by combining a recent clang,
+Working OS X DMGs are created in Linux by combining a recent clang,
 the Apple's 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 OSX. A pre-compiled version of 3.2 is used because it was not
+when building for OS X. A pre-compiled version of 3.2 is used because it was not
 available in the Precise repositories at the time this work was started. In the
 future, it can be switched to use system packages instead.
 
@@ -29,18 +29,18 @@ 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 6.1.1 dmg:
+To obtain it, register for a developer account, then download the Xcode 6.1.1 dmg:
 https://developer.apple.com/devcenter/download.action?path=/Developer_Tools/xcode_6.1.1/xcode_6.1.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.9.sdk
 
 Unfortunately, the usual linux tools (7zip, hpmount, loopback mount) are incapable of opening this file.
-To create a tarball suitable for gitian input, mount the dmg in OSX, then create it with:
+To create a tarball suitable for Gitian input, mount the dmg in OS X, then create it with:
   $ tar -C /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -czf MacOSX10.9.sdk.tar.gz MacOSX10.9.sdk
 
 
-The gitian descriptors build 2 sets of files: Linux tools, then Apple binaries
+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.
@@ -64,20 +64,20 @@ Ideally, the creation could be fixed and genisoimage would no longer be necessar
 
 Background images and other features can be added to DMG files by inserting a
 .DS_Store before creation. The easiest way to create this file is to build a
-DMG without one, move it to a device running OSX, customize the layout, then
+DMG without one, move it to a device running OS X, customize the layout, then
 grab the .DS_Store file for later use. That is the approach taken here.
 
-As of OSX Mavericks (10.9), using an Apple-blessed key to sign binaries is a
+As of OS X Mavericks (10.9), 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
+- 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.
-- Builders feed the unsigned app + detached signature back into gitian. It
+- Builders feed the unsigned app + detached signature back into Gitian. It
   uses the pre-built tools to recombine the pieces into a deterministic dmg.
diff --git a/doc/README_windows.txt b/doc/README_windows.txt
index e4fd9bdf9..2d1c4503c 100644
--- a/doc/README_windows.txt
+++ b/doc/README_windows.txt
@@ -1,4 +1,4 @@
-Bitcoin Core 0.11.99
+Bitcoin Core 0.12.99
 =====================
 
 Intro
diff --git a/doc/bips.md b/doc/bips.md
index c84bd966f..e73add013 100644
--- a/doc/bips.md
+++ b/doc/bips.md
@@ -14,6 +14,9 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.12.0**):
 * [`BIP 37`](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki): The bloom filtering for transaction relaying, partial merkle trees for blocks, and the protocol version bump to 70001 (enabling low-bandwidth SPV clients) has been implemented since **v0.8.0** ([PR #1795](https://github.com/bitcoin/bitcoin/pull/1795)).
 * [`BIP 42`](https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki): The bug that would have caused the subsidy schedule to resume after block 13440000 was fixed in **v0.9.2** ([PR #3842](https://github.com/bitcoin/bitcoin/pull/3842)).
 * [`BIP 61`](https://github.com/bitcoin/bips/blob/master/bip-0061.mediawiki): The 'reject' protocol message (and the protocol version bump to 70002) was added in **v0.9.0** ([PR #3185](https://github.com/bitcoin/bitcoin/pull/3185)).
+* [`BIP 65`](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki): The CHECKLOCKTIMEVERIFY softfork was merged in **v0.12.0** ([PR #6351](https://github.com/bitcoin/bitcoin/pull/6351)), and backported to **v0.11.2** and **v0.10.4**. Mempool-only CLTV was added in [PR #6124](https://github.com/bitcoin/bitcoin/pull/6124).
 * [`BIP 66`](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki): The strict DER rules and associated version 3 blocks have been implemented since **v0.10.0** ([PR #5713](https://github.com/bitcoin/bitcoin/pull/5713)).
 * [`BIP 70`](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki) [`71`](https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki) [`72`](https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki): Payment Protocol support has been available in Bitcoin Core GUI since **v0.9.0** ([PR #5216](https://github.com/bitcoin/bitcoin/pull/5216)).
 * [`BIP 111`](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki): `NODE_BLOOM` service bit added, but only enforced for peer versions `>=70011` as of **v0.12.0** ([PR #6579](https://github.com/bitcoin/bitcoin/pull/6579)).
+* [`BIP 125`](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki): Opt-in full replace-by-fee signaling honoured in mempool and mining as of **v0.12.0** ([PR 6871](https://github.com/bitcoin/bitcoin/pull/6871)).
+* [`BIP 130`](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki): direct headers announcement is negotiated with peer versions `>=70012` as of **v0.12.0** ([PR 6494](https://github.com/bitcoin/bitcoin/pull/6494)).
diff --git a/doc/build-openbsd.md b/doc/build-openbsd.md
index a26b52465..d92330146 100644
--- a/doc/build-openbsd.md
+++ b/doc/build-openbsd.md
@@ -38,7 +38,7 @@ Do not use `pkg_add boost`! The boost version installed thus is compiled using t
 
     test_bitcoin:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.17.0 : WARNING: symbol(_ZN11__gnu_debug17_S_debug_me ssagesE) size mismatch, relink your program
     ...
-    Segmentation fault (core dumped) 
+    Segmentation fault (core dumped)
 
 This makes it necessary to build boost, or at least the parts used by Bitcoin Core, manually:
 
@@ -57,7 +57,7 @@ tar -xjf boost_1_59_0.tar.bz2
 # Boost 1.59 needs two small patches for OpenBSD
 cd boost_1_59_0
 # Also here: https://gist.githubusercontent.com/laanwj/bf359281dc319b8ff2e1/raw/92250de8404b97bb99d72ab898f4a8cb35ae1ea3/patch-boost_test_impl_execution_monitor_ipp.patch
-patch -p0 < /usr/ports/devel/boost/patches/patch-boost_test_impl_execution_monitor_ipp 
+patch -p0 < /usr/ports/devel/boost/patches/patch-boost_test_impl_execution_monitor_ipp
 # https://github.com/boostorg/filesystem/commit/90517e459681790a091566dce27ca3acabf9a70c
 sed 's/__OPEN_BSD__/__OpenBSD__/g' < libs/filesystem/src/path.cpp > libs/filesystem/src/path.cpp.tmp
 mv libs/filesystem/src/path.cpp.tmp libs/filesystem/src/path.cpp
@@ -92,7 +92,7 @@ tar -xzf db-4.8.30.NC.tar.gz
 # Build the library and install to specified prefix
 cd db-4.8.30.NC/build_unix/
 #  Note: Do a static build so that it can be embedded into the executable, instead of having to find a .so at runtime
-../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX CC=egcc CXX=eg++ CPP=ecpp 
+../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX CC=egcc CXX=eg++ CPP=ecpp
 make install
 ```
 
@@ -160,4 +160,3 @@ version installed by OpenBSD 5.7:
 - https://llvm.org/bugs/show_bug.cgi?id=9758
 
 There is no known workaround for this.
-
diff --git a/doc/build-osx.md b/doc/build-osx.md
index 201fe9522..c3cb1b789 100644
--- a/doc/build-osx.md
+++ b/doc/build-osx.md
@@ -1,11 +1,11 @@
 Mac OS X Build Instructions and Notes
 ====================================
-This guide will show you how to build bitcoind (headless client) for OSX.
+This guide will show you how to build bitcoind (headless client) for OS X.
 
 Notes
 -----
 
-* Tested on OS X 10.7 through 10.10 on 64-bit Intel processors only.
+* Tested on OS X 10.7 through 10.11 on 64-bit Intel processors only.
 
 * All of the commands should be executed in a Terminal application. The
 built-in one is located in `/Applications/Utilities`.
@@ -13,8 +13,8 @@ built-in one is located in `/Applications/Utilities`.
 Preparation
 -----------
 
-You need to install XCode with all the options checked so that the compiler
-and everything is available in /usr not just /Developer. XCode should be
+You need to install Xcode with all the options checked so that the compiler
+and everything is available in /usr not just /Developer. Xcode should be
 available on your OS X installation media, but if not, you can get the
 current version from https://developer.apple.com/xcode/. If you install
 Xcode 4.3 or later, you'll need to install its command line tools. This can
@@ -24,7 +24,7 @@ be re-done or updated every time Xcode is updated.
 You will also need to install [Homebrew](http://brew.sh) in order to install library
 dependencies.
 
-The installation of the actual dependencies is covered in the Instructions
+The installation of the actual dependencies is covered in the instructions
 sections below.
 
 Instructions: Homebrew
@@ -32,21 +32,23 @@ Instructions: Homebrew
 
 #### Install dependencies using Homebrew
 
-        brew install autoconf automake berkeley-db4 libtool boost miniupnpc openssl pkg-config protobuf qt5 libevent
+    brew install autoconf automake berkeley-db4 libtool boost miniupnpc openssl pkg-config protobuf qt5 libevent
 
 NOTE: Building with Qt4 is still supported, however, could result in a broken UI. As such, building with Qt5 is recommended.
 
-### Building `bitcoind`
+### Building `bitcoin`
 
-1. Clone the github tree to get the source code and go into the directory.
+1. Clone the GitHub tree to get the source code and go into the directory.
 
         git clone https://github.com/bitcoin/bitcoin.git
         cd bitcoin
 
-2.  Build bitcoind:
+2.  Build bitcoin-core:
+    This will configure and build the headless bitcoin binaries as well as the gui (if Qt is found).
+    You can disable the gui build by passing `--without-gui` to configure.
 
         ./autogen.sh
-        ./configure --with-gui=qt5
+        ./configure
         make
 
 3.  It is also a good idea to build and run the unit tests:
@@ -60,10 +62,10 @@ NOTE: Building with Qt4 is still supported, however, could result in a broken UI
 Use Qt Creator as IDE
 ------------------------
 You can use Qt Creator as IDE, for debugging and for manipulating forms, etc.
-Download Qt Creator from http://www.qt.io/download/. Download the "community edition" and only install Qt Creator (uncheck the rest during the installation process).
+Download Qt Creator from https://www.qt.io/download/. Download the "community edition" and only install Qt Creator (uncheck the rest during the installation process).
 
-1. Make sure you installed everything through homebrew mentioned above 
-2. Do a proper ./configure --with-gui=qt5 --enable-debug
+1. Make sure you installed everything through Homebrew mentioned above
+2. Do a proper ./configure --enable-debug
 3. In Qt Creator do "New Project" -> Import Project -> Import Existing Project
 4. Enter "bitcoin-qt" as project name, enter src/qt as location
 5. Leave the file selection as it is
@@ -79,7 +81,7 @@ You can ignore this section if you are building `bitcoind` for your own use.
 
 bitcoind/bitcoin-cli binaries are not included in the Bitcoin-Qt.app bundle.
 
-If you are building `bitcoind` or `Bitcoin-Qt` for others, your build machine should be set up
+If you are building `bitcoind` or `Bitcoin Core` for others, your build machine should be set up
 as follows for maximum compatibility:
 
 All dependencies should be compiled with these flags:
@@ -88,7 +90,7 @@ All dependencies should be compiled with these flags:
  -arch x86_64
  -isysroot $(xcode-select --print-path)/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
 
-Once dependencies are compiled, see [doc/release-process.md](release-process.md) for how the Bitcoin-Qt.app
+Once dependencies are compiled, see [doc/release-process.md](release-process.md) for how the Bitcoin Core
 bundle is packaged and signed to create the .dmg disk image that is distributed.
 
 Running
diff --git a/doc/build-unix.md b/doc/build-unix.md
index a9a0028c4..31bbab7f0 100644
--- a/doc/build-unix.md
+++ b/doc/build-unix.md
@@ -1,6 +1,6 @@
 UNIX BUILD NOTES
 ====================
-Some notes on how to build Bitcoin in Unix.
+Some notes on how to build Bitcoin Core in Unix.
 
 (for OpenBSD specific instructions, see [build-openbsd.md](build-openbsd.md))
 
@@ -61,49 +61,55 @@ Dependency Build Instructions: Ubuntu & Debian
 ----------------------------------------------
 Build requirements:
 
-	sudo apt-get install build-essential libtool autotools-dev autoconf pkg-config libssl-dev libevent-dev
+    sudo apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils
 
-For Ubuntu 12.04 and later or Debian 7 and later libboost-all-dev has to be installed:
+On at least Ubuntu 14.04+ and Debian 7+ there are generic names for the
+individual boost development packages, so the following can be used to only
+install necessary parts of boost:
 
-	sudo apt-get install libboost-all-dev
+    sudo apt-get install libboost-system-dev libboost-filesystem-dev libboost-chrono-dev libboost-program-options-dev libboost-test-dev libboost-thread-dev
 
- db4.8 packages are available [here](https://launchpad.net/~bitcoin/+archive/bitcoin).
- You can add the repository using the following command:
+If that doesn't work, you can install all boost development packages with:
 
-        sudo add-apt-repository ppa:bitcoin/bitcoin
-        sudo apt-get update
+    sudo apt-get install libboost-all-dev
 
- Ubuntu 12.04 and later have packages for libdb5.1-dev and libdb5.1++-dev,
- but using these will break binary wallet compatibility, and is not recommended.
+BerkeleyDB is required for the wallet. db4.8 packages are available [here](https://launchpad.net/~bitcoin/+archive/bitcoin).
+You can add the repository and install using the following commands:
 
-For other Debian & Ubuntu (with ppa):
+    sudo add-apt-repository ppa:bitcoin/bitcoin
+    sudo apt-get update
+    sudo apt-get install libdb4.8-dev libdb4.8++-dev
 
-	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, which 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.
+
+See the section "Disable-wallet mode" to build Bitcoin Core without wallet.
 
 Optional:
 
-	sudo apt-get install libminiupnpc-dev (see --with-miniupnpc and --enable-upnp-default)
+    sudo apt-get install libminiupnpc-dev (see --with-miniupnpc and --enable-upnp-default)
 
 ZMQ dependencies:
 
-        sudo apt-get install libzmq3-dev (provides ZMQ API 4.x)
-
+    sudo apt-get install libzmq3-dev (provides ZMQ API 4.x)
 
 Dependencies for the GUI: Ubuntu & Debian
 -----------------------------------------
 
 If you want to build Bitcoin-Qt, make sure that the required packages for Qt development
-are installed. Either Qt 4 or Qt 5 are necessary to build the GUI.
-If both Qt 4 and Qt 5 are installed, Qt 4 will be used. Pass `--with-gui=qt5` to configure to choose Qt5.
+are installed. Either Qt 5 or Qt 4 are necessary to build the GUI.
+If both Qt 4 and Qt 5 are installed, Qt 5 will be used. Pass `--with-gui=qt4` to configure to choose Qt4.
 To build without GUI pass `--without-gui`.
 
-To build with Qt 4 you need the following:
+To build with Qt 5 (recommended) you need the following:
 
-    sudo apt-get install libqt4-dev libprotobuf-dev protobuf-compiler
+    sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler
 
-For Qt 5 you need the following:
+Alternatively, to build with Qt 4 you need the following:
 
-    sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler
+    sudo apt-get install libqt4-dev libprotobuf-dev protobuf-compiler
 
 libqrencode (optional) can be installed with:
 
@@ -129,14 +135,6 @@ turned off by default.  See the configure options for upnp behavior desired:
 	--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
 -----------
@@ -207,6 +205,7 @@ Hardening enables the following features:
     	scanelf -e ./bitcoin
 
     The output should contain:
+
      TYPE
     ET_DYN
 
diff --git a/doc/build-windows.md b/doc/build-windows.md
new file mode 100644
index 000000000..2b9233d1e
--- /dev/null
+++ b/doc/build-windows.md
@@ -0,0 +1,40 @@
+WINDOWS BUILD NOTES
+====================
+
+Some notes on how to build Bitcoin Core for Windows.
+
+Most developers use cross-compilation from Ubuntu to build executables for
+Windows. This is also used to build the release binaries.
+
+Building on Windows itself is possible (for example using msys / mingw-w64),
+but no one documented the steps to do this. If you are doing this, please contribute them.
+
+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.
+
+First install the toolchains:
+
+    sudo apt-get install g++-mingw-w64-i686 mingw-w64-i686-dev g++-mingw-w64-x86-64 mingw-w64-x86-64-dev
+
+To build executables for Windows 32-bit:
+
+    cd depends
+    make HOST=i686-w64-mingw32 -j4
+    cd ..
+    ./configure --prefix=`pwd`/depends/i686-w64-mingw32
+    make
+
+To build executables for Windows 64-bit:
+
+    cd depends
+    make HOST=x86_64-w64-mingw32 -j4
+    cd ..
+    ./configure --prefix=`pwd`/depends/x86_64-w64-mingw32
+    make
+
+For further documentation on the depends system see [README.md](../depends/README.md) in the depends directory.
+
diff --git a/doc/developer-notes.md b/doc/developer-notes.md
index 8302a7856..358792251 100644
--- a/doc/developer-notes.md
+++ b/doc/developer-notes.md
@@ -1,5 +1,5 @@
-Coding Standards
-================
+Developer Notes
+===============
 
 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
@@ -57,7 +57,7 @@ As Doxygen recognizes the comments by the delimiters (`/**` and `*/` in this cas
 
 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()
@@ -171,3 +171,205 @@ Threads
 - BitcoinMiner : Generates bitcoins (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 Bitcoin 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 Bitcoin Core code.
+
+General Bitcoin 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 NULL. See `qa/rpc-tests/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++
+-------------
+
+- Assertions should not have side-effects
+
+  - *Rationale*: Even though the source code is set to 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
+  `scoped_pointer` 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 vector out-of-bounds exceptions. `&vch[0]` is illegal for an
+  empty vector, `&vch[vch.size()]` is always illegal. Use `begin_ptr(vch)` and
+  `end_ptr(vch)` to get the begin and end pointer instead (defined in
+  `serialize.h`)
+
+- Vector bounds checking is only enabled in debug mode. Do not rely on it
+
+- Make sure that constructors initialize all fields. 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.
+
+- 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`, `ParseDouble` from `utilstrencodings.h` for number parsing
+
+  - *Rationale*: These functions do overflow checking, and avoid pesky locale issues
+
+- For `strprintf`, `LogPrint`, `LogPrintf` formatting characters don't need size specifiers
+
+  - *Rationale*: Bitcoin Core uses tinyformat, which is type safe. Leave them out to avoid confusion
+
+Threads and synchronization
+----------------------------
+
+- Build and run tests with `-DDEBUG_LOCKORDER` to verify that no potential
+  deadlocks are introduced. As of 0.12, 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);
+{
+    ...
+}
+```
+
+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
+
+- Don't import anything into the global namespace (`using namespace ...`). Use
+  fully specified types such as `std::string`.
+
+  - *Rationale*: Avoids symbol conflicts
+
+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.
diff --git a/doc/dnsseed-policy.md b/doc/dnsseed-policy.md
index 814ae3876..55a5c2825 100644
--- a/doc/dnsseed-policy.md
+++ b/doc/dnsseed-policy.md
@@ -7,7 +7,7 @@ As such, DNS seeds must be run by entities which have some minimum
 level of trust within the Bitcoin community.
 
 Other implementations of Bitcoin software may also use the same
-seeds and may be more exposed. In light of this exposure, this 
+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
diff --git a/doc/files.md b/doc/files.md
index c083bcb03..f7eca57dc 100644
--- a/doc/files.md
+++ b/doc/files.md
@@ -12,6 +12,8 @@
 * fee_estimates.dat: stores statistics used to estimate minimum transaction fees and priorities required for confirmation; since 0.10.0
 * peers.dat: peer IP address database (custom format); since 0.7.0
 * wallet.dat: personal wallet (BDB) with keys and transactions
+* .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
 
 Only used in pre-0.8.0
 ---------------------
diff --git a/doc/gitian-building.md b/doc/gitian-building.md
index 265fbd586..019e85169 100644
--- a/doc/gitian-building.md
+++ b/doc/gitian-building.md
@@ -1,7 +1,7 @@
 Gitian building
 ================
 
-*Setup instructions for a gitian build of Bitcoin using a Debian VM or physical system.*
+*Setup instructions for a Gitian build of Bitcoin using a Debian VM or physical system.*
 
 Gitian is the deterministic build process that is used to build the Bitcoin
 Core executables. It provides a way to be reasonably sure that the
@@ -13,7 +13,7 @@ Multiple developers build the source code by following a specific descriptor
 These results are compared and only if they match, the build is accepted and uploaded
 to bitcoin.org.
 
-More independent gitian builders are needed, which is why this guide exists. 
+More independent Gitian builders are needed, which is why this guide exists.
 It is preferred you follow these steps yourself instead of using someone else's
 VM image to avoid 'contaminating' the build.
 
@@ -22,9 +22,9 @@ 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 the gitian image](#setting-up-the-gitian-image)
+- [Setting up Debian for Gitian building](#setting-up-debian-for-gitian-building)
+- [Installing Gitian](#installing-gitian)
+- [Setting up the Gitian image](#setting-up-the-gitian-image)
 - [Getting and building the inputs](#getting-and-building-the-inputs)
 - [Building Bitcoin](#building-bitcoin)
 - [Building an alternative repository](#building-an-alternative-repository)
@@ -43,7 +43,7 @@ Any kind of virtualization can be used, for example:
 - [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 gitian on actual hardware instead of using virtualization.
+You can also install Gitian on actual hardware instead of using virtualization.
 
 Create a new VirtualBox VM
 ---------------------------
@@ -60,18 +60,18 @@ In the VirtualBox GUI click "Create" and choose the following parameters in the
 ![](gitian-building/create_vm_hard_disk.png)
 
 - Hard Disk: Create a virtual hard disk now
-    
+
 ![](gitian-building/create_vm_hard_disk_file_type.png)
 
-- Hard Disk file type: Use the default, VDI (VirtualBox Disk Image) 
+- Hard Disk file type: Use the default, VDI (VirtualBox Disk Image)
 
 ![](gitian-building/create_vm_storage_physical_hard_disk.png)
-    
-- Storage on physical hard disk: Dynamically Allocated 
-    
+
+- Storage on physical hard disk: Dynamically Allocated
+
 ![](gitian-building/create_vm_file_location_size.png)
 
-- File location and size: at least 40GB; as low as 20GB *may* be possible, but better to err on the safe side 
+- File location and size: at least 40GB; as low as 20GB *may* be possible, but better to err on the safe side
 - Click `Create`
 
 Get the [Debian 8.x net installer](http://cdimage.debian.org/debian-cd/8.2.0/amd64/iso-cd/debian-8.2.0-amd64-netinst.iso) (a more recent minor version should also work, see also [Debian Network installation](https://www.debian.org/CD/netinst/)).
@@ -81,7 +81,7 @@ Unixy OSes by entering the following in a terminal:
     echo "d393d17ac6b3113c81186e545c416a00f28ed6e05774284bb5e8f0df39fcbcb9  debian-8.2.0-amd64-netinst.iso" | sha256sum -c
     # (must return OK)
 
-After creating the VM, we need to configure it. 
+After creating the VM, we need to configure it.
 
 - Click the `Settings` button, then go to the `Network` tab. Adapter 1 should be attached to `NAT`.
 
@@ -115,8 +115,8 @@ This section will explain how to install Debian on the newly created VM.
 
 ![](gitian-building/debian_install_1_boot_menu.png)
 
-**Note**: Navigating in the Debian installer: 
-To keep a setting at the default and proceed, just press `Enter`. 
+**Note**: Navigating 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)
@@ -126,23 +126,23 @@ To select a different button, press `Tab`.
 ![](gitian-building/debian_install_4_configure_keyboard.png)
 
 - The VM will detect network settings using DHCP, this should all proceed automatically
-- Configure the network: 
+- Configure the network:
   - Hostname `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) 
+- 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) 
+- Name the new user `debian` (the full name doesn't matter, you can leave it empty)
 - Set the account username as `debian`
 
 ![](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) 
+- Choose a user password and enter it twice (remember it for later)
 
 ![](gitian-building/debian_install_9_user_password.png)
 
@@ -152,11 +152,11 @@ To select a different button, press `Tab`.
 ![](gitian-building/debian_install_10_configure_clock.png)
 
 - Disk setup
-  - Partitioning method: Guided - Use the entire disk 
-  
+  - Partitioning method: Guided - Use the entire disk
+
 ![](gitian-building/debian_install_11_partition_disks.png)
 
-  - Select disk to partition: SCSI1 (0,0,0) 
+  - Select disk to partition: SCSI1 (0,0,0)
 
 ![](gitian-building/debian_install_12_choose_disk.png)
 
@@ -166,7 +166,7 @@ To select a different button, press `Tab`.
 ![](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) 
+- Choose a mirror (any will do)
 
 ![](gitian-building/debian_install_16_choose_a_mirror.png)
 
@@ -201,7 +201,7 @@ After Installation
 The next step in the guide involves logging in as root via SSH.
 SSH login for root users is disabled by default, so we'll enable that now.
 
-Login to the VM using username `root` and the root password you choose earlier.
+Login to the VM using username `root` and the root password you chose earlier.
 You'll be presented with a screen similar to this.
 
 ![](gitian-building/debian_root_login.png)
@@ -243,7 +243,7 @@ For example, to connect as `root` from a Linux command prompt use
 
 Replace `root` with `debian` to log in as user.
 
-Setting up Debian for gitian building
+Setting up Debian for Gitian building
 --------------------------------------
 
 In this section we will be setting up the Debian installation for Gitian building.
@@ -260,7 +260,7 @@ Then set up LXC and the rest with the following, which is a complex jumble of se
 
 ```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
+# that the build script can execute 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
@@ -280,7 +280,7 @@ reboot
 At the end the VM is rebooted to make sure that the changes take effect. The steps in this
 section only need to be performed once.
 
-Installing gitian
+Installing Gitian
 ------------------
 
 Re-login as the user `debian` that was created during installation.
@@ -289,25 +289,25 @@ 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
+wget http://archive.ubuntu.com/ubuntu/pool/universe/v/vm-builder/vm-builder_0.12.4+bzr494.orig.tar.gz
+echo "76cbf8c52c391160b2641e7120dbade5afded713afaa6032f733a261f13e6a8e  vm-builder_0.12.4+bzr494.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
+tar -zxvf vm-builder_0.12.4+bzr494.orig.tar.gz
+cd vm-builder-0.12.4+bzr494
 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 bitcoin and gitian.
+Clone the git repositories for bitcoin and Gitian.
 
 ```bash
 git clone https://github.com/devrandom/gitian-builder.git
 git clone https://github.com/bitcoin/bitcoin
 ```
 
-Setting up the gitian image
+Setting up the Gitian image
 -------------------------
 
 Gitian needs a virtual image of the operating system to build in.
@@ -320,7 +320,7 @@ Execute the following as user `debian`:
 
 ```bash
 cd gitian-builder
-bin/make-base-vm --lxc --arch amd64 --suite precise
+bin/make-base-vm --lxc --arch amd64 --suite trusty
 ```
 
 There will be a lot of warnings printed during the build of the image. These can be ignored.
@@ -333,14 +333,14 @@ Getting and building the inputs
 Follow the instructions in [doc/release-process.md](release-process.md#fetch-and-build-inputs-first-time-or-when-dependency-versions-change)
 in the bitcoin repository under 'Fetch and build inputs' to install sources which require
 manual intervention. Also optionally follow the next step: 'Seed the Gitian sources cache
-and offline git repositories' which will fetch the remaining files required for building 
+and offline git repositories' which will fetch the remaining files required for building
 offline.
 
 Building Bitcoin
 ----------------
 
-To build Bitcoin (for Linux, OSX and Windows) just follow the steps under 'perform
-gitian builds' in [doc/release-process.md](release-process.md#perform-gitian-builds) in the bitcoin repository.
+To build Bitcoin (for Linux, OS X and Windows) just follow the steps under 'perform
+Gitian builds' in [doc/release-process.md](release-process.md#perform-gitian-builds) in the bitcoin repository.
 
 This may take some time as it will build all the dependencies needed for each descriptor.
 These dependencies will be cached after a successful build to avoid rebuilding them when possible.
@@ -380,7 +380,7 @@ 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
+the Gitian builder at an alternative repository, using the same descriptors
 and inputs.
 
 For example:
@@ -395,9 +395,9 @@ COMMIT=2014_03_windows_unicode_path
 Building fully offline
 -----------------------
 
-For building fully offline including attaching signatures to unsigned builds, the detached-sigs repository 
+For building fully offline including attaching signatures to unsigned builds, the detached-sigs repository
 and the bitcoin git repository with the desired tag must both be available locally, and then gbuild must be
-told where to find them. It also requires an apt-cacher-ng which is fully-populated but set to offline mode, or 
+told where to find them. It also requires an apt-cacher-ng which is fully-populated but set to offline mode, or
 manually disabling gitian-builder's use of apt-get to update the VM build environment.
 
 To configure apt-cacher-ng as an offline cacher, you will need to first populate its cache with the relevant
@@ -417,7 +417,7 @@ LXC_ARCH=amd64 LXC_SUITE=precise on-target -u root \
   -e DEBIAN_FRONTEND=noninteractive apt-get --no-install-recommends -y install \
   $( sed -ne '/^packages:/,/[^-] .*/ {/^- .*/{s/"//g;s/- //;p}}' ../bitcoin/contrib/gitian-descriptors/*|sort|uniq )
 LXC_ARCH=amd64 LXC_SUITE=precise on-target -u root apt-get -q -y purge grub
-LXC_ARCH=amd64 LXC_SUITE=precise on-target -u root -e DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade 
+LXC_ARCH=amd64 LXC_SUITE=precise on-target -u root -e DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade
 ```
 
 And then set offline mode for apt-cacher-ng:
@@ -431,7 +431,7 @@ Offlinemode: 1
 service apt-cacher-ng restart
 ```
 
-Then when building, override the remote URLs that gbuild would otherwise pull from the gitian descriptors::
+Then when building, override the remote URLs that gbuild would otherwise pull from the Gitian descriptors::
 ```bash
 
 cd /some/root/path/
@@ -461,7 +461,7 @@ in `gitian.sigs` to your signing machine and do
 ```
 
 This will create the `.sig` files that can be committed together with the `.assert` files to assert your
-gitian build.
+Gitian build.
 
 Uploading signatures
 ---------------------
diff --git a/doc/init.md b/doc/init.md
index ed9ce7215..e3db5b05e 100644
--- a/doc/init.md
+++ b/doc/init.md
@@ -13,8 +13,9 @@ can be found in the contrib/init folder.
 1. Service User
 ---------------------------------
 
-All three startup configurations assume the existence of a "bitcoin" user
+All three Linux startup configurations assume the existence of a "bitcoin" user
 and group.  They must be created before attempting to use these scripts.
+The OS X configuration assumes bitcoind will be set up for the current user.
 
 2. Configuration
 ---------------------------------
@@ -29,25 +30,27 @@ 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 bitcoind 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 
+If bitcoind 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. 
+controls who can access it through RPC.
 
-By default the cookie is stored in the data directory, but it's location can be overridden 
+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 bitcoind without having to do any manual configuration.
 
-`conf`, `pid`, and `wallet` accept relative paths which are interpreted as 
+`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, 
+For an example configuration file that describes the configuration settings,
 see `contrib/debian/examples/bitcoin.conf`.
 
 3. Paths
 ---------------------------------
 
+3a) Linux
+
 All three configurations assume several paths that might need to be adjusted.
 
 Binary:              `/usr/bin/bitcoind`  
@@ -62,6 +65,13 @@ reasons to make the configuration file and data directory only readable by the
 bitcoin user and group.  Access to bitcoin-cli and other bitcoind rpc clients
 can then be controlled by group membership.
 
+3b) Mac OS X
+
+Binary:              `/usr/local/bin/bitcoind`  
+Configuration file:  `~/Library/Application Support/Bitcoin/bitcoin.conf`  
+Data directory:      `~/Library/Application Support/Bitcoin`
+Lock file:           `~/Library/Application Support/Bitcoin/.lock`
+
 4. Installing Service Configuration
 -----------------------------------
 
@@ -93,13 +103,23 @@ use old versions of Upstart and do not supply the start-stop-daemon utility.
 
 Copy bitcoind.init to /etc/init.d/bitcoind. Test by running `service bitcoind start`.
 
-Using this script, you can adjust the path and flags to the bitcoind program by 
-setting the BITCOIND and FLAGS environment variables in the file 
+Using this script, you can adjust the path and flags to the bitcoind program by
+setting the BITCOIND and FLAGS environment variables in the file
 /etc/sysconfig/bitcoind. You can also use the DAEMONOPTS environment variable here.
 
+4e) Mac OS X
+
+Copy org.bitcoin.bitcoind.plist into ~/Library/LaunchAgents. Load the launch agent by
+running `launchctl load ~/Library/LaunchAgents/org.bitcoin.bitcoind.plist`.
+
+This Launch Agent will cause bitcoind to start whenever the user logs in.
+
+NOTE: This approach is intended for those wanting to run bitcoind as the current user.
+You will need to modify org.bitcoin.bitcoind.plist if you intend to use it as a
+Launch Daemon with a dedicated bitcoin user.
+
 5. Auto-respawn
 -----------------------------------
 
 Auto respawning is currently only configured for Upstart and systemd.
 Reasonable defaults have been chosen but YMMV.
-
diff --git a/doc/reduce-traffic.md b/doc/reduce-traffic.md
new file mode 100644
index 000000000..2d86588eb
--- /dev/null
+++ b/doc/reduce-traffic.md
@@ -0,0 +1,38 @@
+Reduce Traffic
+==============
+
+Some node operators need to deal with bandwidth caps imposed by their ISPs.
+
+By default, bitcoin-core allows up to 125 connections to different peers, 8 of
+which are outbound. You can therefore, have at most 117 inbound connections.
+
+The default settings can result in relatively significant traffic consumption.
+
+Ways to reduce traffic:
+
+## 1. Use `-maxuploadtarget=<MiB per day>`
+
+A major component of the traffic is caused by serving historic blocks to other nodes
+during the initial blocks download phase (syncing up a new node).
+This option can be specified in MiB per day and is turned off by default.
+This is *not* a hard limit; only a threshold to minimize the outbound
+traffic. When the limit is about to be reached, the uploaded data is cut by no
+longer serving historic blocks (blocks older than one week).
+Keep in mind that new nodes require other nodes that are willing to serve
+historic blocks. **The recommended minimum is 144 blocks per day (max. 144MB
+per day)**
+
+Whitelisted peers will never be disconnected, although their traffic counts for
+calculating the target.
+
+## 2. Disable "listening" (`-listen=0`)
+
+Disabling listening will result in fewer nodes connected (remember the maximum of 8
+outbound peers). Fewer nodes will result in less traffic usage as you are relaying
+blocks and transactions to fewer nodes.
+
+## 3. Reduce maximum connections (`-maxconnections=<num>`)
+
+Reducing the maximum connected nodes to a minimum could be desirable if traffic
+limits are tiny. Keep in mind that bitcoin's trustless model works best if you are
+connected to a handful of nodes.
diff --git a/doc/release-notes.md b/doc/release-notes.md
index 70623a393..801b684e6 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -4,117 +4,11 @@ release-notes at release time)
 Notable changes
 ===============
 
-SSL support for RPC dropped
-----------------------------
+Example item
+----------------
 
-SSL support for RPC, previously enabled by the option `rpcssl` has been dropped
-from both the client and the server. This was done in preparation for removing
-the dependency on OpenSSL for the daemon completely.
 
-Trying to use `rpcssl` will result in an error:
-
-    Error: SSL mode for RPC (-rpcssl) is no longer supported.
-
-If you are one of the few people that relies on this feature, a flexible
-migration path is to use `stunnel`. This is an utility that can tunnel
-arbitrary TCP connections inside SSL. On e.g. Ubuntu it can be installed with:
-
-    sudo apt-get install stunnel4
-
-Then, to tunnel a SSL connection on 28332 to a RPC server bound on localhost on port 18332 do:
-
-    stunnel -d 28332 -r 127.0.0.1:18332 -p stunnel.pem -P ''
-
-It can also be set up system-wide in inetd style.
-
-Another way to re-attain SSL would be to setup a httpd reverse proxy. This solution
-would allow the use of different authentication, loadbalancing, on-the-fly compression and
-caching. A sample config for apache2 could look like:
-
-    Listen 443
-
-    NameVirtualHost *:443
-    <VirtualHost *:443>
-
-    SSLEngine On
-    SSLCertificateFile /etc/apache2/ssl/server.crt
-    SSLCertificateKeyFile /etc/apache2/ssl/server.key
-
-    <Location /bitcoinrpc>
-        ProxyPass http://127.0.0.1:8332/
-        ProxyPassReverse http://127.0.0.1:8332/
-        # optional enable digest auth
-        # AuthType Digest
-        # ...
-
-        # optional bypass bitcoind rpc basic auth
-        # RequestHeader set Authorization "Basic <hash>"
-        # get the <hash> from the shell with: base64 <<< bitcoinrpc:<password>
-    </Location>
-
-    # Or, balance the load:
-    # ProxyPass / balancer://balancer_cluster_name
-
-    </VirtualHost>
-
-Random-cookie RPC authentication
----------------------------------
-
-When no `-rpcpassword` is specified, the daemon now uses a special 'cookie'
-file for authentication. This file is generated with random content when the
-daemon starts, and deleted when it exits. Its contents are used as
-authentication token. Read access to this file controls who can access through
-RPC. By default it is stored in the data directory but its location can be
-overridden with the option `-rpccookiefile`.
-
-This is similar to Tor's CookieAuthentication: see
-https://www.torproject.org/docs/tor-manual.html.en
-
-This allows running bitcoind without having to do any manual configuration.
-
-Low-level RPC API changes
---------------------------
-
-- Monetary amounts can be provided as strings. This means that for example the
-  argument to sendtoaddress can be "0.0001" instead of 0.0001. This can be an
-  advantage if a JSON library insists on using a lossy floating point type for
-  numbers, which would be dangerous for monetary amounts.
-
-Option parsing behavior
------------------------
-
-Command line options are now parsed strictly in the order in which they are
-specified. It used to be the case that `-X -noX` ends up, unintuitively, with X
-set, as `-X` had precedence over `-noX`. This is no longer the case. Like for
-other software, the last specified value for an option will hold.
-
-`NODE_BLOOM` service bit
-------------------------
-
-Support for the `NODE_BLOOM` service bit, as described in [BIP
-111](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki), has been
-added to the P2P protocol code.
-
-BIP 111 defines a service bit to allow peers to advertise that they support
-bloom filters (such as used by SPV clients) explicitly. It also bumps the protocol
-version to allow peers to identify old nodes which allow bloom filtering of the
-connection despite lacking the new service bit.
-
-In this version, it is only enforced for peers that send protocol versions
-`>=70011`. For the next major version it is planned that this restriction will be
-removed. It is recommended to update SPV clients to check for the `NODE_BLOOM`
-service bit for nodes that report versions newer than 70011.
-
-Merkle branches removed from wallet
------------------------------------
-
-Previously, every wallet transaction stored a Merkle branch to prove its
-presence in blocks. This wasn't being used for more than an expensive
-sanity check. Since 0.12, these are no longer stored. When loading a
-0.12 wallet into an older version, it will automatically rescan to avoid
-failed checks.
-
-0.12.0 Change log
+0.13.0 Change log
 =================
 
 Detailed release notes follow. This overview includes changes that affect
@@ -124,33 +18,20 @@ git merge commit are mentioned.
 
 ### RPC and REST
 
-Asm representations of scriptSig signatures now contain SIGHASH type decodes
-----------------------------------------------------------------------------
-
-The `asm` property of each scriptSig now contains the decoded signature hash
-type for each signature that provides a valid defined hash type.
+Asm script outputs now contain OP_CHECKLOCKTIMEVERIFY in place of OP_NOP2
+-------------------------------------------------------------------------
 
-The following items contain assembly representations of scriptSig signatures
-and are affected by this change:
+OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP 
+65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki)
 
-- RPC `getrawtransaction`
+The following outputs are affected by this change:
+- RPC `getrawtransaction` (in verbose mode)
 - RPC `decoderawtransaction`
+- RPC `decodescript`
 - REST `/rest/tx/` (JSON format)
 - REST `/rest/block/` (JSON format when including extended tx details)
 - `bitcoin-tx -json`
 
-For example, the `scriptSig.asm` property of a transaction input that
-previously showed an assembly representation of:
-
-    304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c509001
-
-now shows as:
-
-    304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c5090[ALL]
-
-Note that the output of the RPC `decodescript` did not change because it is
-configured specifically to process scriptPubKey and not scriptSig scripts.
-
 ### Configuration and command-line options
 
 ### Block and transaction handling
@@ -169,13 +50,3 @@ configured specifically to process scriptPubKey and not scriptSig scripts.
 
 ### Miscellaneous
 
-- Removed bitrpc.py from contrib
-
-Addition of ZMQ-based Notifcations
-==================================
-
-Bitcoind can now (optionally) asynchronously notify clients through a
-ZMQ-based PUB socket of the arrival of new transactions and blocks.
-This feature requires installation of the ZMQ C API library 4.x and
-configuring its use through the command line or configuration file.
-Please see docs/zmq.md for details of operation.
diff --git a/doc/release-notes/release-notes-0.10.3.md b/doc/release-notes/release-notes-0.10.3.md
new file mode 100644
index 000000000..8a110e562
--- /dev/null
+++ b/doc/release-notes/release-notes-0.10.3.md
@@ -0,0 +1,165 @@
+Bitcoin Core version 0.10.3 is now available from:
+
+  <https://bitcoin.org/bin/bitcoin-core-0.10.3/>
+
+This is a new minor version release, bringing security fixes and translation 
+updates. It is recommended to upgrade to this version as soon as possible.
+
+Please report bugs using the issue tracker at github:
+
+  <https://github.com/bitcoin/bitcoin/issues>
+
+Upgrading and downgrading
+=========================
+
+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/Bitcoin-Qt (on Mac) or
+bitcoind/bitcoin-qt (on Linux).
+
+Downgrade warning
+------------------
+
+Because release 0.10.0 and later makes use of headers-first synchronization and
+parallel block download (see further), the block files and databases are not
+backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
+
+* Blocks will be stored on disk out of order (in the order they are
+received, really), which makes it incompatible with some tools or
+other programs. Reindexing using earlier versions will also not work
+anymore as a result of this.
+
+* The block index database will now hold headers for which no block is
+stored on disk, which earlier versions won't support.
+
+If you want to be able to downgrade smoothly, make a backup of your entire data
+directory. Without this your node will need start syncing (or importing from
+bootstrap.dat) anew afterwards. It is possible that the data from a completely
+synchronised 0.10 node may be usable in older versions as-is, but this is not
+supported and may break as soon as the older version attempts to reindex.
+
+This does not affect wallet forward or backward compatibility.
+
+Notable changes
+===============
+
+Fix buffer overflow in bundled upnp
+------------------------------------
+
+Bundled miniupnpc was updated to 1.9.20151008. This fixes a buffer overflow in
+the XML parser during initial network discovery.
+
+Details can be found here: http://talosintel.com/reports/TALOS-2015-0035/
+
+This applies to the distributed executables only, not when building from source or
+using distribution provided packages.
+
+Additionally, upnp has been disabled by default. This may result in a lower
+number of reachable nodes on IPv4, however this prevents future libupnpc
+vulnerabilities from being a structural risk to the network
+(see https://github.com/bitcoin/bitcoin/pull/6795).
+
+Test for LowS signatures before relaying
+-----------------------------------------
+
+Make the node require the canonical 'low-s' encoding for ECDSA signatures when
+relaying or mining.  This removes a nuisance malleability vector.
+
+Consensus behavior is unchanged.
+
+If widely deployed this change would eliminate the last remaining known vector
+for nuisance malleability on SIGHASH_ALL P2PKH transactions. On the down-side
+it will block most transactions made by sufficiently out of date software.
+
+Unlike the other avenues to change txids on transactions this
+one was randomly violated by all deployed bitcoin software prior to
+its discovery. So, while other malleability vectors where made
+non-standard as soon as they were discovered, this one has remained
+permitted. Even BIP62 did not propose applying this rule to
+old version transactions, but conforming implementations have become
+much more common since BIP62 was initially written.
+
+Bitcoin Core has produced compatible signatures since a28fb70e in
+September 2013, but this didn't make it into a release until 0.9
+in March 2014; Bitcoinj has done so for a similar span of time.
+Bitcoinjs and electrum have been more recently updated.
+
+This does not replace the need for BIP62 or similar, as miners can
+still cooperate to break transactions.  Nor does it replace the
+need for wallet software to handle malleability sanely[1]. This
+only eliminates the cheap and irritating DOS attack.
+
+[1] On the Malleability of Bitcoin Transactions
+Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, Łukasz Mazurek
+http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf
+
+Minimum relay fee default increase
+-----------------------------------
+
+The default for the `-minrelaytxfee` setting has been increased from `0.00001`
+to `0.00005`.
+
+This is necessitated by the current transaction flooding, causing
+outrageous memory usage on nodes due to the mempool ballooning. This is a
+temporary measure, bridging the time until a dynamic method for determining
+this fee is merged (which will be in 0.12).
+
+(see https://github.com/bitcoin/bitcoin/pull/6793, as well as the 0.11.0
+release notes, in which this value was suggested)
+
+0.10.3 Change log
+=================
+
+Detailed release notes follow. This overview includes changes that affect external
+behavior, not code moves, refactors or string updates.
+
+- #6186 `e4a7d51` Fix two problems in CSubnet parsing
+- #6153 `ebd7d8d` Parameter interaction: disable upnp if -proxy set
+- #6203 `ecc96f5` Remove P2SH coinbase flag, no longer interesting
+- #6226 `181771b` json: fail read_string if string contains trailing garbage
+- #6244 `09334e0` configure: Detect (and reject) LibreSSL
+- #6276 `0fd8464` Fix getbalance * 0
+- #6274 `be64204` Add option `-alerts` to opt out of alert system
+- #6319 `3f55638` doc: update mailing list address
+- #6438 `7e66e9c` openssl: avoid config file load/race
+- #6439 `255eced` Updated URL location of netinstall for Debian
+- #6412 `0739e6e` Test whether created sockets are select()able
+- #6694 `f696ea1` [QT] fix thin space word wrap line brake issue
+- #6704 `743cc9e` Backport bugfixes to 0.10
+- #6769 `1cea6b0` Test LowS in standardness, removes nuisance malleability vector.
+- #6789 `093d7b5` Update miniupnpc to 1.9.20151008
+- #6795 `f2778e0` net: Disable upnp by default
+- #6797 `91ef4d9` Do not store more than 200 timedata samples
+- #6793 `842c48d` Bump minrelaytxfee default
+
+Credits
+=======
+
+Thanks to everyone who directly contributed to this release:
+
+- Adam Weiss
+- Alex Morcos
+- Casey Rodarmor
+- Cory Fields
+- fanquake
+- Gregory Maxwell
+- Jonas Schnelli
+- J Ross Nicoll
+- Luke Dashjr
+- Pavel Vasin
+- Pieter Wuille
+- randy-waterhouse
+- ฿tcDrak
+- Tom Harding
+- Veres Lajos
+- Wladimir J. van der Laan
+
+And all those who contributed additional code review and/or security research:
+
+- timothy on IRC for reporting the issue
+- Vulnerability in miniupnp discovered by Aleksandar Nikolic of Cisco Talos
+
+As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
diff --git a/doc/release-notes/release-notes-0.11.1.md b/doc/release-notes/release-notes-0.11.1.md
new file mode 100644
index 000000000..799205691
--- /dev/null
+++ b/doc/release-notes/release-notes-0.11.1.md
@@ -0,0 +1,172 @@
+Bitcoin Core version 0.11.1 is now available from:
+
+  <https://bitcoin.org/bin/bitcoin-core-0.11.1/>
+
+This is a new minor version release, bringing security fixes. It is recommended
+to upgrade to this version as soon as possible.
+
+Please report bugs using the issue tracker at github:
+
+  <https://github.com/bitcoin/bitcoin/issues>
+
+Upgrading and downgrading
+=========================
+
+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/Bitcoin-Qt (on Mac) or
+bitcoind/bitcoin-qt (on Linux).
+
+Downgrade warning
+------------------
+
+Because release 0.10.0 and later makes use of headers-first synchronization and
+parallel block download (see further), the block files and databases are not
+backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
+
+* Blocks will be stored on disk out of order (in the order they are
+received, really), which makes it incompatible with some tools or
+other programs. Reindexing using earlier versions will also not work
+anymore as a result of this.
+
+* The block index database will now hold headers for which no block is
+stored on disk, which earlier versions won't support.
+
+If you want to be able to downgrade smoothly, make a backup of your entire data
+directory. Without this your node will need start syncing (or importing from
+bootstrap.dat) anew afterwards. It is possible that the data from a completely
+synchronised 0.10 node may be usable in older versions as-is, but this is not
+supported and may break as soon as the older version attempts to reindex.
+
+This does not affect wallet forward or backward compatibility. There are no
+known problems when downgrading from 0.11.x to 0.10.x.
+
+Notable changes
+===============
+
+Fix buffer overflow in bundled upnp
+------------------------------------
+
+Bundled miniupnpc was updated to 1.9.20151008. This fixes a buffer overflow in
+the XML parser during initial network discovery.
+
+Details can be found here: http://talosintel.com/reports/TALOS-2015-0035/
+
+This applies to the distributed executables only, not when building from source or
+using distribution provided packages.
+
+Additionally, upnp has been disabled by default. This may result in a lower
+number of reachable nodes on IPv4, however this prevents future libupnpc
+vulnerabilities from being a structural risk to the network
+(see https://github.com/bitcoin/bitcoin/pull/6795).
+
+Test for LowS signatures before relaying
+-----------------------------------------
+
+Make the node require the canonical 'low-s' encoding for ECDSA signatures when
+relaying or mining.  This removes a nuisance malleability vector.
+
+Consensus behavior is unchanged.
+
+If widely deployed this change would eliminate the last remaining known vector
+for nuisance malleability on SIGHASH_ALL P2PKH transactions. On the down-side
+it will block most transactions made by sufficiently out of date software.
+
+Unlike the other avenues to change txids on transactions this
+one was randomly violated by all deployed bitcoin software prior to
+its discovery. So, while other malleability vectors where made
+non-standard as soon as they were discovered, this one has remained
+permitted. Even BIP62 did not propose applying this rule to
+old version transactions, but conforming implementations have become
+much more common since BIP62 was initially written.
+
+Bitcoin Core has produced compatible signatures since a28fb70e in
+September 2013, but this didn't make it into a release until 0.9
+in March 2014; Bitcoinj has done so for a similar span of time.
+Bitcoinjs and electrum have been more recently updated.
+
+This does not replace the need for BIP62 or similar, as miners can
+still cooperate to break transactions.  Nor does it replace the
+need for wallet software to handle malleability sanely[1]. This
+only eliminates the cheap and irritating DOS attack.
+
+[1] On the Malleability of Bitcoin Transactions
+Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, Łukasz Mazurek
+http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf
+
+Minimum relay fee default increase
+-----------------------------------
+
+The default for the `-minrelaytxfee` setting has been increased from `0.00001`
+to `0.00005`.
+
+This is necessitated by the current transaction flooding, causing
+outrageous memory usage on nodes due to the mempool ballooning. This is a
+temporary measure, bridging the time until a dynamic method for determining
+this fee is merged (which will be in 0.12).
+
+(see https://github.com/bitcoin/bitcoin/pull/6793, as well as the 0.11
+release notes, in which this value was suggested)
+
+0.11.1 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.
+
+- #6438 `2531438` openssl: avoid config file load/race
+- #6439 `980f820` Updated URL location of netinstall for Debian
+- #6384 `8e5a969` qt: Force TLS1.0+ for SSL connections
+- #6471 `92401c2` Depends: bump to qt 5.5
+- #6224 `93b606a` Be even stricter in processing unrequested blocks
+- #6571 `100ac4e` libbitcoinconsensus: avoid a crash in multi-threaded environments
+- #6545 `649f5d9` Do not store more than 200 timedata samples.
+- #6694 `834e299` [QT] fix thin space word wrap line break issue
+- #6703 `1cd7952` Backport bugfixes to 0.11
+- #6750 `5ed8d0b` Recent rejects backport to v0.11
+- #6769 `71cc9d9` Test LowS in standardness, removes nuisance malleability vector.
+- #6789 `b4ad73f` Update miniupnpc to 1.9.20151008
+- #6785 `b4dc33e` Backport to v0.11: In (strCommand == "tx"), return if AlreadyHave()
+- #6412 `0095b9a` Test whether created sockets are select()able
+- #6795 `4dbcec0` net: Disable upnp by default
+- #6793 `e7bcc4a` Bump minrelaytxfee default
+
+Credits
+=======
+
+Thanks to everyone who directly contributed to this release:
+
+- Adam Weiss
+- Alex Morcos
+- Casey Rodarmor
+- Cory Fields
+- fanquake
+- Gregory Maxwell
+- Jonas Schnelli
+- J Ross Nicoll
+- Luke Dashjr
+- Pavel Janík
+- Pavel Vasin
+- Peter Todd
+- Pieter Wuille
+- randy-waterhouse
+- Ross Nicoll
+- Suhas Daftuar
+- tailsjoin
+- ฿tcDrak
+- Tom Harding
+- Veres Lajos
+- Wladimir J. van der Laan
+
+And those who contributed additional code review and/or security research:
+
+- timothy on IRC for reporting the issue
+- Vulnerability in miniupnp discovered by Aleksandar Nikolic of Cisco Talos
+
+As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
+
diff --git a/doc/release-notes/release-notes-0.6.3.md b/doc/release-notes/release-notes-0.6.3.md
index 28bb20e10..c27f607b5 100644
--- a/doc/release-notes/release-notes-0.6.3.md
+++ b/doc/release-notes/release-notes-0.6.3.md
@@ -23,7 +23,7 @@ hundreds of blocks long.
 Bitcoin-Qt no longer automatically selects the first address
 in the address book (Issue #1384).
 
-Fixed minimize-to-dock behavior of Bitcon-Qt on the Mac.
+Fixed minimize-to-dock behavior of Bitcoin-Qt on the Mac.
 
 Added a block checkpoint at block 185,333 to speed up initial
 blockchain download.
diff --git a/doc/release-process.md b/doc/release-process.md
index 1bfdb8fab..9a2362cb8 100644
--- a/doc/release-process.md
+++ b/doc/release-process.md
@@ -1,19 +1,21 @@
 Release Process
 ====================
 
-* update translations (ping wumpus, Diapolo or tcatm on IRC)
-* see https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md#syncing-with-transifex
+* Update translations (ping wumpus, Diapolo or tcatm on IRC) see [translation_process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md#syncing-with-transifex)
+* Update [bips.md](bips.md) to account for changes since the last release.
 
 * * *
 
-###first time only or for new builders, check out the source in the following directory hierarchy
+###First time / New builders
+Check out the source code in the following directory hierarchy.
 
 	cd /path/to/your/toplevel/build
 	git clone https://github.com/bitcoin/gitian.sigs.git
+	git clone https://github.com/bitcoin/bitcoin-detached-sigs.git
 	git clone https://github.com/devrandom/gitian-builder.git
 	git clone https://github.com/bitcoin/bitcoin.git
 
-###for bitcoin maintainers/release engineers, update (commit) version in sources
+###Bitcoin maintainers/release engineers, update (commit) version in sources
 
 	pushd ./bitcoin
 	contrib/verifysfbinaries/verify.sh
@@ -21,72 +23,68 @@ Release Process
 	share/setup.nsi
 	src/clientversion.h (change CLIENT_VERSION_IS_RELEASE to true)
 
-###for bitcoin maintainers/release engineers, tag version in git
+	# tag version in git
 
 	git tag -s v(new version, e.g. 0.8.0)
 
-###for bitcoin maintainers/release engineers, write release notes. git shortlog helps a lot, for example:
+	# 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)
 	popd
 
 * * *
 
-###update gitian, gitian.sigs, checkout bitcoin version, and perform gitian builds
+###Setup and perform Gitian builds
+
+ Setup Gitian descriptors:
 
- To ensure your gitian descriptors are accurate for direct reference for gbuild, below, run the following from a directory containing the bitcoin source:
-  
 	pushd ./bitcoin
-	export SIGNER=(your gitian key, ie bluematt, sipa, etc)
+	export SIGNER=(your Gitian key, ie bluematt, sipa, etc)
 	export VERSION=(new version, e.g. 0.8.0)
 	git checkout v${VERSION}
 	popd
 
-  Ensure your gitian.sigs are up-to-date if you wish to gverify your builds against other gitian signatures:
+  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 your gitian-builder sources are up-to-date to take advantage of the new caching features of gitian (`e9741525c` or later is recommended)
+  Ensure gitian-builder is up-to-date to take advantage of new caching features (`e9741525c` or later is recommended).
 
 	pushd ./gitian-builder
 	git pull
 
-###fetch and create inputs: (first time, or when dependency versions change)
- 
+###Fetch and create inputs: (first time, or when dependency versions change)
+
 	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
 
- Register and download the Apple SDK: (see OSX Readme for details)
- 
+ Register and download the Apple SDK: see [OS X readme](README_osx.txt) for details.
+
  https://developer.apple.com/devcenter/download.action?path=/Developer_Tools/xcode_6.1.1/xcode_6.1.1.dmg
- 
+
  Using a Mac, create a tarball for the 10.9 SDK and copy it to the inputs directory:
- 
+
 	tar -C /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -czf MacOSX10.9.sdk.tar.gz MacOSX10.9.sdk
 
 ###Optional: Seed the Gitian sources cache and offline git repositories
 
-By default, gitian will fetch source files as needed. To cache them ahead of time:
+By default, Gitian will fetch source files as needed. To cache them ahead of time:
 
 	make -C ../bitcoin/depends download SOURCES_PATH=`pwd`/cache/common
 
 Only missing files will be fetched, so this is safe to re-run for each build.
 
-Clone the detached-sigs repository:
-
-	popd
-	git clone https://github.com/bitcoin/bitcoin-detached-sigs.git
-	pushd ./bitcoin-builder
-
-NOTE: Offline builds must use the --url flag to ensure gitian fetches only from local URLs.
-For example: ./bin/bguild --url bitcoin=/path/to/bitcoin,signature=/path/to/sigs {rest of arguments}
-The following gbuild invocations DO NOT DO THIS by default.
+NOTE: Offline builds must use the --url flag to ensure Gitian fetches only from local URLs. For example:
+```
+./bin/gbuild --url bitcoin=/path/to/bitcoin,signature=/path/to/sigs {rest of arguments}
+```
+The gbuild invocations below <b>DO NOT DO THIS</b> by default.
 
 ###Build (and optionally verify) Bitcoin Core for Linux, Windows, and OS X:
-  
+
 	./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
 	./bin/gsign --signer $SIGNER --release ${VERSION}-linux --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
 	./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-linux ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
@@ -110,8 +108,8 @@ The following gbuild invocations DO NOT DO THIS by default.
   1. source tarball (bitcoin-${VERSION}.tar.gz)
   2. linux 32-bit and 64-bit dist tarballs (bitcoin-${VERSION}-linux[32|64].tar.gz)
   3. windows 32-bit and 64-bit unsigned installers and dist zips (bitcoin-${VERSION}-win[32|64]-setup-unsigned.exe, bitcoin-${VERSION}-win[32|64].zip)
-  4. OSX unsigned installer and dist tarball (bitcoin-${VERSION}-osx-unsigned.dmg, bitcoin-${VERSION}-osx64.tar.gz)
-  5. Gitian signatures (in gitian.sigs/${VERSION}-<linux|{win,osx}-unsigned>/(your gitian key)/
+  4. OS X unsigned installer and dist tarball (bitcoin-${VERSION}-osx-unsigned.dmg, bitcoin-${VERSION}-osx64.tar.gz)
+  5. Gitian signatures (in gitian.sigs/${VERSION}-<linux|{win,osx}-unsigned>/(your Gitian key)/
 
 ###Next steps:
 
@@ -125,11 +123,12 @@ Commit your signature to gitian.sigs:
 	git push  # Assuming you can push to the gitian.sigs tree
 	popd
 
-  Wait for Windows/OSX detached signatures:
-	Once the Windows/OSX builds each have 3 matching signatures, they will be signed with their respective release keys.
-	Detached signatures will then be committed to the bitcoin-detached-sigs repository, which can be combined with the unsigned apps to create signed binaries.
+  Wait for Windows/OS X detached signatures:
+
+	Once the Windows/OS X builds each have 3 matching signatures, they will be signed with their respective release keys.
+	Detached signatures will then be committed to the [bitcoin-detached-sigs](https://github.com/bitcoin/bitcoin-detached-sigs) repository, which can be combined with the unsigned apps to create signed binaries.
 
-  Create (and optionally verify) the signed OSX binary:
+  Create (and optionally verify) the signed OS X binary:
 
 	pushd ./gitian-builder
 	./bin/gbuild -i --commit signature=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-osx-signer.yml
@@ -148,7 +147,7 @@ Commit your signature to gitian.sigs:
 	mv build/out/bitcoin-*win32-setup.exe ../bitcoin-${VERSION}-win32-setup.exe
 	popd
 
-Commit your signature for the signed OSX/Windows binaries:
+Commit your signature for the signed OS X/Windows binaries:
 
 	pushd gitian.sigs
 	git add ${VERSION}-osx-signed/${SIGNER}
@@ -176,14 +175,14 @@ Note: check that SHA256SUMS itself doesn't end up in SHA256SUMS, which is a spur
 - Update bitcoin.org version
 
   - First, check to see if the Bitcoin.org maintainers have prepared a
-    release: https://github.com/bitcoin/bitcoin.org/labels/Releases
+    release: https://github.com/bitcoin-dot-org/bitcoin.org/labels/Releases
 
       - If they have, it will have previously failed their Travis CI
         checks because the final release files weren't uploaded.
         Trigger a Travis CI rebuild---if it passes, merge.
 
   - If they have not prepared a release, follow the Bitcoin.org release
-    instructions: https://github.com/bitcoin/bitcoin.org#release-notes
+    instructions: https://github.com/bitcoin-dot-org/bitcoin.org#release-notes
 
   - After the pull request is merged, the website will automatically show the newest version within 15 minutes, as well
     as update the OS download links. Ping @saivann/@harding (saivann/harding on Freenode) in case anything goes wrong
diff --git a/doc/shared-libraries.md b/doc/shared-libraries.md
index f1448f725..f4ff53d6e 100644
--- a/doc/shared-libraries.md
+++ b/doc/shared-libraries.md
@@ -41,3 +41,4 @@ The interface is defined in the C header `bitcoinconsensus.h` located in  `src/s
 - [NBitcoin](https://github.com/NicolasDorier/NBitcoin/blob/master/NBitcoin/Script.cs#L814) (.NET Bindings)
 - [node-libbitcoinconsensus](https://github.com/bitpay/node-libbitcoinconsensus) (Node.js Bindings)
 - [java-libbitcoinconsensus](https://github.com/dexX7/java-libbitcoinconsensus) (Java Bindings)
+- [bitcoinconsensus-php](https://github.com/Bit-Wasp/bitcoinconsensus-php) (PHP Bindings)
diff --git a/doc/tor.md b/doc/tor.md
index f8b94d19d..1d35a658b 100644
--- a/doc/tor.md
+++ b/doc/tor.md
@@ -15,15 +15,15 @@ outgoing connections be anonymized, 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 service.
-	
+
 	-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
@@ -55,10 +55,10 @@ your bitcoind's P2P listen port (8333 by default).
 	                preference for your node to advertize itself with, for connections
 	                coming from unroutable addresses (such as 127.0.0.1, where the
 	                Tor proxy typically runs).
-	
+
 	-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
@@ -88,3 +88,19 @@ for normal IPv4/IPv6 communication, use:
 
 	./bitcoin -onion=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.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.
+Bitcoin Core has been updated to make use of this.
+
+This means that if Tor is running (and proper authorization is available),
+Bitcoin Core automatically creates a hidden service to listen on, without
+manual configuration. This will positively affect the number of available
+.onion nodes.
+
+This new feature is enabled by default if Bitcoin Core is listening, and
+a connection to Tor can be made. It can be configured with the `-listenonion`,
+`-torcontrol` and `-torpassword` settings. To show verbose debugging
+information, pass `-debug=tor`.
diff --git a/doc/translation_process.md b/doc/translation_process.md
index b06975e1d..310d560b3 100644
--- a/doc/translation_process.md
+++ b/doc/translation_process.md
@@ -1,7 +1,7 @@
 Translations
 ============
 
-The Bitcoin-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, Bitcoin-Core makes use of the Transifex online translation management tool. 
+The Bitcoin-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, Bitcoin-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.
@@ -74,10 +74,10 @@ The Transifex Bitcoin project config file is included as part of the repo. It ca
 To assist in updating translations, we have created a script to help.
 
 1. `python contrib/devtools/update-translations.py`
-2. Update `src/qt/bitcoin.qrc` manually or via
+2. Update `src/qt/bitcoin_locale.qrc` manually or via
    `ls src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/<file alias="\2">locale\/\1.qm<\/file>/'`
-3. Update `src/qt/Makefile.am` manually or via
-   `ls src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/  locale\/\1.ts \\/'`
+3. Update `src/Makefile.qt.include` manually or via
+   `ls src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/  qt\/locale\/\1.ts \\/'`
 4. `git add` new translations from `src/qt/locale/`
 
 **Do not directly download translations** one by one from the Transifex website, as we do a few post-processing steps before committing the translations.
diff --git a/doc/translation_strings_policy.md b/doc/translation_strings_policy.md
index cf72a55b2..b95259cdc 100644
--- a/doc/translation_strings_policy.md
+++ b/doc/translation_strings_policy.md
@@ -1,7 +1,7 @@
 Translation Strings Policy
 ===========================
 
-This document provides guidelines for internationalization of the Bitcoin Core software. 
+This document provides guidelines for internationalization of the Bitcoin Core software.
 
 How to translate?
 ------------------
@@ -52,7 +52,7 @@ Try to write translation strings in an understandable way, for both the user and
 ### Do not translate internal errors
 
 Do not translate internal errors, or log messages, or messages that appear on the RPC interface. If an error is to be shown to the user,
-use a generic message, then log the detailed message to the log. E.g. "Error: A fatal internal error occurred, see debug.log for details".
+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
@@ -107,4 +107,3 @@ The second example reduces the number of pluralized words that translators have
 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 `bitcoin_en.ts` remains unchanged.
-
diff --git a/doc/unit-tests.md b/doc/unit-tests.md
index 72613054b..afaece829 100644
--- a/doc/unit-tests.md
+++ b/doc/unit-tests.md
@@ -1,18 +1,18 @@
 Compiling/running unit tests
 ------------------------------------
 
-Unit tests will be automatically compiled if dependencies were met in configure
+Unit tests will be automatically compiled if dependencies were met in `./configure`
 and tests weren't explicitly disabled.
 
-After configuring, they can be run with 'make check'.
+After configuring, they can be run with `make check`.
 
-To run the bitcoind tests manually, launch src/test/test_bitcoin .
+To run the bitcoind tests manually, launch `src/test/test_bitcoin`.
 
 To add more bitcoind tests, add `BOOST_AUTO_TEST_CASE` functions to the existing
-.cpp files in the test/ directory or add new .cpp files that
+.cpp files in the `test/` directory or add new .cpp files that
 implement new BOOST_AUTO_TEST_SUITE sections.
 
-To run the bitcoin-qt tests manually, launch src/qt/test/test_bitcoin-qt
+To run the bitcoin-qt tests manually, launch `src/qt/test/test_bitcoin-qt`
 
 To add more bitcoin-qt tests, add them to the `src/qt/test/` directory and
 the `src/qt/test/test_main.cpp` file.
diff --git a/doc/zmq.md b/doc/zmq.md
index 358d29d04..902d1124c 100644
--- a/doc/zmq.md
+++ b/doc/zmq.md
@@ -2,7 +2,7 @@
 
 [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/subcribe,
+providing various message-oriented semantics such as publish/subscribe,
 request/reply, and push/pull.
 
 The Bitcoin Core daemon can be configured to act as a trusted "border
@@ -43,14 +43,14 @@ operation.
 
 ## Enabling
 
-By default, the ZeroMQ port functionality is enabled. Two steps are
-required to enable--compiling in the ZeroMQ code, and configuring
-runtime operation on the command-line or configuration file.
+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 bitcoind:
 
-    $ ./configure --enable-zmq (other options)
+    $ ./configure --disable-zmq (other options)
 
-This will produce a binary that is capable of providing the ZeroMQ
-facility, but will not do so until also configured properly.
+To actually enable operation, one must set the appropriate options on
+the commandline or in the configuration file.
 
 ## Usage
 
@@ -78,7 +78,7 @@ bytes).
 These options can also be provided in bitcoin.conf.
 
 ZeroMQ endpoint specifiers for TCP (and others) are documented in the
-[ZeroMQ API](http://api.zeromq.org).
+[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
author	Luke Dashjr <[email protected]>	2016-01-15 05:17:15 +0000
committer	Luke Dashjr <[email protected]>	2016-01-15 05:17:15 +0000
commit	5bc4fb7b602c420be1c746442edad6b2d8e333ab (patch)
tree	32ce1458f7fafdf4f9a1dcb09091f1a6de416625 /doc
parent	banlist (bugfix): allow CNode::SweepBanned() to run on interval (diff)
parent	Merge pull request #7327 (diff)
download	discoin-5bc4fb7b602c420be1c746442edad6b2d8e333ab.tar.xz discoin-5bc4fb7b602c420be1c746442edad6b2d8e333ab.zip