aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/Doxyfile2
-rw-r--r--doc/README.md2
-rw-r--r--doc/README_windows.txt2
-rw-r--r--doc/bips.md2
-rw-r--r--doc/build-osx.md20
-rw-r--r--doc/build-unix.md19
-rw-r--r--doc/developer-notes.md169
-rw-r--r--doc/gitian-building.md11
-rw-r--r--doc/release-notes.md240
-rw-r--r--doc/release-notes/release-notes-0.6.3.md2
-rw-r--r--doc/release-process.md33
-rw-r--r--doc/translation_process.md6
-rw-r--r--doc/unit-tests.md10
13 files changed, 247 insertions, 271 deletions
diff --git a/doc/Doxyfile b/doc/Doxyfile
index 925a33ee89..428fba98e1 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 f6df28a89b..c0f9ee5220 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -1,4 +1,4 @@
-Bitcoin Core 0.11.99
+Bitcoin Core 0.12.99
=====================
Setup
diff --git a/doc/README_windows.txt b/doc/README_windows.txt
index e4fd9bdf90..2d1c4503c9 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 c780e2dde0..e73add0130 100644
--- a/doc/bips.md
+++ b/doc/bips.md
@@ -18,3 +18,5 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.12.0**):
* [`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-osx.md b/doc/build-osx.md
index 02498e5c4b..c3cb1b7891 100644
--- a/doc/build-osx.md
+++ b/doc/build-osx.md
@@ -5,7 +5,7 @@ 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`.
@@ -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
@@ -36,17 +36,19 @@ Instructions: Homebrew
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.
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
+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 159a140608..60c9d57b0a 100644
--- a/doc/build-unix.md
+++ b/doc/build-unix.md
@@ -50,18 +50,21 @@ Optional dependencies:
For the versions used in the release, see [release-process.md](release-process.md) under *Fetch and build inputs*.
-System requirements
+Memory Requirements
--------------------
-C++ compilers are memory-hungry. It is recommended to have at least 1 GB of
-memory available when compiling Bitcoin Core. With 512MB of memory or less
-compilation will take much longer due to swap thrashing.
+C++ compilers are memory-hungry. It is recommended to have at least 1.5 GB of
+memory available when compiling Bitcoin 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"
Dependency Build Instructions: Ubuntu & Debian
----------------------------------------------
Build requirements:
- sudo apt-get install build-essential libtool autotools-dev autoconf pkg-config libssl-dev libevent-dev bsdmainutils
+ sudo apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils
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
@@ -236,3 +239,9 @@ In this case there is no dependency on Berkeley DB 4.8.
Mining is also possible in disable-wallet mode, but only using the `getblocktemplate` RPC
call not `getwork`.
+
+Additional Configure Flags
+--------------------------
+A list of additional configure flags can be displayed with:
+
+ ./configure --help
diff --git a/doc/developer-notes.md b/doc/developer-notes.md
index 7fe292f1f8..358792251b 100644
--- a/doc/developer-notes.md
+++ b/doc/developer-notes.md
@@ -204,3 +204,172 @@ 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/gitian-building.md b/doc/gitian-building.md
index 019e851696..5ca91505e7 100644
--- a/doc/gitian-building.md
+++ b/doc/gitian-building.md
@@ -74,11 +74,11 @@ In the VirtualBox GUI click "Create" and choose the following parameters in the
- 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/)).
+Get the [Debian 8.x net installer](http://cdimage.debian.org/debian-cd/8.3.0/amd64/iso-cd/debian-8.3.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 "d393d17ac6b3113c81186e545c416a00f28ed6e05774284bb5e8f0df39fcbcb9 debian-8.2.0-amd64-netinst.iso" | sha256sum -c
+ echo "dd25bcdde3c6ea5703cc0f313cde621b13d42ff7d252e2538a11663c93bf8654 debian-8.3.0-amd64-netinst.iso" | sha256sum -c
# (must return OK)
After creating the VM, we need to configure it.
@@ -259,15 +259,15 @@ adduser debian sudo
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
+# the version of lxc-start in Debian needs to run as root, so make sure
# 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
# 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 'iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE' >> /etc/rc.local
+echo 'echo 1 > /proc/sys/net/ipv4/ip_forward' >> /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
@@ -305,6 +305,7 @@ 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
+git clone https://github.com/bitcoin/gitian.sigs.git
```
Setting up the Gitian image
diff --git a/doc/release-notes.md b/doc/release-notes.md
index 7db27f9fac..801b684e6b 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -4,208 +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.
-
-Any sequence of pushdatas in OP_RETURN outputs now allowed
-----------------------------------------------------------
-
-Previously OP_RETURN outputs with a payload were only relayed and mined if they
-had a single pushdata. This restriction has been lifted to allow any
-combination of data pushes and numeric constant opcodes (OP_1 to OP_16). The
-limit on OP_RETURN output size is now applied to the entire serialized
-scriptPubKey, 83 bytes by default. (the previous 80 byte default plus three
-bytes overhead)
-
-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.
-
-BIP65 - CHECKLOCKTIMEVERIFY
----------------------------
-
-Previously it was impossible to create a transaction output that was guaranteed
-to be unspendable until a specific date in the future. CHECKLOCKTIMEVERIFY is a
-new opcode that allows a script to check if a specific block height or time has
-been reached, failing the script otherwise. This enables a wide variety of new
-functionality such as time-locked escrows, secure payment channels, etc.
-
-BIP65 implements CHECKLOCKTIMEVERIFY by introducing block version 4, which adds
-additional restrictions to the NOP2 opcode. The same miner-voting mechanism as
-in BIP34 and BIP66 is used: when 751 out of a sequence of 1001 blocks have
-version number 4 or higher, the new consensus rule becomes active for those
-blocks. When 951 out of a sequence of 1001 blocks have version number 4 or
-higher, it becomes mandatory for all blocks and blocks with versions less than
-4 are rejected.
-
-Bitcoin Core's block templates are now for version 4 blocks only, and any
-mining software relying on its `getblocktemplate` must be updated in parallel
-to use either libblkmaker version 0.4.3 or any version from 0.5.2 onward. If
-you are solo mining, this will affect you the moment you upgrade Bitcoin Core,
-which must be done prior to BIP65 achieving its 951/1001 status. If you are
-mining with the stratum mining protocol: this does not affect you. If you are
-mining with the getblocktemplate protocol to a pool: this will affect you at
-the pool operator's discretion, which must be no later than BIP65 achieving its
-951/1001 status.
-
-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`.
-
-Reduce upload traffic
----------------------
-
-A major part of the outbound traffic is caused by serving historic blocks to
-other nodes in initial block download state.
-
-It is now possible to reduce the total upload traffic via the `-maxuploadtarget`
-parameter. This is *not* a hard limit but a threshold to minimize the outbound
-traffic. When the limit is about to be reached, the uploaded data is cut by not
-serving historic blocks (blocks older than one week).
-Moreover, any SPV peer is disconnected when they request a filtered block.
-
-This option can be specified in MiB per day and is turned off by default
-(`-maxuploadtarget=0`).
-The recommended minimum is 144 * MAX_BLOCK_SIZE (currently 144MB) per day.
-
-Whitelisted peers will never be disconnected, although their traffic counts for
-calculating the target.
-
-A more detailed documentation about keeping traffic low can be found in
-[/doc/reducetraffic.md](/doc/reducetraffic.md).
-
-Signature validation using libsecp256k1
----------------------------------------
-
-ECDSA signatures inside Bitcoin transactions now use validation using
-[https://github.com/bitcoin/secp256k1](libsecp256k1) instead of OpenSSL.
-
-Depending on the platform, this means a significant speedup for raw signature
-validation speed. The advantage is largest on x86_64, where validation is over
-five times faster. In practice, this translates to a raw reindexing and new
-block validation times that are less than half of what it was before.
-
-Libsecp256k1 has undergone very extensive testing and validation.
-
-A side effect of this change is that libconsensus no longer depends on OpenSSL.
-
-0.12.0 Change log
+0.13.0 Change log
=================
Detailed release notes follow. This overview includes changes that affect
@@ -215,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
@@ -260,13 +50,3 @@ configured specifically to process scriptPubKey and not scriptSig scripts.
### Miscellaneous
-- Removed bitrpc.py from contrib
-
-Addition of ZMQ-based Notifications
-==================================
-
-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.6.3.md b/doc/release-notes/release-notes-0.6.3.md
index 28bb20e104..c27f607b5c 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 9a2362cb85..39e3032a67 100644
--- a/doc/release-process.md
+++ b/doc/release-process.md
@@ -41,6 +41,7 @@ Check out the source code in the following directory hierarchy.
pushd ./bitcoin
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
@@ -83,25 +84,16 @@ NOTE: Offline builds must use the --url flag to ensure Gitian fetches only from
```
The gbuild invocations below <b>DO NOT DO THIS</b> by default.
-###Build (and optionally verify) Bitcoin Core for Linux, Windows, and OS X:
+###Build and Sign 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
- mv build/out/bitcoin-*.tar.gz build/out/src/bitcoin-*.tar.gz ../
./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-win-unsigned --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
- ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
- mv build/out/bitcoin-*-win-unsigned.tar.gz inputs/bitcoin-win-unsigned.tar.gz
- mv build/out/bitcoin-*.zip build/out/bitcoin-*.exe ../
./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-osx-unsigned --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml
- ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml
- mv build/out/bitcoin-*-osx-unsigned.tar.gz inputs/bitcoin-osx-unsigned.tar.gz
- mv build/out/bitcoin-*.tar.gz build/out/bitcoin-*.dmg ../
- popd
Build output expected:
@@ -111,6 +103,27 @@ The gbuild invocations below <b>DO NOT DO THIS</b> by default.
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)/
+###Verify other gitian builders signatures to your own. (Optional)
+
+ Add other gitian builders keys to your gpg keyring
+
+ gpg --import ../bitcoin/contrib/gitian-downloader/*.pgp
+
+ Verify the signatures
+
+ ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-linux ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
+ ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
+ ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml
+
+###Move the outputs to the correct directory
+
+ mv build/out/bitcoin-*.tar.gz build/out/src/bitcoin-*.tar.gz ../
+ mv build/out/bitcoin-*-win-unsigned.tar.gz inputs/bitcoin-win-unsigned.tar.gz
+ mv build/out/bitcoin-*.zip build/out/bitcoin-*.exe ../
+ mv build/out/bitcoin-*-osx-unsigned.tar.gz inputs/bitcoin-osx-unsigned.tar.gz
+ mv build/out/bitcoin-*.tar.gz build/out/bitcoin-*.dmg ../
+ popd
+
###Next steps:
Commit your signature to gitian.sigs:
diff --git a/doc/translation_process.md b/doc/translation_process.md
index 6389c5aced..310d560b36 100644
--- a/doc/translation_process.md
+++ b/doc/translation_process.md
@@ -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/unit-tests.md b/doc/unit-tests.md
index 72613054b9..afaece829c 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.