aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/Doxyfile2
-rw-r--r--doc/README.md14
-rw-r--r--doc/README_osx.txt13
-rw-r--r--doc/README_windows.txt12
-rw-r--r--doc/REST-interface.md67
-rw-r--r--doc/assets-attribution.md9
-rw-r--r--doc/bips.md18
-rw-r--r--doc/bootstrap.md56
-rw-r--r--doc/build-osx.md37
-rw-r--r--doc/build-unix.md8
-rw-r--r--doc/developer-notes.md (renamed from doc/coding.md)50
-rw-r--r--doc/dnsseed-policy.md21
-rw-r--r--doc/gitian-building.md46
-rw-r--r--doc/img/bootstrap1.pngbin55028 -> 0 bytes
-rw-r--r--doc/img/bootstrap2.pngbin35195 -> 0 bytes
-rw-r--r--doc/img/bootstrap4.pngbin110060 -> 0 bytes
-rw-r--r--doc/img/bootstrap5.pngbin20825 -> 0 bytes
-rw-r--r--doc/init.md14
-rw-r--r--doc/release-notes.md36
-rw-r--r--doc/release-notes/release-notes-0.10.0.md762
-rw-r--r--doc/release-notes/release-notes-0.10.1.md143
-rw-r--r--doc/release-notes/release-notes-0.10.2.md86
-rw-r--r--doc/release-notes/release-notes-0.9.4.md95
-rw-r--r--doc/release-notes/release-notes-0.9.5.md60
-rw-r--r--doc/release-process.md75
-rw-r--r--doc/translation_process.md4
-rw-r--r--doc/translation_strings_policy.md110
-rw-r--r--doc/unit-tests.md2
28 files changed, 1543 insertions, 197 deletions
diff --git a/doc/Doxyfile b/doc/Doxyfile
index 8a11d1e8d0..925a33ee89 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.10.99
+PROJECT_NUMBER = 0.11.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 ecb8dc80fd..ecddf50d4b 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -1,12 +1,9 @@
-Bitcoin 0.10.99
+Bitcoin Core 0.11.99
=====================
-Copyright (c) 2009-2014 Bitcoin Developers
-
-
Setup
---------------------
-[Bitcoin Core](http://bitcoin.org/en/download) is the original Bitcoin client and it builds the backbone of the network. However, it downloads and stores the entire history of Bitcoin transactions (which is currently several GBs); depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to a day or more. Thankfully you only have to do this once. If you would like the process to go faster you can [download the blockchain directly](bootstrap.md).
+[Bitcoin Core](http://bitcoin.org/en/download) is the original Bitcoin client and it builds the backbone of the network. However, it downloads and stores the entire history of Bitcoin transactions (which is currently several GBs); depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to a day or more.
Running
---------------------
@@ -46,18 +43,23 @@ The following are developer notes on how to build Bitcoin on your native platfor
- [OSX Build Notes](build-osx.md)
- [Unix Build Notes](build-unix.md)
+- [Gitian Building Guide](gitian-building.md)
Development
---------------------
The Bitcoin repo's [root README](https://github.com/bitcoin/bitcoin/blob/master/README.md) contains relevant information on the development process and automated testing.
-- [Coding Guidelines](coding.md)
+- [Developer Notes](developer-notes.md)
- [Multiwallet Qt Development](multiwallet-qt.md)
- [Release Notes](release-notes.md)
- [Release Process](release-process.md)
- [Source Code Documentation (External Link)](https://dev.visucore.com/bitcoin/doxygen/)
- [Translation Process](translation_process.md)
+- [Translation Strings Policy](translation_strings_policy.md)
- [Unit Tests](unit-tests.md)
+- [Unauthenticated REST Interface](REST-interface.md)
+- [BIPS](bips.md)
+- [Dnsseed Policy](dnsseed-policy.md)
### Resources
* Discuss on the [BitcoinTalk](https://bitcointalk.org/) forums, in the [Development & Technical Discussion board](https://bitcointalk.org/index.php?board=6.0).
diff --git a/doc/README_osx.txt b/doc/README_osx.txt
index d56234f7d9..a572c7a241 100644
--- a/doc/README_osx.txt
+++ b/doc/README_osx.txt
@@ -1,6 +1,6 @@
Deterministic OSX Dmg Notes.
-Working OSX DMG's are created in Linux by combining a recent clang,
+Working OSX 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
@@ -29,14 +29,15 @@ 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 xcode4630916281a.dmg:
-https://developer.apple.com/downloads/download.action?path=Developer_Tools/xcode_4.6.3/xcode4630916281a.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.7.sdk
+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:
- $ tar -C /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -czf MacOSX10.7.sdk.tar.gz MacOSX10.7.sdk
+ $ 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
@@ -57,7 +58,7 @@ libdmg-hfsplus project is used to compress it. There are several bugs in this
tool and its maintainer has seemingly abandoned the project. It has been forked
and is available (with fixes) here: https://github.com/theuni/libdmg-hfsplus .
-The 'dmg' tool has the ability to create DMG's from scratch as well, but this
+The 'dmg' tool has the ability to create DMGs from scratch as well, but this
functionality is broken. Only the compression feature is currently used.
Ideally, the creation could be fixed and genisoimage would no longer be necessary.
diff --git a/doc/README_windows.txt b/doc/README_windows.txt
index 5ac1152055..e4fd9bdf90 100644
--- a/doc/README_windows.txt
+++ b/doc/README_windows.txt
@@ -1,13 +1,5 @@
-Bitcoin 0.10.99
-
-Copyright (c) 2009-2014 Bitcoin Core Developers
-
-Distributed under the MIT software license, see the accompanying
-file COPYING or http://www.opensource.org/licenses/mit-license.php.
-This product includes software developed by the OpenSSL Project for use in
-the OpenSSL Toolkit (https://www.openssl.org/). This product includes
-cryptographic software written by Eric Young (eay@cryptsoft.com).
-
+Bitcoin Core 0.11.99
+=====================
Intro
-----
diff --git a/doc/REST-interface.md b/doc/REST-interface.md
index 0af650b4e8..2219ceb65f 100644
--- a/doc/REST-interface.md
+++ b/doc/REST-interface.md
@@ -5,13 +5,18 @@ The REST API can be enabled with the `-rest` option.
Supported API
-------------
-`GET /rest/tx/TX-HASH.{bin|hex|json}`
+
+####Transactions
+`GET /rest/tx/<TX-HASH>.<bin|hex|json>`
Given a transaction hash,
Returns a transaction, in binary, hex-encoded binary or JSON formats.
-`GET /rest/block/BLOCK-HASH.{bin|hex|json}`
-`GET /rest/block/notxdetails/BLOCK-HASH.{bin|hex|json}`
+For full TX query capability, one must enable the transaction index via "txindex=1" command line / configuration option.
+
+####Blocks
+`GET /rest/block/<BLOCK-HASH>.<bin|hex|json>`
+`GET /rest/block/notxdetails/<BLOCK-HASH>.<bin|hex|json>`
Given a block hash,
Returns a block, in binary, hex-encoded binary or JSON formats.
@@ -20,8 +25,60 @@ The HTTP request and response are both handled entirely in-memory, thus making m
With the /notxdetails/ option JSON response will only contain the transaction hash instead of the complete transaction details. The option only affects the JSON response.
-For full TX query capability, one must enable the transaction index via "txindex=1" command line / configuration option.
+####Blockheaders
+`GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex>`
+
+Given a block hash,
+Returns <COUNT> amount of blockheaders in upward direction.
+
+JSON is not supported.
+
+####Chaininfos
+`GET /rest/chaininfo.json`
+
+Returns various state info regarding block chain processing.
+Only supports JSON as output format.
+* chain : (string) current network name as defined in BIP70 (main, test, regtest)
+* blocks : (numeric) the current number of blocks processed in the server
+* headers : (numeric) the current number of headers we have validated
+* bestblockhash : (string) the hash of the currently best block
+* difficulty : (numeric) the current difficulty
+* verificationprogress : (numeric) estimate of verification progress [0..1]
+* chainwork : (string) total amount of work in active chain, in hexadecimal
+
+####Query UTXO set
+`GET /rest/getutxos/<checkmempool>/<txid>-<n>/<txid>-<n>/.../<txid>-<n>.<bin|hex|json>`
+
+The getutxo command allows querying of the UTXO set given a set of outpoints.
+See BIP64 for input and output serialisation:
+https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki
+
+Example:
+```
+$ curl localhost:18332/rest/getutxos/checkmempool/b2cdfd7b89def827ff8af7cd9bff7627ff72e5e8b0f71210f92ea7a4000c5d75-0.json 2>/dev/null | json_pp
+{
+ "chaintipHash" : "00000000fb01a7f3745a717f8caebee056c484e6e0bfe4a9591c235bb70506fb",
+ "chainHeight" : 325347,
+ "utxos" : [
+ {
+ "scriptPubKey" : {
+ "addresses" : [
+ "mi7as51dvLJsizWnTMurtRmrP8hG2m1XvD"
+ ],
+ "type" : "pubkeyhash",
+ "hex" : "76a9141c7cebb529b86a04c683dfa87be49de35bcf589e88ac",
+ "reqSigs" : 1,
+ "asm" : "OP_DUP OP_HASH160 1c7cebb529b86a04c683dfa87be49de35bcf589e OP_EQUALVERIFY OP_CHECKSIG"
+ },
+ "value" : 8.8687,
+ "height" : 2147483647,
+ "txvers" : 1
+ }
+ ],
+ "bitmap" : "1"
+}
+```
Risks
-------------
-Running a webbrowser on the same node with a REST enabled bitcoind can be a risk. Accessing prepared XSS websites could read out tx/block data of your node by placing links like `<script src="http://127.0.0.1:1234/tx/json/1234567890">` which might break the nodes privacy. \ No newline at end of file
+Running a webbrowser on the same node with a REST enabled bitcoind can be a risk. Accessing prepared XSS websites could read out tx/block data of your node by placing links like `<script src="http://127.0.0.1:8332/rest/tx/1234567890.json">` which might break the nodes privacy.
diff --git a/doc/assets-attribution.md b/doc/assets-attribution.md
index 2cdcc273be..c6da1a4586 100644
--- a/doc/assets-attribution.md
+++ b/doc/assets-attribution.md
@@ -22,6 +22,7 @@ The following is a list of assets used in the bitcoin source and their proper at
src/qt/res/icons/receive.png, src/qt/res/icons/remove.png,
src/qt/res/icons/send.png, src/qt/res/icons/synced.png,
src/qt/res/icons/transaction*.png, src/qt/res/icons/tx_output.png,
+ src/qt/res/icons/warning.png
Jonas Schnelli
-----------------------
@@ -39,9 +40,7 @@ Jonas Schnelli
src/qt/res/icons/connect[0-3].png, src/qt/res/icons/eye_minus.png,
src/qt/res/icons/eye_plus.png, src/qt/res/icons/verify.png,
src/qt/res/icons/tx_inout.png, src/qt/res/icons/tx_input.png,
- src/qt/res/icons/unit_btc.png, src/qt/res/icons/unit_mbtc.png,
- src/qt/res/icons/unit_ubtc.png, src/qt/res/src/verify.svg
- src/qt/res/src/bitcoin.svg, src/qt/res/src/clock*.svg,
- src/qt/res/src/connect*.svg, src/qt/res/src/mine.svg,
- src/qt/res/src/qt.svg, src/qt/res/src/tx*.svg,
+ src/qt/res/src/verify.svg, src/qt/res/src/bitcoin.svg,
+ src/qt/res/src/clock*.svg, src/qt/res/src/connect*.svg,
+ src/qt/res/src/mine.svg, src/qt/res/src/qt.svg, src/qt/res/src/tx*.svg,
src/qt/res/src/verify.svg,
diff --git a/doc/bips.md b/doc/bips.md
new file mode 100644
index 0000000000..90e98ed419
--- /dev/null
+++ b/doc/bips.md
@@ -0,0 +1,18 @@
+BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.10.0**):
+
+* [`BIP 11`](https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki): Multisig outputs are standard since **v0.6.0** ([PR #669](https://github.com/bitcoin/bitcoin/pull/669)).
+* [`BIP 13`](https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki): The address format for P2SH addresses has been implemented since **v0.6.0** ([PR #669](https://github.com/bitcoin/bitcoin/pull/669)).
+* [`BIP 14`](https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki): The subversion string is being used as User Agent since **v0.6.0** ([PR #669](https://github.com/bitcoin/bitcoin/pull/669)).
+* [`BIP 16`](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki): The pay-to-script-hash evaluation rules have been implemented since **v0.6.0**, and took effect on *April 1st 2012* ([PR #748](https://github.com/bitcoin/bitcoin/pull/748)).
+* [`BIP 21`](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki): The URI format for Bitcoin payments has been implemented since **v0.6.0** ([PR #176](https://github.com/bitcoin/bitcoin/pull/176)).
+* [`BIP 22`](https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki): The 'getblocktemplate' (GBT) RPC protocol for mining has been implemented since **v0.7.0** ([PR #936](https://github.com/bitcoin/bitcoin/pull/936)).
+* [`BIP 23`](https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki): Some extensions to GBT have been implemented since **v0.10.0rc1**, including longpolling and block proposals ([PR #1816](https://github.com/bitcoin/bitcoin/pull/1816)).
+* [`BIP 30`](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki): The evaluation rules to forbid creating new transactions with the same txid as previous not-fully-spent transactions were implemented since **v0.6.0**, and the rule took effect on *March 15th 2012* ([PR #915](https://github.com/bitcoin/bitcoin/pull/915)).
+* [`BIP 31`](https://github.com/bitcoin/bips/blob/master/bip-0031.mediawiki): The 'pong' protocol message (and the protocol version bump to 60001) has been implemented since **v0.6.1** ([PR #1081](https://github.com/bitcoin/bitcoin/pull/1081)).
+* [`BIP 34`](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki): The rule that requires blocks to contain their height (number) in the coinbase input, and the introduction of version 2 blocks has been implemented since **v0.7.0**. The rule took effect for version 2 blocks as of *block 224413* (March 5th 2013), and version 1 blocks are no longer allowed since *block 227931* (March 25th 2013) ([PR #1526](https://github.com/bitcoin/bitcoin/pull/1526)).
+* [`BIP 35`](https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki): The 'mempool' protocol message (and the protocol version bump to 60002) has been implemented since **v0.7.0** ([PR #1641](https://github.com/bitcoin/bitcoin/pull/1641)).
+* [`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 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)).
diff --git a/doc/bootstrap.md b/doc/bootstrap.md
deleted file mode 100644
index b84fd24b11..0000000000
--- a/doc/bootstrap.md
+++ /dev/null
@@ -1,56 +0,0 @@
-### Bootstrap the Blockchain Synchronization
-
-Normally the Bitcoin client will download the transaction and network information, called the blockchain, from the network by syncing with the other clients. This process can take quite some time as the [Bitcoin blockchain](https://blockchain.info/charts/blocks-size) is growing bigger and bigger for each day. Luckily there is a safe and fast way to speed up this process. We'll show you how to bootstrap your blockchain to bring your client up to speed in just a few simple steps.
-
-### Requirements
-
-- A fresh install of the Bitcoin client software.
-
-### Download the blockchain via BitTorrent
-
-Jeff Garzik, Bitcoin Core developer, offers an [torrent file](https://bitcointalk.org/index.php?topic=145386.0) for bootstrapping purposes that is updated often. BitTorrent is a protocol that speeds up the downloading of large files by using the other clients in the network. Examples of free and safe open source clients are [Deluge](http://deluge-torrent.org/) or [qBittorrent](http://www.qbittorrent.org/). A guide to installing and configuring the torrent clients can be found [here](http://dev.deluge-torrent.org/wiki/UserGuide) for Deluge and [here](http://qbforums.shiki.hu/) for qBittorrent. A further in-depth tutorial on BitTorrent can be found [here](http://www.howtogeek.com/howto/31846/bittorrent-for-beginners-how-get-started-downloading-torrents/).
-
-With the client installed we'll proceed to download the blockchain torrent file. Use the following magnet link:
-
- magnet:?xt=urn:btih:2d4e6c1f96c5d5fb260dff92aea4e600227f1aea&dn=bootstrap.dat&tr=udp://tracker.openbittorrent.com:80&tr=udp://tracker.publicbt.com:80&tr=udp://tracker.ccc.de:80&tr=udp://tracker.istole.it:80
-
- or go to [Jeff Garzik's topic](https://bitcointalk.org/index.php?topic=145386.0) for a signed magnet link. Alternatively you can use the [.torrent file](http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/bootstrap.dat.torrent/download) found on SourceForge.
-
-![Fig1](img/bootstrap1.png)
-
-The download page should look like this, with a countdown to the download. If it does not work click the direct download link.
-
-The torrent client installed will recognize the download of the torrent file. Save the bootstrap.dat file to the folder you use for downloads. The image below shows the torrent download in qBittorrent, with current speed and ETA highlighted.
-
-![Fig2](img/bootstrap2.png)
-
-### Importing the blockchain
-Exit the Bitcoin client software if you have it running. Be sure not to have an actively used wallet in use. We are going to copy the download of the blockchain to the Bitcoin client data directory. You should run the client software at least once so it can generate the data directory. Copy the downloaded bootstrap.dat file into the Bitcoin data folder.
-
-**For Windows users:**
-Open explorer, and type into the address bar:
-
- %APPDATA%\Bitcoin
-
-This will open up the data folder. It should look like the image below. Copy over the bootstrap.dat from your download folder to this directory.
-![Fig4](img/bootstrap4.png)
-
-**For OSX users:**
-Open Finder by pressing Press [shift] + [cmd] + [g] and enter:
-
- ~/Library/Application Support/Bitcoin/
-
-**For Linux users:**
-The directory is hidden in your User folder. Go to:
-
- ~/.bitcoin/
-
-### Importing the blockchain
-Now start the Bitcoin client software. It should show "Importing blocks from disk" like the image below.
-![Fig5](img/bootstrap5.png)
-
-Wait until the import finishes. The client will download the last days not covered by the import. Congratulations you have successfully imported the blockchain!
-
-### Is this safe?
-
-Yes, the above method is safe. The download contains only raw blockchain data and the client verifies this on import. Do not download the blockchain from unofficial sources, especially if they provide `*.rev` and `*.sst` files. These files are not verified and can contain malicious edits.
diff --git a/doc/build-osx.md b/doc/build-osx.md
index c41820f2b1..dc319dd1c4 100644
--- a/doc/build-osx.md
+++ b/doc/build-osx.md
@@ -1,6 +1,6 @@
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 OSX.
Notes
-----
@@ -21,12 +21,6 @@ Xcode 4.3 or later, you'll need to install its command line tools. This can
be done in `Xcode > Preferences > Downloads > Components` and generally must
be re-done or updated every time Xcode is updated.
-There's also an assumption that you already have `git` installed. If
-not, it's the path of least resistance to install [Github for Mac](https://mac.github.com/)
-(OS X 10.7+) or
-[Git for OS X](https://code.google.com/p/git-osx-installer/). It is also
-available via Homebrew.
-
You will also need to install [Homebrew](http://brew.sh) in order to install library
dependencies.
@@ -38,30 +32,9 @@ Instructions: Homebrew
#### Install dependencies using Homebrew
- brew install autoconf automake libtool boost miniupnpc openssl pkg-config protobuf qt
-
-#### Installing berkeley-db4 using Homebrew
-
-The homebrew package for berkeley-db4 has been broken for some time. It will install without Java though.
-
-Running this command takes you into brew's interactive mode, which allows you to configure, make, and install by hand:
-```
-$ brew install https://raw.github.com/mxcl/homebrew/master/Library/Formula/berkeley-db4.rb -–without-java
-```
-
-The rest of these commands are run inside brew interactive mode:
-```
-/private/tmp/berkeley-db4-UGpd0O/db-4.8.30 $ cd ..
-/private/tmp/berkeley-db4-UGpd0O $ db-4.8.30/dist/configure --prefix=/usr/local/Cellar/berkeley-db4/4.8.30 --mandir=/usr/local/Cellar/berkeley-db4/4.8.30/share/man --enable-cxx
-/private/tmp/berkeley-db4-UGpd0O $ make
-/private/tmp/berkeley-db4-UGpd0O $ make install
-/private/tmp/berkeley-db4-UGpd0O $ exit
-```
-
-After exiting, you'll get a warning that the install is keg-only, which means it wasn't symlinked to `/usr/local`. You don't need it to link it to build bitcoin, but if you want to, here's how:
-
- $ brew link --force berkeley-db4
+ brew install autoconf automake berkeley-db4 libtool boost miniupnpc openssl pkg-config protobuf qt5
+NOTE: Building with Qt4 is still supported, however, could result in a broken UI. As such, building with Qt5 is recommended.
### Building `bitcoind`
@@ -73,7 +46,7 @@ After exiting, you'll get a warning that the install is keg-only, which means it
2. Build bitcoind:
./autogen.sh
- ./configure
+ ./configure --with-gui=qt5
make
3. It is also a good idea to build and run the unit tests:
@@ -115,7 +88,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 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-Qt.app
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 8ddee3b757..f70bf7f1fe 100644
--- a/doc/build-unix.md
+++ b/doc/build-unix.md
@@ -159,7 +159,7 @@ tar -xzvf db-4.8.30.NC.tar.gz
# Build the library and install to our prefix
cd db-4.8.30.NC/build_unix/
-# Note: Do a static build so that it can be embedded into the exectuable, instead of having to find a .so at runtime
+# 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
make install
@@ -195,12 +195,12 @@ Hardening enables the following features:
* Position Independent Executable
Build position independent code to take advantage of Address Space Layout Randomization
- offered by some kernels. An attacker who is able to cause execution of code at an arbitrary
- memory location is thwarted if he doesn't know where anything useful is located.
+ offered by some kernels. Attackers who can cause execution of code at an arbitrary memory
+ location are thwarted if they don't know where anything useful is located.
The stack and heap are randomly located by default but this allows the code section to be
randomly located as well.
- On an Amd64 processor where a library was not compiled with -fPIC, this will cause an error
+ On an AMD64 processor where a library was not compiled with -fPIC, this will cause an error
such as: "relocation R_X86_64_32 against `......' can not be used when making a shared object;"
To test that you have built PIE executable, install scanelf, part of paxutils, and use:
diff --git a/doc/coding.md b/doc/developer-notes.md
index 43294dbe4c..7d3d78adfc 100644
--- a/doc/coding.md
+++ b/doc/developer-notes.md
@@ -53,7 +53,7 @@ bool function(int arg1, const char *arg2)
```
A complete list of `@xxx` commands can be found at http://www.stack.nl/~dimitri/doxygen/manual/commands.html.
As Doxygen recognizes the comments by the delimiters (`/**` and `*/` in this case), you don't
-*need* to provide any commands for a comment to be valid, just a description text is fine.
+*need* to provide any commands for a comment to be valid; just a description text is fine.
To describe a class use the same construct above the class definition:
```c++
@@ -89,6 +89,41 @@ Not OK (used plenty in the current source, but not picked up):
A full list of comment syntaxes picked up by doxygen can be found at http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html,
but if possible use one of the above styles.
+Development tips and tricks
+---------------------------
+
+**compiling for debugging**
+
+Run configure with the --enable-debug option, then make. Or run configure with
+CXXFLAGS="-g -ggdb -O0" or whatever debug flags you need.
+
+**debug.log**
+
+If the code is behaving strangely, take a look in the debug.log file in the data directory;
+error and debugging messages are written there.
+
+The -debug=... command-line option controls debugging; running with just -debug or -debug=1 will turn
+on all categories (and give you a very large debug.log file).
+
+The Qt code routes qDebug() output to debug.log under category "qt": run with -debug=qt
+to see it.
+
+**testnet and regtest modes**
+
+Run with the -testnet option to run with "play bitcoins" on the test network, if you
+are testing multi-machine code that needs to operate across the internet.
+
+If you are testing something that can run on one machine, run with the -regtest option.
+In regression test mode, blocks can be created on-demand; see qa/rpc-tests/ for tests
+that run in -regtest mode.
+
+**DEBUG_LOCKORDER**
+
+Bitcoin Core is a multithreaded application, and deadlocks or other multithreading bugs
+can be very difficult to track down. Compiling with -DDEBUG_LOCKORDER (configure
+CXXFLAGS="-DDEBUG_LOCKORDER -g") inserts run-time checks to keep track of which locks
+are held, and adds warnings to the debug.log file if inconsistencies are detected.
+
Locking/mutex usage notes
-------------------------
@@ -136,3 +171,16 @@ Threads
- BitcoinMiner : Generates bitcoins (if wallet is enabled).
- Shutdown : Does an orderly shutdown of everything.
+
+Pull Request Terminology
+------------------------
+
+Concept ACK - Agree with the idea and overall direction, but have neither reviewed nor tested the code changes.
+
+utACK (untested ACK) - Reviewed and agree with the code changes but haven't actually tested them.
+
+Tested ACK - Reviewed the code changes and have verified the functionality or bug fix.
+
+ACK - A loose ACK can be confusing. It's best to avoid them unless it's a documentation/comment only change in which case there is nothing to test/verify; therefore the tested/untested distinction is not there.
+
+NACK - Disagree with the code changes/concept. Should be accompanied by an explanation.
diff --git a/doc/dnsseed-policy.md b/doc/dnsseed-policy.md
index 66a1757ac5..814ae3876a 100644
--- a/doc/dnsseed-policy.md
+++ b/doc/dnsseed-policy.md
@@ -7,19 +7,17 @@ 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
-document establishes some basic expectations for the expectations
-for the operation of dnsseeds.
+seeds and may be more exposed. In light of this exposure, this
+document establishes some basic expectations for operating dnsseeds.
-0. A DNS seed operating organization or person is expected
-to follow good host security practices and maintain control of
-their serving infrastructure and not sell or transfer control of their
-DNS seed. Any hosting services contracted by the operator are
-equally expected to uphold these expectations.
+0. A DNS seed operating organization or person is expected to follow good
+host security practices, maintain control of applicable infrastructure,
+and not sell or transfer control of the DNS seed. Any hosting services
+contracted by the operator are equally expected to uphold these expectations.
1. The DNS seed results must consist exclusively of fairly selected and
functioning Bitcoin nodes from the public network to the best of the
-operators understanding and capability.
+operator's understanding and capability.
2. For the avoidance of doubt, the results may be randomized but must not
single-out any group of hosts to receive different results unless due to an
@@ -29,7 +27,7 @@ urgent technical necessity and disclosed.
4. Any logging of DNS queries should be only that which is necessary
for the operation of the service or urgent health of the Bitcoin
-network and must not be retained longer than necessary or disclosed
+network and must not be retained longer than necessary nor disclosed
to any third party.
5. Information gathered as a result of the operators node-spidering
@@ -45,7 +43,8 @@ related to the DNS seed operation.
If these expectations cannot be satisfied the operator should
discontinue providing services and contact the active Bitcoin
-Core development team as well as posting on bitcoin-development.
+Core development team as well as posting on
+[bitcoin-dev](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev).
Behavior outside of these expectations may be reasonable in some
situations but should be discussed in public in advance.
diff --git a/doc/gitian-building.md b/doc/gitian-building.md
index defddedc6e..1fa5b5f989 100644
--- a/doc/gitian-building.md
+++ b/doc/gitian-building.md
@@ -24,7 +24,7 @@ Table of Contents
- [Connecting to the VM](#connecting-to-the-vm)
- [Setting up Debian for gitian building](#setting-up-debian-for-gitian-building)
- [Installing gitian](#installing-gitian)
-- [Setting up gitian images](#setting-up-gitian-images)
+- [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)
@@ -74,20 +74,20 @@ In the VirtualBox GUI click "Create" and choose the following parameters in the
- Disk size: at least 40GB; as low as 20GB *may* be possible, but better to err on the safe side
- Push the `Create` button
-Get the [Debian 7.4 net installer](http://ftp.at.debian.org/debian-jigdo/current/amd64/iso-cd/debian-7.4.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 7.8 net installer](http://cdimage.debian.org/debian-cd/7.8.0/amd64/iso-cd/debian-7.8.0-amd64-netinst.iso) (a more recent minor version should also work, see also [Debian Network installation](https://www.debian.org/CD/netinst/)).
This DVD image can be validated using a SHA256 hashing tool, for example on
Unixy OSes by entering the following in a terminal:
- echo "b712a141bc60269db217d3b3e456179bd6b181645f90e4aac9c42ed63de492e9 debian-7.4.0-amd64-netinst.iso" | sha256sum -c
+ echo "e39c36d6adc0fd86c6edb0e03e22919086c883b37ca194d063b8e3e8f6ff6a3a debian-7.8.0-amd64-netinst.iso" | sha256sum -c
# (must return OK)
After creating the VM, we need to configure it.
-- Click the `Settings` button, then go to the `Network` tab. Adapter 1 should be attacked to `NAT`.
+- Click the `Settings` button, then go to the `Network` tab. Adapter 1 should be attached to `NAT`.
![](gitian-building/network_settings.png)
-- Click `Advanced`, then `Port Forwarding`. We want to set up a port through where we can reach the VM to get files in and out.
+- Click `Advanced`, then `Port Forwarding`. We want to set up a port through which we can reach the VM to get files in and out.
- Create a new rule by clicking the plus icon.
![](gitian-building/port_forwarding_rules.png)
@@ -109,9 +109,9 @@ Then start the VM. On the first launch you will be asked for a CD or DVD image.
Installing Debian
------------------
-In this section it will be explained how to install Debian on the newly created VM.
+This section will explain how to install Debian on the newly created VM.
-- Choose the non-graphical installer. We do not need the graphical environment, it will only increase installation time and disk usage.
+- Choose the non-graphical installer. We do not need the graphical environment; it will only increase installation time and disk usage.
![](gitian-building/debian_install_1_boot_menu.png)
@@ -144,7 +144,7 @@ and proceed, just press `Enter`. To select a different button, press `Tab`.
![](gitian-building/debian_install_9_user_password.png)
-- The installer will set up the clock using a time server, this process should be automatic
+- The installer will set up the clock using a time server; this process should be automatic
- Set up the clock: choose a time zone (depends on the locale settings that you picked earlier; specifics don't matter)
![](gitian-building/debian_install_10_configure_clock.png)
@@ -277,24 +277,21 @@ 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 and then checkout the bitcoin version that you want to build.
+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
-cd bitcoin
-git checkout v${VERSION}
-cd ..
```
-Setting up gitian images
+Setting up the gitian image
-------------------------
-Gitian needs virtual images of the operating system to build in.
-Currently this is Ubuntu Precise for x86_64.
-These images will be copied and used every time that a build is started to
+Gitian needs a virtual image of the operating system to build in.
+Currently this is Ubuntu Precise x86_64.
+This image will be copied and used every time that a build is started to
make sure that the build is deterministic.
-Creating the images will take a while, but only has to be done once.
+Creating the image will take a while, but only has to be done once.
Execute the following as user `debian`:
@@ -303,7 +300,7 @@ cd gitian-builder
bin/make-base-vm --lxc --arch amd64 --suite precise
```
-There will be a lot of warnings printed during build of the images. These can be ignored.
+There will be a lot of warnings printed during build of the image. These can be ignored.
**Note**: When sudo asks for a password, enter the password for the user *debian* not for *root*.
@@ -322,13 +319,14 @@ To build Bitcoin (for Linux, OSX and Windows) just follow the steps under 'perfo
gitian builds' in [doc/release-process.md](release-process.md) in the bitcoin repository.
This may take a long time as it also builds the dependencies needed for each descriptor.
-These dependencies will be cached after a successful build to avoid rebuilding them when possible.
+These dependencies will be cached after a successful build to avoid rebuilding them where possible.
At any time you can check the package installation and build progress with
```bash
tail -f var/install.log
tail -f var/build.log
+```
Output from `gbuild` will look something like
@@ -373,7 +371,7 @@ COMMIT=2014_03_windows_unicode_path
Signing externally
-------------------
-If you want to do the PGP signing on another device that's also possible; just define `SIGNER` as mentioned
+If you want to do the PGP signing on another device, that's also possible; just define `SIGNER` as mentioned
and follow the steps in the build process as normal.
gpg: skipped "laanwj": secret key not available
@@ -382,9 +380,9 @@ When you execute `gsign` you will get an error from GPG, which can be ignored. C
in `gitian.sigs` to your signing machine and do
```bash
- gpg --detach-sign ${VERSION}-linux/${SIGNER}/bitcoin-build.assert
- gpg --detach-sign ${VERSION}-win/${SIGNER}/bitcoin-build.assert
- gpg --detach-sign ${VERSION}-osx/${SIGNER}/bitcoin-build.assert
+ gpg --detach-sign ${VERSION}-linux/${SIGNER}/bitcoin-linux-build.assert
+ gpg --detach-sign ${VERSION}-win/${SIGNER}/bitcoin-win-build.assert
+ gpg --detach-sign ${VERSION}-osx-unsigned/${SIGNER}/bitcoin-osx-build.assert
```
This will create the `.sig` files that can be committed together with the `.assert` files to assert your
@@ -395,4 +393,4 @@ Uploading signatures
After building and signing you can push your signatures (both the `.assert` and `.assert.sig` files) to the
[bitcoin/gitian.sigs](https://github.com/bitcoin/gitian.sigs/) repository, or if that's not possible create a pull
-request. You can also mail the files to me (laanwj@gmail.com) and I'll commit them.
+request. You can also mail the files to Wladimir (laanwj@gmail.com) and he will commit them.
diff --git a/doc/img/bootstrap1.png b/doc/img/bootstrap1.png
deleted file mode 100644
index 075930791b..0000000000
--- a/doc/img/bootstrap1.png
+++ /dev/null
Binary files differ
diff --git a/doc/img/bootstrap2.png b/doc/img/bootstrap2.png
deleted file mode 100644
index 6461f81810..0000000000
--- a/doc/img/bootstrap2.png
+++ /dev/null
Binary files differ
diff --git a/doc/img/bootstrap4.png b/doc/img/bootstrap4.png
deleted file mode 100644
index ad69737922..0000000000
--- a/doc/img/bootstrap4.png
+++ /dev/null
Binary files differ
diff --git a/doc/img/bootstrap5.png b/doc/img/bootstrap5.png
deleted file mode 100644
index d8d9baaf37..0000000000
--- a/doc/img/bootstrap5.png
+++ /dev/null
Binary files differ
diff --git a/doc/init.md b/doc/init.md
index 1f0559d806..1f206a6c02 100644
--- a/doc/init.md
+++ b/doc/init.md
@@ -8,6 +8,7 @@ can be found in the contrib/init folder.
contrib/init/bitcoind.openrc: OpenRC compatible SysV style init script
contrib/init/bitcoind.openrcconf: OpenRC conf.d file
contrib/init/bitcoind.conf: Upstart service configuration file
+ contrib/init/bitcoind.init: CentOS compatible SysV style init script
1. Service User
---------------------------------
@@ -49,6 +50,7 @@ Configuration file: /etc/bitcoin/bitcoin.conf
Data directory: /var/lib/bitcoind
PID file: /var/run/bitcoind/bitcoind.pid (OpenRC and Upstart)
/var/lib/bitcoind/bitcoind.pid (systemd)
+Lock file: /var/lock/subsys/bitcoind (CentOS)
The configuration file, PID directory (if applicable) and data directory
should all be owned by the bitcoin user and group. It is advised for security
@@ -61,7 +63,7 @@ can then be controlled by group membership.
4a) systemd
-Installing this .service file consists on just copying it to
+Installing this .service file consists of just copying it to
/usr/lib/systemd/system directory, followed by the command
"systemctl daemon-reload" in order to update running systemd configuration.
@@ -81,7 +83,15 @@ Drop bitcoind.conf in /etc/init. Test by running "service bitcoind start"
it will automatically start on reboot.
NOTE: This script is incompatible with CentOS 5 and Amazon Linux 2014 as they
-use old versions of Upstart and do not supply the start-stop-daemon uitility.
+use old versions of Upstart and do not supply the start-stop-daemon utility.
+
+4d) CentOS
+
+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
+/etc/sysconfig/bitcoind. You can also use the DAEMONOPTS environment variable here.
5. Auto-respawn
-----------------------------------
diff --git a/doc/release-notes.md b/doc/release-notes.md
index 1cb517e5c7..6bb8587d78 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -1,3 +1,39 @@
(note: this is a temporary file, to be added-to by anybody, and moved to
release-notes at release time)
+Notable changes
+===============
+
+Example header
+----------------------
+
+Example content.
+
+0.12.0 Change log
+=================
+
+Detailed release notes follow. This overview includes changes that affect
+behavior, not code moves, refactors and string updates. For convenience in locating
+the code changes and accompanying discussion, both the pull request and
+git merge commit are mentioned.
+
+### RPC and REST
+
+### Configuration and command-line options
+
+### Block and transaction handling
+
+### P2P protocol and network code
+
+### Validation
+
+### Build system
+
+### Wallet
+
+### GUI
+
+### Tests
+
+### Miscellaneous
+
diff --git a/doc/release-notes/release-notes-0.10.0.md b/doc/release-notes/release-notes-0.10.0.md
new file mode 100644
index 0000000000..986b8832ec
--- /dev/null
+++ b/doc/release-notes/release-notes-0.10.0.md
@@ -0,0 +1,762 @@
+Bitcoin Core version 0.10.0 is now available from:
+
+ https://bitcoin.org/bin/0.10.0/
+
+This is a new major version release, bringing both new features and
+bug fixes.
+
+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).
+
+Downgrading warning
+---------------------
+
+Because release 0.10.0 makes use of headers-first synchronization and parallel
+block download (see further), the block files and databases are not
+backwards-compatible with older 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
+===============
+
+Faster synchronization
+----------------------
+
+Bitcoin Core now uses 'headers-first synchronization'. This means that we first
+ask peers for block headers (a total of 27 megabytes, as of December 2014) and
+validate those. In a second stage, when the headers have been discovered, we
+download the blocks. However, as we already know about the whole chain in
+advance, the blocks can be downloaded in parallel from all available peers.
+
+In practice, this means a much faster and more robust synchronization. On
+recent hardware with a decent network link, it can be as little as 3 hours
+for an initial full synchronization. You may notice a slower progress in the
+very first few minutes, when headers are still being fetched and verified, but
+it should gain speed afterwards.
+
+A few RPCs were added/updated as a result of this:
+- `getblockchaininfo` now returns the number of validated headers in addition to
+the number of validated blocks.
+- `getpeerinfo` lists both the number of blocks and headers we know we have in
+common with each peer. While synchronizing, the heights of the blocks that we
+have requested from peers (but haven't received yet) are also listed as
+'inflight'.
+- A new RPC `getchaintips` lists all known branches of the block chain,
+including those we only have headers for.
+
+Transaction fee changes
+-----------------------
+
+This release automatically estimates how high a transaction fee (or how
+high a priority) transactions require to be confirmed quickly. The default
+settings will create transactions that confirm quickly; see the new
+'txconfirmtarget' setting to control the tradeoff between fees and
+confirmation times. Fees are added by default unless the 'sendfreetransactions'
+setting is enabled.
+
+Prior releases used hard-coded fees (and priorities), and would
+sometimes create transactions that took a very long time to confirm.
+
+Statistics used to estimate fees and priorities are saved in the
+data directory in the `fee_estimates.dat` file just before
+program shutdown, and are read in at startup.
+
+New command line options for transaction fee changes:
+- `-txconfirmtarget=n` : create transactions that have enough fees (or priority)
+so they are likely to begin confirmation within n blocks (default: 1). This setting
+is over-ridden by the -paytxfee option.
+- `-sendfreetransactions` : Send transactions as zero-fee transactions if possible
+(default: 0)
+
+New RPC commands for fee estimation:
+- `estimatefee nblocks` : Returns approximate fee-per-1,000-bytes needed for
+a transaction to begin confirmation within nblocks. Returns -1 if not enough
+transactions have been observed to compute a good estimate.
+- `estimatepriority nblocks` : Returns approximate priority needed for
+a zero-fee transaction to begin confirmation within nblocks. Returns -1 if not
+enough free transactions have been observed to compute a good
+estimate.
+
+RPC access control changes
+--------------------------
+
+Subnet matching for the purpose of access control is now done
+by matching the binary network address, instead of with string wildcard matching.
+For the user this means that `-rpcallowip` takes a subnet specification, which can be
+
+- a single IP address (e.g. `1.2.3.4` or `fe80::0012:3456:789a:bcde`)
+- a network/CIDR (e.g. `1.2.3.0/24` or `fe80::0000/64`)
+- a network/netmask (e.g. `1.2.3.4/255.255.255.0` or `fe80::0012:3456:789a:bcde/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff`)
+
+An arbitrary number of `-rpcallow` arguments can be given. An incoming connection will be accepted if its origin address
+matches one of them.
+
+For example:
+
+| 0.9.x and before | 0.10.x |
+|--------------------------------------------|---------------------------------------|
+| `-rpcallowip=192.168.1.1` | `-rpcallowip=192.168.1.1` (unchanged) |
+| `-rpcallowip=192.168.1.*` | `-rpcallowip=192.168.1.0/24` |
+| `-rpcallowip=192.168.*` | `-rpcallowip=192.168.0.0/16` |
+| `-rpcallowip=*` (dangerous!) | `-rpcallowip=::/0` (still dangerous!) |
+
+Using wildcards will result in the rule being rejected with the following error in debug.log:
+
+ Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24).
+
+
+REST interface
+--------------
+
+A new HTTP API is exposed when running with the `-rest` flag, which allows
+unauthenticated access to public node data.
+
+It is served on the same port as RPC, but does not need a password, and uses
+plain HTTP instead of JSON-RPC.
+
+Assuming a local RPC server running on port 8332, it is possible to request:
+- Blocks: http://localhost:8332/rest/block/*HASH*.*EXT*
+- Blocks without transactions: http://localhost:8332/rest/block/notxdetails/*HASH*.*EXT*
+- Transactions (requires `-txindex`): http://localhost:8332/rest/tx/*HASH*.*EXT*
+
+In every case, *EXT* can be `bin` (for raw binary data), `hex` (for hex-encoded
+binary) or `json`.
+
+For more details, see the `doc/REST-interface.md` document in the repository.
+
+RPC Server "Warm-Up" Mode
+-------------------------
+
+The RPC server is started earlier now, before most of the expensive
+intialisations like loading the block index. It is available now almost
+immediately after starting the process. However, until all initialisations
+are done, it always returns an immediate error with code -28 to all calls.
+
+This new behaviour can be useful for clients to know that a server is already
+started and will be available soon (for instance, so that they do not
+have to start it themselves).
+
+Improved signing security
+-------------------------
+
+For 0.10 the security of signing against unusual attacks has been
+improved by making the signatures constant time and deterministic.
+
+This change is a result of switching signing to use libsecp256k1
+instead of OpenSSL. Libsecp256k1 is a cryptographic library
+optimized for the curve Bitcoin uses which was created by Bitcoin
+Core developer Pieter Wuille.
+
+There exist attacks[1] against most ECC implementations where an
+attacker on shared virtual machine hardware could extract a private
+key if they could cause a target to sign using the same key hundreds
+of times. While using shared hosts and reusing keys are inadvisable
+for other reasons, it's a better practice to avoid the exposure.
+
+OpenSSL has code in their source repository for derandomization
+and reduction in timing leaks that we've eagerly wanted to use for a
+long time, but this functionality has still not made its
+way into a released version of OpenSSL. Libsecp256k1 achieves
+significantly stronger protection: As far as we're aware this is
+the only deployed implementation of constant time signing for
+the curve Bitcoin uses and we have reason to believe that
+libsecp256k1 is better tested and more thoroughly reviewed
+than the implementation in OpenSSL.
+
+[1] https://eprint.iacr.org/2014/161.pdf
+
+Watch-only wallet support
+-------------------------
+
+The wallet can now track transactions to and from wallets for which you know
+all addresses (or scripts), even without the private keys.
+
+This can be used to track payments without needing the private keys online on a
+possibly vulnerable system. In addition, it can help for (manual) construction
+of multisig transactions where you are only one of the signers.
+
+One new RPC, `importaddress`, is added which functions similarly to
+`importprivkey`, but instead takes an address or script (in hexadecimal) as
+argument. After using it, outputs credited to this address or script are
+considered to be received, and transactions consuming these outputs will be
+considered to be sent.
+
+The following RPCs have optional support for watch-only:
+`getbalance`, `listreceivedbyaddress`, `listreceivedbyaccount`,
+`listtransactions`, `listaccounts`, `listsinceblock`, `gettransaction`. See the
+RPC documentation for those methods for more information.
+
+Compared to using `getrawtransaction`, this mechanism does not require
+`-txindex`, scales better, integrates better with the wallet, and is compatible
+with future block chain pruning functionality. It does mean that all relevant
+addresses need to added to the wallet before the payment, though.
+
+Consensus library
+-----------------
+
+Starting from 0.10.0, the Bitcoin Core distribution includes a consensus library.
+
+The purpose of this library is to make the verification functionality that is
+critical to Bitcoin's consensus available to other applications, e.g. to language
+bindings such as [python-bitcoinlib](https://pypi.python.org/pypi/python-bitcoinlib) or
+alternative node implementations.
+
+This library is called `libbitcoinconsensus.so` (or, `.dll` for Windows).
+Its interface is defined in the C header [bitcoinconsensus.h](https://github.com/bitcoin/bitcoin/blob/0.10/src/script/bitcoinconsensus.h).
+
+In its initial version the API includes two functions:
+
+- `bitcoinconsensus_verify_script` verifies a script. It returns whether the indicated input of the provided serialized transaction
+correctly spends the passed scriptPubKey under additional constraints indicated by flags
+- `bitcoinconsensus_version` returns the API version, currently at an experimental `0`
+
+The functionality is planned to be extended to e.g. UTXO management in upcoming releases, but the interface
+for existing methods should remain stable.
+
+Standard script rules relaxed for P2SH addresses
+------------------------------------------------
+
+The IsStandard() rules have been almost completely removed for P2SH
+redemption scripts, allowing applications to make use of any valid
+script type, such as "n-of-m OR y", hash-locked oracle addresses, etc.
+While the Bitcoin protocol has always supported these types of script,
+actually using them on mainnet has been previously inconvenient as
+standard Bitcoin Core nodes wouldn't relay them to miners, nor would
+most miners include them in blocks they mined.
+
+bitcoin-tx
+----------
+
+It has been observed that many of the RPC functions offered by bitcoind are
+"pure functions", and operate independently of the bitcoind wallet. This
+included many of the RPC "raw transaction" API functions, such as
+createrawtransaction.
+
+bitcoin-tx is a newly introduced command line utility designed to enable easy
+manipulation of bitcoin transactions. A summary of its operation may be
+obtained via "bitcoin-tx --help" Transactions may be created or signed in a
+manner similar to the RPC raw tx API. Transactions may be updated, deleting
+inputs or outputs, or appending new inputs and outputs. Custom scripts may be
+easily composed using a simple text notation, borrowed from the bitcoin test
+suite.
+
+This tool may be used for experimenting with new transaction types, signing
+multi-party transactions, and many other uses. Long term, the goal is to
+deprecate and remove "pure function" RPC API calls, as those do not require a
+server round-trip to execute.
+
+Other utilities "bitcoin-key" and "bitcoin-script" have been proposed, making
+key and script operations easily accessible via command line.
+
+Mining and relay policy enhancements
+------------------------------------
+
+Bitcoin Core's block templates are now for version 3 blocks only, and any mining
+software relying on its `getblocktemplate` must be updated in parallel to use
+libblkmaker either version 0.4.2 or any version from 0.5.1 onward.
+If you are solo mining, this will affect you the moment you upgrade Bitcoin
+Core, which must be done prior to BIP66 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 BIP66
+achieving its 951/1001 status.
+
+The `prioritisetransaction` RPC method has been added to enable miners to
+manipulate the priority of transactions on an individual basis.
+
+Bitcoin Core now supports BIP 22 long polling, so mining software can be
+notified immediately of new templates rather than having to poll periodically.
+
+Support for BIP 23 block proposals is now available in Bitcoin Core's
+`getblocktemplate` method. This enables miners to check the basic validity of
+their next block before expending work on it, reducing risks of accidental
+hardforks or mining invalid blocks.
+
+Two new options to control mining policy:
+- `-datacarrier=0/1` : Relay and mine "data carrier" (OP_RETURN) transactions
+if this is 1.
+- `-datacarriersize=n` : Maximum size, in bytes, we consider acceptable for
+"data carrier" outputs.
+
+The relay policy has changed to more properly implement the desired behavior of not
+relaying free (or very low fee) transactions unless they have a priority above the
+AllowFreeThreshold(), in which case they are relayed subject to the rate limiter.
+
+BIP 66: strict DER encoding for signatures
+------------------------------------------
+
+Bitcoin Core 0.10 implements BIP 66, which introduces block version 3, and a new
+consensus rule, which prohibits non-DER signatures. Such transactions have been
+non-standard since Bitcoin v0.8.0 (released in February 2013), but were
+technically still permitted inside blocks.
+
+This change breaks the dependency on OpenSSL's signature parsing, and is
+required if implementations would want to remove all of OpenSSL from the
+consensus code.
+
+The same miner-voting mechanism as in BIP 34 is used: when 751 out of a
+sequence of 1001 blocks have version number 3 or higher, the new consensus
+rule becomes active for those blocks. When 951 out of a sequence of 1001
+blocks have version number 3 or higher, it becomes mandatory for all blocks.
+
+Backward compatibility with current mining software is NOT provided, thus miners
+should read the first paragraph of "Mining and relay policy enhancements" above.
+
+0.10.0 Change log
+=================
+
+Detailed release notes follow. This overview includes changes that affect external
+behavior, not code moves, refactors or string updates.
+
+RPC:
+- `f923c07` Support IPv6 lookup in bitcoin-cli even when IPv6 only bound on localhost
+- `b641c9c` Fix addnode "onetry": Connect with OpenNetworkConnection
+- `171ca77` estimatefee / estimatepriority RPC methods
+- `b750cf1` Remove cli functionality from bitcoind
+- `f6984e8` Add "chain" to getmininginfo, improve help in getblockchaininfo
+- `99ddc6c` Add nLocalServices info to RPC getinfo
+- `cf0c47b` Remove getwork() RPC call
+- `2a72d45` prioritisetransaction <txid> <priority delta> <priority tx fee>
+- `e44fea5` Add an option `-datacarrier` to allow users to disable relaying/mining data carrier transactions
+- `2ec5a3d` Prevent easy RPC memory exhaustion attack
+- `d4640d7` Added argument to getbalance to include watchonly addresses and fixed errors in balance calculation
+- `83f3543` Added argument to listaccounts to include watchonly addresses
+- `952877e` Showing 'involvesWatchonly' property for transactions returned by 'listtransactions' and 'listsinceblock'. It is only appended when the transaction involves a watchonly address
+- `d7d5d23` Added argument to listtransactions and listsinceblock to include watchonly addresses
+- `f87ba3d` added includeWatchonly argument to 'gettransaction' because it affects balance calculation
+- `0fa2f88` added includedWatchonly argument to listreceivedbyaddress/...account
+- `6c37f7f` `getrawchangeaddress`: fail when keypool exhausted and wallet locked
+- `ff6a7af` getblocktemplate: longpolling support
+- `c4a321f` Add peerid to getpeerinfo to allow correlation with the logs
+- `1b4568c` Add vout to ListTransactions output
+- `b33bd7a` Implement "getchaintips" RPC command to monitor blockchain forks
+- `733177e` Remove size limit in RPC client, keep it in server
+- `6b5b7cb` Categorize rpc help overview
+- `6f2c26a` Closely track mempool byte total. Add "getmempoolinfo" RPC
+- `aa82795` Add detailed network info to getnetworkinfo RPC
+- `01094bd` Don't reveal whether password is <20 or >20 characters in RPC
+- `57153d4` rpc: Compute number of confirmations of a block from block height
+- `ff36cbe` getnetworkinfo: export local node's client sub-version string
+- `d14d7de` SanitizeString: allow '(' and ')'
+- `31d6390` Fixed setaccount accepting foreign address
+- `b5ec5fe` update getnetworkinfo help with subversion
+- `ad6e601` RPC additions after headers-first
+- `33dfbf5` rpc: Fix leveldb iterator leak, and flush before `gettxoutsetinfo`
+- `2aa6329` Enable customising node policy for datacarrier data size with a -datacarriersize option
+- `f877aaa` submitblock: Use a temporary CValidationState to determine accurately the outcome of ProcessBlock
+- `e69a587` submitblock: Support for returning specific rejection reasons
+- `af82884` Add "warmup mode" for RPC server
+- `e2655e0` Add unauthenticated HTTP REST interface to public blockchain data
+- `683dc40` Disable SSLv3 (in favor of TLS) for the RPC client and server
+- `44b4c0d` signrawtransaction: validate private key
+- `9765a50` Implement BIP 23 Block Proposal
+- `f9de17e` Add warning comment to getinfo
+
+Command-line options:
+- `ee21912` Use netmasks instead of wildcards for IP address matching
+- `deb3572` Add `-rpcbind` option to allow binding RPC port on a specific interface
+- `96b733e` Add `-version` option to get just the version
+- `1569353` Add `-stopafterblockimport` option
+- `77cbd46` Let -zapwallettxes recover transaction meta data
+- `1c750db` remove -tor compatibility code (only allow -onion)
+- `4aaa017` rework help messages for fee-related options
+- `4278b1d` Clarify error message when invalid -rpcallowip
+- `6b407e4` -datadir is now allowed in config files
+- `bdd5b58` Add option `-sysperms` to disable 077 umask (create new files with system default umask)
+- `cbe39a3` Add "bitcoin-tx" command line utility and supporting modules
+- `dbca89b` Trigger -alertnotify if network is upgrading without you
+- `ad96e7c` Make -reindex cope with out-of-order blocks
+- `16d5194` Skip reindexed blocks individually
+- `ec01243` --tracerpc option for regression tests
+- `f654f00` Change -genproclimit default to 1
+- `3c77714` Make -proxy set all network types, avoiding a connect leak
+- `57be955` Remove -printblock, -printblocktree, and -printblockindex
+- `ad3d208` remove -maxorphanblocks config parameter since it is no longer functional
+
+Block and transaction handling:
+- `7a0e84d` ProcessGetData(): abort if a block file is missing from disk
+- `8c93bf4` LoadBlockIndexDB(): Require block db reindex if any `blk*.dat` files are missing
+- `77339e5` Get rid of the static chainMostWork (optimization)
+- `4e0eed8` Allow ActivateBestChain to release its lock on cs_main
+- `18e7216` Push cs_mains down in ProcessBlock
+- `fa126ef` Avoid undefined behavior using CFlatData in CScript serialization
+- `7f3b4e9` Relax IsStandard rules for pay-to-script-hash transactions
+- `c9a0918` Add a skiplist to the CBlockIndex structure
+- `bc42503` Use unordered_map for CCoinsViewCache with salted hash (optimization)
+- `d4d3fbd` Do not flush the cache after every block outside of IBD (optimization)
+- `ad08d0b` Bugfix: make CCoinsViewMemPool support pruned entries in underlying cache
+- `5734d4d` Only remove actualy failed blocks from setBlockIndexValid
+- `d70bc52` Rework block processing benchmark code
+- `714a3e6` Only keep setBlockIndexValid entries that are possible improvements
+- `ea100c7` Reduce maximum coinscache size during verification (reduce memory usage)
+- `4fad8e6` Reject transactions with excessive numbers of sigops
+- `b0875eb` Allow BatchWrite to destroy its input, reducing copying (optimization)
+- `92bb6f2` Bypass reloading blocks from disk (optimization)
+- `2e28031` Perform CVerifyDB on pcoinsdbview instead of pcoinsTip (reduce memory usage)
+- `ab15b2e` Avoid copying undo data (optimization)
+- `341735e` Headers-first synchronization
+- `afc32c5` Fix rebuild-chainstate feature and improve its performance
+- `e11b2ce` Fix large reorgs
+- `ed6d1a2` Keep information about all block files in memory
+- `a48f2d6` Abstract context-dependent block checking from acceptance
+- `7e615f5` Fixed mempool sync after sending a transaction
+- `51ce901` Improve chainstate/blockindex disk writing policy
+- `a206950` Introduce separate flushing modes
+- `9ec75c5` Add a locking mechanism to IsInitialBlockDownload to ensure it never goes from false to true
+- `868d041` Remove coinbase-dependant transactions during reorg
+- `723d12c` Remove txn which are invalidated by coinbase maturity during reorg
+- `0cb8763` Check against MANDATORY flags prior to accepting to mempool
+- `8446262` Reject headers that build on an invalid parent
+- `008138c` Bugfix: only track UTXO modification after lookup
+
+P2P protocol and network code:
+- `f80cffa` Do not trigger a DoS ban if SCRIPT_VERIFY_NULLDUMMY fails
+- `c30329a` Add testnet DNS seed of Alex Kotenko
+- `45a4baf` Add testnet DNS seed of Andreas Schildbach
+- `f1920e8` Ping automatically every 2 minutes (unconditionally)
+- `806fd19` Allocate receive buffers in on the fly
+- `6ecf3ed` Display unknown commands received
+- `aa81564` Track peers' available blocks
+- `caf6150` Use async name resolving to improve net thread responsiveness
+- `9f4da19` Use pong receive time rather than processing time
+- `0127a9b` remove SOCKS4 support from core and GUI, use SOCKS5
+- `40f5cb8` Send rejects and apply DoS scoring for errors in direct block validation
+- `dc942e6` Introduce whitelisted peers
+- `c994d2e` prevent SOCKET leak in BindListenPort()
+- `a60120e` Add built-in seeds for .onion
+- `60dc8e4` Allow -onlynet=onion to be used
+- `3a56de7` addrman: Do not propagate obviously poor addresses onto the network
+- `6050ab6` netbase: Make SOCKS5 negotiation interruptible
+- `604ee2a` Remove tx from AlreadyAskedFor list once we receive it, not when we process it
+- `efad808` Avoid reject message feedback loops
+- `71697f9` Separate protocol versioning from clientversion
+- `20a5f61` Don't relay alerts to peers before version negotiation
+- `b4ee0bd` Introduce preferred download peers
+- `845c86d` Do not use third party services for IP detection
+- `12a49ca` Limit the number of new addressses to accumulate
+- `35e408f` Regard connection failures as attempt for addrman
+- `a3a7317` Introduce 10 minute block download timeout
+- `3022e7d` Require sufficent priority for relay of free transactions
+- `58fda4d` Update seed IPs, based on bitcoin.sipa.be crawler data
+- `18021d0` Remove bitnodes.io from dnsseeds.
+
+Validation:
+- `6fd7ef2` Also switch the (unused) verification code to low-s instead of even-s
+- `584a358` Do merkle root and txid duplicates check simultaneously
+- `217a5c9` When transaction outputs exceed inputs, show the offending amounts so as to aid debugging
+- `f74fc9b` Print input index when signature validation fails, to aid debugging
+- `6fd59ee` script.h: set_vch() should shift a >32 bit value
+- `d752ba8` Add SCRIPT_VERIFY_SIGPUSHONLY (BIP62 rule 2) (test only)
+- `698c6ab` Add SCRIPT_VERIFY_MINIMALDATA (BIP62 rules 3 and 4) (test only)
+- `ab9edbd` script: create sane error return codes for script validation and remove logging
+- `219a147` script: check ScriptError values in script tests
+- `0391423` Discourage NOPs reserved for soft-fork upgrades
+- `98b135f` Make STRICTENC invalid pubkeys fail the script rather than the opcode
+- `307f7d4` Report script evaluation failures in log and reject messages
+- `ace39db` consensus: guard against openssl's new strict DER checks
+- `12b7c44` Improve robustness of DER recoding code
+- `76ce5c8` fail immediately on an empty signature
+
+Build system:
+- `f25e3ad` Fix build in OS X 10.9
+- `65e8ba4` build: Switch to non-recursive make
+- `460b32d` build: fix broken boost chrono check on some platforms
+- `9ce0774` build: Fix windows configure when using --with-qt-libdir
+- `ea96475` build: Add mention of --disable-wallet to bdb48 error messages
+- `1dec09b` depends: add shared dependency builder
+- `c101c76` build: Add --with-utils (bitcoin-cli and bitcoin-tx, default=yes). Help string consistency tweaks. Target sanity check fix
+- `e432a5f` build: add option for reducing exports (v2)
+- `6134b43` Fixing condition 'sabotaging' MSVC build
+- `af0bd5e` osx: fix signing to make Gatekeeper happy (again)
+- `a7d1f03` build: fix dynamic boost check when --with-boost= is used
+- `d5fd094` build: fix qt test build when libprotobuf is in a non-standard path
+- `2cf5f16` Add libbitcoinconsensus library
+- `914868a` build: add a deterministic dmg signer
+- `2d375fe` depends: bump openssl to 1.0.1k
+- `b7a4ecc` Build: Only check for boost when building code that requires it
+
+Wallet:
+- `b33d1f5` Use fee/priority estimates in wallet CreateTransaction
+- `4b7b1bb` Sanity checks for estimates
+- `c898846` Add support for watch-only addresses
+- `d5087d1` Use script matching rather than destination matching for watch-only
+- `d88af56` Fee fixes
+- `a35b55b` Dont run full check every time we decrypt wallet
+- `3a7c348` Fix make_change to not create half-satoshis
+- `f606bb9` fix a possible memory leak in CWalletDB::Recover
+- `870da77` fix possible memory leaks in CWallet::EncryptWallet
+- `ccca27a` Watch-only fixes
+- `9b1627d` [Wallet] Reduce minTxFee for transaction creation to 1000 satoshis
+- `a53fd41` Deterministic signing
+- `15ad0b5` Apply AreSane() checks to the fees from the network
+- `11855c1` Enforce minRelayTxFee on wallet created tx and add a maxtxfee option
+
+GUI:
+- `c21c74b` osx: Fix missing dock menu with qt5
+- `b90711c` Fix Transaction details shows wrong To:
+- `516053c` Make links in 'About Bitcoin Core' clickable
+- `bdc83e8` Ensure payment request network matches client network
+- `65f78a1` Add GUI view of peer information
+- `06a91d9` VerifyDB progress reporting
+- `fe6bff2` Add BerkeleyDB version info to RPCConsole
+- `b917555` PeerTableModel: Fix potential deadlock. #4296
+- `dff0e3b` Improve rpc console history behavior
+- `95a9383` Remove CENT-fee-rule from coin control completely
+- `56b07d2` Allow setting listen via GUI
+- `d95ba75` Log messages with type>QtDebugMsg as non-debug
+- `8969828` New status bar Unit Display Control and related changes
+- `674c070` seed OpenSSL PNRG with Windows event data
+- `509f926` Payment request parsing on startup now only changes network if a valid network name is specified
+- `acd432b` Prevent balloon-spam after rescan
+- `7007402` Implement SI-style (thin space) thoudands separator
+- `91cce17` Use fixed-point arithmetic in amount spinbox
+- `bdba2dd` Remove an obscure option no-one cares about
+- `bd0aa10` Replace the temporary file hack currently used to change Bitcoin-Qt's dock icon (OS X) with a buffer-based solution
+- `94e1b9e` Re-work overviewpage UI
+- `8bfdc9a` Better looking trayicon
+- `b197bf3` disable tray interactions when client model set to 0
+- `1c5f0af` Add column Watch-only to transactions list
+- `21f139b` Fix tablet crash. closes #4854
+- `e84843c` Broken addresses on command line no longer trigger testnet
+- `a49f11d` Change splash screen to normal window
+- `1f9be98` Disable App Nap on OSX 10.9+
+- `27c3e91` Add proxy to options overridden if necessary
+- `4bd1185` Allow "emergency" shutdown during startup
+- `d52f072` Don't show wallet options in the preferences menu when running with -disablewallet
+- `6093aa1` Qt: QProgressBar CPU-Issue workaround
+- `0ed9675` [Wallet] Add global boolean whether to send free transactions (default=true)
+- `ed3e5e4` [Wallet] Add global boolean whether to pay at least the custom fee (default=true)
+- `e7876b2` [Wallet] Prevent user from paying a non-sense fee
+- `c1c9d5b` Add Smartfee to GUI
+- `e0a25c5` Make askpassphrase dialog behave more sanely
+- `94b362d` On close of splashscreen interrupt verifyDB
+- `b790d13` English translation update
+- `8543b0d` Correct tooltip on address book page
+
+Tests:
+- `b41e594` Fix script test handling of empty scripts
+- `d3a33fc` Test CHECKMULTISIG with m == 0 and n == 0
+- `29c1749` Let tx (in)valid tests use any SCRIPT_VERIFY flag
+- `6380180` Add rejection of non-null CHECKMULTISIG dummy values
+- `21bf3d2` Add tests for BoostAsioToCNetAddr
+- `b5ad5e7` Add Python test for -rpcbind and -rpcallowip
+- `9ec0306` Add CODESEPARATOR/FindAndDelete() tests
+- `75ebced` Added many rpc wallet tests
+- `0193fb8` Allow multiple regression tests to run at once
+- `92a6220` Hook up sanity checks
+- `3820e01` Extend and move all crypto tests to crypto_tests.cpp
+- `3f9a019` added list/get received by address/ account tests
+- `a90689f` Remove timing-based signature cache unit test
+- `236982c` Add skiplist unit tests
+- `f4b00be` Add CChain::GetLocator() unit test
+- `b45a6e8` Add test for getblocktemplate longpolling
+- `cdf305e` Set -discover=0 in regtest framework
+- `ed02282` additional test for OP_SIZE in script_valid.json
+- `0072d98` script tests: BOOLAND, BOOLOR decode to integer
+- `833ff16` script tests: values that overflow to 0 are true
+- `4cac5db` script tests: value with trailing 0x00 is true
+- `89101c6` script test: test case for 5-byte bools
+- `d2d9dc0` script tests: add tests for CHECKMULTISIG limits
+- `d789386` Add "it works" test for bitcoin-tx
+- `df4d61e` Add bitcoin-tx tests
+- `aa41ac2` Test IsPushOnly() with invalid push
+- `6022b5d` Make `script_{valid,invalid}.json` validation flags configurable
+- `8138cbe` Add automatic script test generation, and actual checksig tests
+- `ed27e53` Add coins_tests with a large randomized CCoinViewCache test
+- `9df9cf5` Make SCRIPT_VERIFY_STRICTENC compatible with BIP62
+- `dcb9846` Extend getchaintips RPC test
+- `554147a` Ensure MINIMALDATA invalid tests can only fail one way
+- `dfeec18` Test every numeric-accepting opcode for correct handling of the numeric minimal encoding rule
+- `2b62e17` Clearly separate PUSHDATA and numeric argument MINIMALDATA tests
+- `16d78bd` Add valid invert of invalid every numeric opcode tests
+- `f635269` tests: enable alertnotify test for Windows
+- `7a41614` tests: allow rpc-tests to get filenames for bitcoind and bitcoin-cli from the environment
+- `5122ea7` tests: fix forknotify.py on windows
+- `fa7f8cd` tests: remove old pull-tester scripts
+- `7667850` tests: replace the old (unused since Travis) tests with new rpc test scripts
+- `f4e0aef` Do signature-s negation inside the tests
+- `1837987` Optimize -regtest setgenerate block generation
+- `2db4c8a` Fix node ranges in the test framework
+- `a8b2ce5` regression test only setmocktime RPC call
+- `daf03e7` RPC tests: create initial chain with specific timestamps
+- `8656dbb` Port/fix txnmall.sh regression test
+- `ca81587` Test the exact order of CHECKMULTISIG sig/pubkey evaluation
+- `7357893` Prioritize and display -testsafemode status in UI
+- `f321d6b` Add key generation/verification to ECC sanity check
+- `132ea9b` miner_tests: Disable checkpoints so they don't fail the subsidy-change test
+- `bc6cb41` QA RPC tests: Add tests block block proposals
+- `f67a9ce` Use deterministically generated script tests
+- `11d7a7d` [RPC] add rpc-test for http keep-alive (persistent connections)
+- `34318d7` RPC-test based on invalidateblock for mempool coinbase spends
+- `76ec867` Use actually valid transactions for script tests
+- `c8589bf` Add actual signature tests
+- `e2677d7` Fix smartfees test for change to relay policy
+- `263b65e` tests: run sanity checks in tests too
+
+Miscellaneous:
+- `122549f` Fix incorrect checkpoint data for testnet3
+- `5bd02cf` Log used config file to debug.log on startup
+- `68ba85f` Updated Debian example bitcoin.conf with config from wiki + removed some cruft and updated comments
+- `e5ee8f0` Remove -beta suffix
+- `38405ac` Add comment regarding experimental-use service bits
+- `be873f6` Issue warning if collecting RandSeed data failed
+- `8ae973c` Allocate more space if necessary in RandSeedAddPerfMon
+- `675bcd5` Correct comment for 15-of-15 p2sh script size
+- `fda3fed` libsecp256k1 integration
+- `2e36866` Show nodeid instead of addresses in log (for anonymity) unless otherwise requested
+- `cd01a5e` Enable paranoid corruption checks in LevelDB >= 1.16
+- `9365937` Add comment about never updating nTimeOffset past 199 samples
+- `403c1bf` contrib: remove getwork-based pyminer (as getwork API call has been removed)
+- `0c3e101` contrib: Added systemd .service file in order to help distributions integrate bitcoind
+- `0a0878d` doc: Add new DNSseed policy
+- `2887bff` Update coding style and add .clang-format
+- `5cbda4f` Changed LevelDB cursors to use scoped pointers to ensure destruction when going out of scope
+- `b4a72a7` contrib/linearize: split output files based on new-timestamp-year or max-file-size
+- `e982b57` Use explicit fflush() instead of setvbuf()
+- `234bfbf` contrib: Add init scripts and docs for Upstart and OpenRC
+- `01c2807` Add warning about the merkle-tree algorithm duplicate txid flaw
+- `d6712db` Also create pid file in non-daemon mode
+- `772ab0e` contrib: use batched JSON-RPC in linarize-hashes (optimization)
+- `7ab4358` Update bash-completion for v0.10
+- `6e6a36c` contrib: show pull # in prompt for github-merge script
+- `5b9f842` Upgrade leveldb to 1.18, make chainstate databases compatible between ARM and x86 (issue #2293)
+- `4e7c219` Catch UTXO set read errors and shutdown
+- `867c600` Catch LevelDB errors during flush
+- `06ca065` Fix CScriptID(const CScript& in) in empty script case
+
+Credits
+=======
+
+Thanks to everyone who contributed to this release:
+
+- 21E14
+- Adam Weiss
+- Aitor Pazos
+- Alexander Jeng
+- Alex Morcos
+- Alon Muroch
+- Andreas Schildbach
+- Andrew Poelstra
+- Andy Alness
+- Ashley Holman
+- Benedict Chan
+- Ben Holden-Crowther
+- Bryan Bishop
+- BtcDrak
+- Christian von Roques
+- Clinton Christian
+- Cory Fields
+- Cozz Lovan
+- daniel
+- Daniel Kraft
+- David Hill
+- Derek701
+- dexX7
+- dllud
+- Dominyk Tiller
+- Doug
+- elichai
+- elkingtowa
+- ENikS
+- Eric Shaw
+- Federico Bond
+- Francis GASCHET
+- Gavin Andresen
+- Giuseppe Mazzotta
+- Glenn Willen
+- Gregory Maxwell
+- gubatron
+- HarryWu
+- himynameismartin
+- Huang Le
+- Ian Carroll
+- imharrywu
+- Jameson Lopp
+- Janusz Lenar
+- JaSK
+- Jeff Garzik
+- JL2035
+- Johnathan Corgan
+- Jonas Schnelli
+- jtimon
+- Julian Haight
+- Kamil Domanski
+- kazcw
+- kevin
+- kiwigb
+- Kosta Zertsekel
+- LongShao007
+- Luke Dashjr
+- Mark Friedenbach
+- Mathy Vanvoorden
+- Matt Corallo
+- Matthew Bogosian
+- Micha
+- Michael Ford
+- Mike Hearn
+- mrbandrews
+- mruddy
+- ntrgn
+- Otto Allmendinger
+- paveljanik
+- Pavel Vasin
+- Peter Todd
+- phantomcircuit
+- Philip Kaufmann
+- Pieter Wuille
+- pryds
+- randy-waterhouse
+- R E Broadley
+- Rose Toomey
+- Ross Nicoll
+- Roy Badami
+- Ruben Dario Ponticelli
+- Rune K. Svendsen
+- Ryan X. Charles
+- Saivann
+- sandakersmann
+- SergioDemianLerner
+- shshshsh
+- sinetek
+- Stuart Cardall
+- Suhas Daftuar
+- Tawanda Kembo
+- Teran McKinney
+- tm314159
+- Tom Harding
+- Trevin Hofmann
+- Whit J
+- Wladimir J. van der Laan
+- Yoichi Hirai
+- Zak Wilcox
+
+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.10.1.md b/doc/release-notes/release-notes-0.10.1.md
new file mode 100644
index 0000000000..5e939600a0
--- /dev/null
+++ b/doc/release-notes/release-notes-0.10.1.md
@@ -0,0 +1,143 @@
+Bitcoin Core version 0.10.1 is now available from:
+
+ <https://bitcoin.org/bin/bitcoin-core-0.10.1/>
+
+This is a new minor version release, bringing bug fixes and translation
+updates. It is recommended to upgrade to this version.
+
+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
+===============
+
+This is a minor release and hence there are no notable changes.
+For the notable changes in 0.10, refer to the release notes for the
+0.10.0 release at https://github.com/bitcoin/bitcoin/blob/v0.10.0/doc/release-notes.md
+
+0.10.1 Change log
+=================
+
+Detailed release notes follow. This overview includes changes that affect external
+behavior, not code moves, refactors or string updates.
+
+RPC:
+- `7f502be` fix crash: createmultisig and addmultisigaddress
+- `eae305f` Fix missing lock in submitblock
+
+Block (database) and transaction handling:
+- `1d2cdd2` Fix InvalidateBlock to add chainActive.Tip to setBlockIndexCandidates
+- `c91c660` fix InvalidateBlock to repopulate setBlockIndexCandidates
+- `002c8a2` fix possible block db breakage during re-index
+- `a1f425b` Add (optional) consistency check for the block chain data structures
+- `1c62e84` Keep mempool consistent during block-reorgs
+- `57d1f46` Fix CheckBlockIndex for reindex
+- `bac6fca` Set nSequenceId when a block is fully linked
+
+P2P protocol and network code:
+- `78f64ef` don't trickle for whitelisted nodes
+- `ca301bf` Reduce fingerprinting through timestamps in 'addr' messages.
+- `200f293` Ignore getaddr messages on Outbound connections.
+- `d5d8998` Limit message sizes before transfer
+- `aeb9279` Better fingerprinting protection for non-main-chain getdatas.
+- `cf0218f` Make addrman's bucket placement deterministic (countermeasure 1 against eclipse attacks, see http://cs-people.bu.edu/heilman/eclipse/)
+- `0c6f334` Always use a 50% chance to choose between tried and new entries (countermeasure 2 against eclipse attacks)
+- `214154e` Do not bias outgoing connections towards fresh addresses (countermeasure 2 against eclipse attacks)
+- `aa587d4` Scale up addrman (countermeasure 6 against eclipse attacks)
+- `139cd81` Cap nAttempts penalty at 8 and switch to pow instead of a division loop
+
+Validation:
+- `d148f62` Acquire CCheckQueue's lock to avoid race condition
+
+Build system:
+- `8752b5c` 0.10 fix for crashes on OSX 10.6
+
+Wallet:
+- N/A
+
+GUI:
+- `2c08406` some mac specifiy cleanup (memory handling, unnecessary code)
+- `81145a6` fix OSX dock icon window reopening
+- `786cf72` fix a issue where "command line options"-action overwrite "Preference"-action (on OSX)
+
+Tests:
+- `1117378` add RPC test for InvalidateBlock
+
+Miscellaneous:
+- `c9e022b` Initialization: set Boost path locale in main thread
+- `23126a0` Sanitize command strings before logging them.
+- `323de27` Initialization: setup environment before starting QT tests
+- `7494e09` Initialization: setup environment before starting tests
+- `df45564` Initialization: set fallback locale as environment variable
+
+Credits
+=======
+
+Thanks to everyone who directly contributed to this release:
+
+- Alex Morcos
+- Cory Fields
+- dexX7
+- fsb4000
+- Gavin Andresen
+- Gregory Maxwell
+- Ivan Pustogarov
+- Jonas Schnelli
+- Matt Corallo
+- mrbandrews
+- Pieter Wuille
+- Ruben de Vries
+- Suhas Daftuar
+- Wladimir J. van der Laan
+
+And all those who contributed additional code review and/or security research:
+- 21E14
+- Alison Kendler
+- Aviv Zohar
+- Ethan Heilman
+- Evil-Knievel
+- fanquake
+- Jeff Garzik
+- Jonas Nick
+- Luke Dashjr
+- Patrick Strateman
+- Philip Kaufmann
+- Sergio Demian Lerner
+- Sharon Goldberg
+
+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.10.2.md b/doc/release-notes/release-notes-0.10.2.md
new file mode 100644
index 0000000000..192ed69d29
--- /dev/null
+++ b/doc/release-notes/release-notes-0.10.2.md
@@ -0,0 +1,86 @@
+Bitcoin Core version 0.10.2 is now available from:
+
+ <https://bitcoin.org/bin/bitcoin-core-0.10.2/>
+
+This is a new minor version release, bringing minor bug fixes and translation
+updates. It is recommended to upgrade to this version.
+
+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
+===============
+
+This fixes a serious problem on Windows with data directories that have non-ASCII
+characters (https://github.com/bitcoin/bitcoin/issues/6078).
+
+For other platforms there are no notable changes.
+
+For the notable changes in 0.10, refer to the release notes
+at https://github.com/bitcoin/bitcoin/blob/v0.10.0/doc/release-notes.md
+
+0.10.2 Change log
+=================
+
+Detailed release notes follow. This overview includes changes that affect external
+behavior, not code moves, refactors or string updates.
+
+Wallet:
+- `824c011` fix boost::get usage with boost 1.58
+
+Miscellaneous:
+- `da65606` Avoid crash on start in TestBlockValidity with gen=1.
+- `424ae66` don't imbue boost::filesystem::path with locale "C" on windows (fixes #6078)
+
+Credits
+=======
+
+Thanks to everyone who directly contributed to this release:
+
+- Cory Fields
+- Gregory Maxwell
+- Jonas Schnelli
+- Wladimir J. van der Laan
+
+And all those who contributed additional code review and/or security research:
+
+- dexX7
+- Pieter Wuille
+- vayvanne
+
+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.9.4.md b/doc/release-notes/release-notes-0.9.4.md
new file mode 100644
index 0000000000..7ee73246a9
--- /dev/null
+++ b/doc/release-notes/release-notes-0.9.4.md
@@ -0,0 +1,95 @@
+Bitcoin Core version 0.9.4 is now available from:
+
+ https://bitcoin.org/bin/0.9.4/
+
+This is a new minor version release, bringing only bug fixes and updated
+translations. Upgrading to this release is recommended.
+
+Please report bugs using the issue tracker at github:
+
+ https://github.com/bitcoin/bitcoin/issues
+
+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).
+
+OpenSSL Warning
+================
+
+OpenSSL 1.0.0p / 1.0.1k was recently released and is being pushed out by
+various operating system maintainers. Review by Gregory Maxwell determined that
+this update is incompatible with the Bitcoin system and could lead to consensus
+forks.
+
+Bitcoin Core released binaries from https://bitcoin.org are unaffected,
+as are any built with the gitian deterministic build system.
+
+However, if you are running either
+
+- The Ubuntu PPA from https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin
+- A third-party or self-compiled Bitcoin Core
+
+upgrade to Bitcoin Core 0.9.4, which includes a workaround, **before** updating
+OpenSSL.
+
+The incompatibility is due to the OpenSSL update changing the
+behavior of ECDSA validation to reject any signature which is
+not encoded in a very rigid manner. This was a result of
+OpenSSL's change for CVE-2014-8275 "Certificate fingerprints
+can be modified".
+
+We are specifically aware of potential hard-forks due to signature
+encoding handling and had been hoping to close them via BIP62 in 0.10.
+BIP62's purpose is to improve transaction malleability handling and
+as a side effect rigidly defines the encoding for signatures, but the
+overall scope of BIP62 has made it take longer than we'd like to
+deploy.
+
+0.9.4 changelog
+================
+
+Validation:
+- `b8e81b7` consensus: guard against openssl's new strict DER checks
+- `60c51f1` fail immediately on an empty signature
+- `037bfef` Improve robustness of DER recoding code
+
+Command-line options:
+- `cd5164a` Make -proxy set all network types, avoiding a connect leak.
+
+P2P:
+- `bb424e4` Limit the number of new addressses to accumulate
+
+RPC:
+- `0a94661` Disable SSLv3 (in favor of TLS) for the RPC client and server.
+
+Build system:
+- `f047dfa` gitian: openssl-1.0.1i.tar.gz -> openssl-1.0.1k.tar.gz
+- `5b9f78d` build: Fix OSX build when using Homebrew and qt5
+- `ffab1dd` Keep symlinks when copying into .app bundle
+- `613247f` osx: fix signing to make Gatekeeper happy (again)
+
+Miscellaneous:
+- `25b49b5` Refactor -alertnotify code
+- `2743529` doc: Add instructions for consistent Mac OS X build names
+
+Credits
+--------
+
+Thanks to who contributed to this release, at least:
+
+- Cory Fields
+- Gavin Andresen
+- Gregory Maxwell
+- Jeff Garzik
+- Luke Dashjr
+- Matt Corallo
+- Pieter Wuille
+- Saivann
+- Sergio Demian Lerner
+- Wladimir J. van der Laan
+
+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.9.5.md b/doc/release-notes/release-notes-0.9.5.md
new file mode 100644
index 0000000000..bed0af9879
--- /dev/null
+++ b/doc/release-notes/release-notes-0.9.5.md
@@ -0,0 +1,60 @@
+Bitcoin Core version 0.9.5 is now available from:
+
+ https://bitcoin.org/bin/0.9.5/
+
+This is a new minor version release, with the goal of backporting BIP66. There
+are also a few bug fixes and updated translations. Upgrading to this release is
+recommended.
+
+Please report bugs using the issue tracker at github:
+
+ https://github.com/bitcoin/bitcoin/issues
+
+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).
+
+Notable changes
+================
+
+Mining and relay policy enhancements
+------------------------------------
+
+Bitcoin Core's block templates are now for version 3 blocks only, and any mining
+software relying on its `getblocktemplate` must be updated in parallel to use
+libblkmaker either version 0.4.2 or any version from 0.5.1 onward.
+If you are solo mining, this will affect you the moment you upgrade Bitcoin
+Core, which must be done prior to BIP66 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 BIP66
+achieving its 951/1001 status.
+
+0.9.5 changelog
+================
+
+- `74f29c2` Check pindexBestForkBase for null
+- `9cd1dd9` Fix priority calculation in CreateTransaction
+- `6b4163b` Sanitize command strings before logging them.
+- `3230b32` Raise version of created blocks, and enforce DERSIG in mempool
+- `989d499` Backport of some of BIP66's tests
+- `ab03660` Implement BIP 66 validation rules and switchover logic
+- `8438074` build: fix dynamic boost check when --with-boost= is used
+
+Credits
+--------
+
+Thanks to who contributed to this release, at least:
+
+- 21E14
+- Alex Morcos
+- Cory Fields
+- Gregory Maxwell
+- Pieter Wuille
+- Wladimir J. van der Laan
+
+As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
diff --git a/doc/release-process.md b/doc/release-process.md
index 30f9797752..5ecb9334f5 100644
--- a/doc/release-process.md
+++ b/doc/release-process.md
@@ -25,7 +25,7 @@ Release Process
###update gitian
- In order to take advantage of the new caching features in gitian, be sure to update to a recent version (e9741525c or higher is recommended)
+ In order to take advantage of the new caching features in gitian, be sure to update to a recent version (`e9741525c` or later is recommended)
###perform gitian builds
@@ -41,14 +41,16 @@ Release Process
###fetch and build 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)
- https://developer.apple.com/downloads/download.action?path=Developer_Tools/xcode_4.6.3/xcode4630916281a.dmg
+ 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.7 SDK and copy it to the inputs directory:
+ 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.7.sdk.tar.gz MacOSX10.7.sdk
+ 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
@@ -64,20 +66,21 @@ Release Process
./bin/gsign --signer $SIGNER --release ${VERSION}-linux --destination ../gitian.sigs/ ../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 --destination ../gitian.sigs/ ../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
+ 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
- mv build/out/bitcoin-*-unsigned.tar.gz inputs
+ 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:
1. source tarball (bitcoin-${VERSION}.tar.gz)
- 2. linux 32-bit and 64-bit binaries dist tarballs (bitcoin-${VERSION}-linux[32|64].tar.gz)
- 3. windows 32-bit and 64-bit installers and dist zips (bitcoin-${VERSION}-win[32|64]-setup.exe, bitcoin-${VERSION}-win[32|64].zip)
- 4. OSX unsigned installer (bitcoin-${VERSION}-osx-unsigned.dmg)
- 5. Gitian signatures (in gitian.sigs/${VERSION}-<linux|win|osx-unsigned>/(your gitian key)/
+ 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)/
###Next steps:
@@ -85,30 +88,38 @@ Commit your signature to gitian.sigs:
pushd gitian.sigs
git add ${VERSION}-linux/${SIGNER}
- git add ${VERSION}-win/${SIGNER}
+ git add ${VERSION}-win-unsigned/${SIGNER}
git add ${VERSION}-osx-unsigned/${SIGNER}
git commit -a
git push # Assuming you can push to the gitian.sigs tree
popd
- Wait for OSX detached signature:
- Once the OSX build has 3 matching signatures, Gavin will sign it with the apple App-Store key.
- He will then upload a detached signature to be combined with the unsigned app to create a signed binary.
+ 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.
Create the signed OSX binary:
pushd ./gitian-builder
- # Fetch the signature as instructed by Gavin
- cp signature.tar.gz inputs/
- ./bin/gbuild -i ../bitcoin/contrib/gitian-descriptors/gitian-osx-signer.yml
+ ./bin/gbuild -i --commit signature=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-osx-signer.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-osx-signed --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-osx-signer.yml
- mv build/out/bitcoin-${VERSION}-osx.dmg ../
+ mv build/out/bitcoin-osx-signed.dmg ../bitcoin-${VERSION}-osx.dmg
popd
-Commit your signature for the signed OSX binary:
+ Create the signed Windows binaries:
+
+ pushd ./gitian-builder
+ ./bin/gbuild -i --commit signature=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-win-signer.yml
+ ./bin/gsign --signer $SIGNER --release ${VERSION}-win-signed --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-win-signer.yml
+ mv build/out/bitcoin-*win64-setup.exe ../bitcoin-${VERSION}-win64-setup.exe
+ mv build/out/bitcoin-*win32-setup.exe ../bitcoin-${VERSION}-win32-setup.exe
+ popd
+
+Commit your signature for the signed OSX/Windows binaries:
pushd gitian.sigs
git add ${VERSION}-osx-signed/${SIGNER}
+ git add ${VERSION}-win-signed/${SIGNER}
git commit -a
git push # Assuming you can push to the gitian.sigs tree
popd
@@ -117,12 +128,6 @@ Commit your signature for the signed OSX binary:
### After 3 or more people have gitian-built and their results match:
-- Perform code-signing.
-
- - Code-sign Windows -setup.exe (in a Windows virtual machine using signtool)
-
- Note: only Gavin has the code-signing keys currently.
-
- Create `SHA256SUMS.asc` for the builds, and GPG-sign it:
```bash
sha256sum * > SHA256SUMS
@@ -130,17 +135,25 @@ gpg --digest-algo sha256 --clearsign SHA256SUMS # outputs SHA256SUMS.asc
rm SHA256SUMS
```
(the digest algorithm is forced to sha256 to avoid confusion of the `Hash:` header that GPG adds with the SHA256 used for the files)
+Note: check that SHA256SUMS itself doesn't end up in SHA256SUMS, which is a spurious/nonsensical entry.
- Upload zips and installers, as well as `SHA256SUMS.asc` from last step, to the bitcoin.org server
+ into `/var/www/bin/bitcoin-core-${VERSION}`
- Update bitcoin.org version
- - Make a pull request to add a file named `YYYY-MM-DD-vX.Y.Z.md` with the release notes
- to https://github.com/bitcoin/bitcoin.org/tree/master/_releases
- ([Example for 0.9.2.1](https://raw.githubusercontent.com/bitcoin/bitcoin.org/master/_releases/2014-06-19-v0.9.2.1.md)).
+ - First, check to see if the Bitcoin.org maintainers have prepared a
+ release: https://github.com/bitcoin/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
- - After the pull request is merged, the website will automatically show the newest version, as well
- as update the OS download links. Ping Saivann in case anything goes wrong
+ - 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
- Announce the release:
@@ -156,4 +169,4 @@ rm SHA256SUMS
- Add release notes for the new version to the directory `doc/release-notes` in git master
-- Celebrate
+- Celebrate
diff --git a/doc/translation_process.md b/doc/translation_process.md
index eed467706e..3653e53021 100644
--- a/doc/translation_process.md
+++ b/doc/translation_process.md
@@ -32,7 +32,7 @@ QToolBar *toolbar = addToolBar(tr("Tabs toolbar"));
### Creating a pull-request
For general PRs, you shouldn’t include any updates to the translation source files. They will be updated periodically, primarily around pre-releases, allowing time for any new phrases to be translated before public releases. This is also important in avoiding translation related merge conflicts.
-When an updated source file is merged into the Github repo, Transifex will automatically detect it (although it can take several hours). Once processed, the new strings will show up as "Remaining" in the Transifex web interface and are ready for translators.
+When an updated source file is merged into the Github repo, Transifex will automatically detect it (although it can take several hours). Once processed, the new strings will show up as "Remaining" in the Transifex web interface and are ready for translators.
To create the pull-request, use the following commands:
```
@@ -108,4 +108,4 @@ To create a new language template, you will need to edit the languages manifest
### Questions and general assistance
The Bitcoin-Core translation maintainers include *tcatm, seone, Diapolo, wumpus and luke-jr*.You can find them, and others, in the Freenode IRC chatroom - `irc.freenode.net #bitcoin-dev`.
-If you are a translator, you should also subscribe to the mailing list, https://groups.google.com/forum/#!forum/bitcoin-translators. Announcements will be posted during application pre-releases to notify translators to check for updates. \ No newline at end of file
+If you are a translator, you should also subscribe to the mailing list, https://groups.google.com/forum/#!forum/bitcoin-translators. Announcements will be posted during application pre-releases to notify translators to check for updates.
diff --git a/doc/translation_strings_policy.md b/doc/translation_strings_policy.md
new file mode 100644
index 0000000000..cf72a55b20
--- /dev/null
+++ b/doc/translation_strings_policy.md
@@ -0,0 +1,110 @@
+Translation Strings Policy
+===========================
+
+This document provides guidelines for internationalization of the Bitcoin Core software.
+
+How to translate?
+------------------
+
+To mark a message as translatable
+
+- In GUI source code (under `src/qt`): use `tr("...")`
+
+- In non-GUI source code (under `src`): use `_("...")`
+
+No internationalization is used for e.g. developer scripts outside `src`.
+
+Strings to be translated
+-------------------------
+
+On a high level, these strings are to be translated:
+
+- GUI strings, anything that appears in a dialog or window
+
+- Command-line option documentation
+
+### GUI strings
+
+Anything that appears to the user in the GUI is to be translated. This includes labels, menu items, button texts, tooltips and window titles.
+This includes messages passed to the GUI through the UI interface through `InitMessage`, `ThreadSafeMessageBox` or `ShowProgress`.
+
+### Command-line options
+
+Documentation for the command line options in the output of `--help` should be translated as well.
+
+Make sure that default values do not end up in the string, but use string formatting like `strprintf(_("Threshold for disconnecting misbehaving peers (default: %u)"), 100)`. Putting default values in strings has led to accidental translations in the past, and forces the string to be retranslated every time the value changes.
+
+Do not translate messages that are only shown to developers, such as those that only appear when `--help-debug` is used.
+
+General recommendations
+------------------------
+
+### Avoid unnecessary translation strings
+
+Try not to burden translators with translating messages that are e.g. slight variations of other messages.
+In the GUI, avoid the use of text where an icon or symbol will do.
+Make sure that placeholder texts in forms don't end up in the list of strings to be translated (use `<string notr="true">`).
+
+### Make translated strings understandable
+
+Try to write translation strings in an understandable way, for both the user and the translator. Avoid overly technical or detailed messages
+
+### Do not translate internal errors
+
+Do not translate internal errors, 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".
+This helps troubleshooting; if the error is the same for everyone, the likelihood is increased that it can be found using a search engine.
+
+### Avoid fragments
+
+Avoid dividing up a message into fragments. Translators see every string separately, so may misunderstand the context if the messages are not self-contained.
+
+### Avoid HTML in translation strings
+
+There have been difficulties with use of HTML in translation strings; translators should not be able to accidentally affect the formatting of messages.
+This may sometimes be at conflict with the recommendation in the previous section.
+
+### Plurals
+
+Plurals can be complex in some languages. A quote from the gettext documentation:
+
+ In Polish we use e.g. plik (file) this way:
+ 1 plik,
+ 2,3,4 pliki,
+ 5-21 pliko'w,
+ 22-24 pliki,
+ 25-31 pliko'w
+ and so on
+
+In Qt code use tr's third argument for optional plurality. For example:
+
+ tr("%n hour(s)","",secs/HOUR_IN_SECONDS);
+ tr("%n day(s)","",secs/DAY_IN_SECONDS);
+ tr("%n week(s)","",secs/WEEK_IN_SECONDS);
+
+This adds `<numerusform>`s to the respective `.ts` file, which can be translated separately depending on the language. In English, this is simply:
+
+ <message numerus="yes">
+ <source>%n active connection(s) to Bitcoin network</source>
+ <translation>
+ <numerusform>%n active connection to Bitcoin network</numerusform>
+ <numerusform>%n active connections to Bitcoin network</numerusform>
+ </translation>
+ </message>
+
+Where it is possible try to avoid embedding numbers into the flow of the string at all. e.g.
+
+ WARNING: check your network connection, %d blocks received in the last %d hours (%d expected)
+
+versus
+
+ WARNING: check your network connection, less blocks (%d) were received in the last %n hours than expected (%d).
+
+The second example reduces the number of pluralized words that translators have to handle from three to one, at no cost to comprehensibility of the sentence.
+
+### String freezes
+
+During a string freeze (often before a major release), no translation strings are to be added, modified or removed.
+
+This can be checked by executing `make translate` in the `src` directory, then verifying that `bitcoin_en.ts` remains unchanged.
+
diff --git a/doc/unit-tests.md b/doc/unit-tests.md
index f1d3a8bc50..72613054b9 100644
--- a/doc/unit-tests.md
+++ b/doc/unit-tests.md
@@ -12,7 +12,7 @@ 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
implement new BOOST_AUTO_TEST_SUITE sections.
-To run the bitcoin-qt tests manually, launch src/qt/test/bitcoin-qt_test
+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.