highperfocused/bitcoin
1
0
Fork 0
mirror of https://github.com/bitcoin/bitcoin.git synced 2025-11-12 23:18:14 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into single_prodname

Browse Source
This commit is contained in:
Luke Dashjr
2016-02-03 05:41:13 +00:00
parent 027fdb83b4 fd13fe7ca0
commit a68bb9f5e7
532 changed files with 26132 additions and 7549 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/Doxyfile
View File

@@ -34,7 +34,7 @@ PROJECT_NAME = Bitcoin
# This could be handy for archiving the generated documentation or
# if some version control system is used.
PROJECT_NUMBER = 0.11.99
PROJECT_NUMBER = 0.12.99
# Using the PROJECT_BRIEF tag one can provide an optional one line description
# for a project that appears at the top of each page and should give viewer

2
doc/README.md
View File

@@ -1,4 +1,4 @@
Bitcoin Core 0.11.99
Bitcoin Core 0.12.99
=====================
Setup

2
doc/README_windows.txt
View File

@@ -1,4 +1,4 @@
Bitcoin Core 0.11.99
Bitcoin Core 0.12.99
=====================
Intro

2
doc/bips.md
View File

@@ -18,3 +18,5 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.12.0**):
* [`BIP 66`](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki): The strict DER rules and associated version 3 blocks have been implemented since **v0.10.0** ([PR #5713](https://github.com/bitcoin/bitcoin/pull/5713)).
* [`BIP 70`](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki) [`71`](https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki) [`72`](https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki): Payment Protocol support has been available in Bitcoin Core GUI since **v0.9.0** ([PR #5216](https://github.com/bitcoin/bitcoin/pull/5216)).
* [`BIP 111`](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki): `NODE_BLOOM` service bit added, but only enforced for peer versions `>=70011` as of **v0.12.0** ([PR #6579](https://github.com/bitcoin/bitcoin/pull/6579)).
* [`BIP 125`](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki): Opt-in full replace-by-fee signaling honoured in mempool and mining as of **v0.12.0** ([PR 6871](https://github.com/bitcoin/bitcoin/pull/6871)).
* [`BIP 130`](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki): direct headers announcement is negotiated with peer versions `>=70012` as of **v0.12.0** ([PR 6494](https://github.com/bitcoin/bitcoin/pull/6494)).

20
doc/build-osx.md
View File

@@ -5,7 +5,7 @@ This guide will show you how to build bitcoind (headless client) for OS X.
Notes
-----
* Tested on OS X 10.7 through 10.10 on 64-bit Intel processors only.
* Tested on OS X 10.7 through 10.11 on 64-bit Intel processors only.
* All of the commands should be executed in a Terminal application. The
built-in one is located in `/Applications/Utilities`.
@@ -24,7 +24,7 @@ be re-done or updated every time Xcode is updated.
You will also need to install [Homebrew](http://brew.sh) in order to install library
dependencies.
The installation of the actual dependencies is covered in the Instructions
The installation of the actual dependencies is covered in the instructions
sections below.
Instructions: Homebrew
@@ -36,17 +36,19 @@ Instructions: Homebrew
NOTE: Building with Qt4 is still supported, however, could result in a broken UI. As such, building with Qt5 is recommended.
### Building `bitcoind`
### Building `bitcoin`
1. Clone the GitHub tree to get the source code and go into the directory.
git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin
2. Build bitcoind:
2. Build bitcoin-core:
This will configure and build the headless bitcoin binaries as well as the gui (if Qt is found).
You can disable the gui build by passing `--without-gui` to configure.
./autogen.sh
./configure --with-gui=qt5
./configure
make
3. It is also a good idea to build and run the unit tests:
@@ -60,10 +62,10 @@ NOTE: Building with Qt4 is still supported, however, could result in a broken UI
Use Qt Creator as IDE
------------------------
You can use Qt Creator as IDE, for debugging and for manipulating forms, etc.
Download Qt Creator from http://www.qt.io/download/. Download the "community edition" and only install Qt Creator (uncheck the rest during the installation process).
Download Qt Creator from https://www.qt.io/download/. Download the "community edition" and only install Qt Creator (uncheck the rest during the installation process).
1. Make sure you installed everything through Homebrew mentioned above
2. Do a proper ./configure --with-gui=qt5 --enable-debug
2. Do a proper ./configure --enable-debug
3. In Qt Creator do "New Project" -> Import Project -> Import Existing Project
4. Enter "bitcoin-qt" as project name, enter src/qt as location
5. Leave the file selection as it is
@@ -79,7 +81,7 @@ You can ignore this section if you are building `bitcoind` for your own use.
bitcoind/bitcoin-cli binaries are not included in the Bitcoin-Qt.app bundle.
If you are building `bitcoind` or `Bitcoin-Qt` for others, your build machine should be set up
If you are building `bitcoind` or `Bitcoin Core` for others, your build machine should be set up
as follows for maximum compatibility:
All dependencies should be compiled with these flags:
@@ -88,7 +90,7 @@ All dependencies should be compiled with these flags:
-arch x86_64
-isysroot $(xcode-select --print-path)/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
Once dependencies are compiled, see [doc/release-process.md](release-process.md) for how the Bitcoin-Qt.app
Once dependencies are compiled, see [doc/release-process.md](release-process.md) for how the Bitcoin Core
bundle is packaged and signed to create the .dmg disk image that is distributed.
Running

19
doc/build-unix.md
View File

@@ -50,18 +50,21 @@ Optional dependencies:
For the versions used in the release, see [release-process.md](release-process.md) under *Fetch and build inputs*.
System requirements
Memory Requirements
--------------------
C++ compilers are memory-hungry. It is recommended to have at least 1 GB of
memory available when compiling Bitcoin Core. With 512MB of memory or less
compilation will take much longer due to swap thrashing.
C++ compilers are memory-hungry. It is recommended to have at least 1.5 GB of
memory available when compiling Bitcoin Core. On systems with less, gcc can be
tuned to conserve memory with additional CXXFLAGS:
./configure CXXFLAGS="--param ggc-min-expand=1 --param ggc-min-heapsize=32768"
Dependency Build Instructions: Ubuntu & Debian
----------------------------------------------
Build requirements:
sudo apt-get install build-essential libtool autotools-dev autoconf pkg-config libssl-dev libevent-dev bsdmainutils
sudo apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils
On at least Ubuntu 14.04+ and Debian 7+ there are generic names for the
individual boost development packages, so the following can be used to only
@@ -236,3 +239,9 @@ In this case there is no dependency on Berkeley DB 4.8.
Mining is also possible in disable-wallet mode, but only using the `getblocktemplate` RPC
call not `getwork`.
Additional Configure Flags
--------------------------
A list of additional configure flags can be displayed with:
./configure --help

169
doc/developer-notes.md
View File

@@ -204,3 +204,172 @@ If a set of tools is used by the build system or scripts the repository (for
example, lcov) it is perfectly acceptable to add its files to `.gitignore`
and commit them.
Development guidelines
============================
A few non-style-related recommendations for developers, as well as points to
pay attention to for reviewers of Bitcoin Core code.
General Bitcoin Core
----------------------
- New features should be exposed on RPC first, then can be made available in the GUI
- *Rationale*: RPC allows for better automatic testing. The test suite for
the GUI is very limited
- Make sure pull requests pass Travis CI before merging
- *Rationale*: Makes sure that they pass thorough testing, and that the tester will keep passing
on the master branch. Otherwise all new pull requests will start failing the tests, resulting in
confusion and mayhem
- *Explanation*: If the test suite is to be updated for a change, this has to
be done first
Wallet
-------
- Make sure that no crashes happen with run-time option `-disablewallet`.
- *Rationale*: In RPC code that conditionally uses the wallet (such as
`validateaddress`) it is easy to forget that global pointer `pwalletMain`
can be NULL. See `qa/rpc-tests/disablewallet.py` for functional tests
exercising the API with `-disablewallet`
- Include `db_cxx.h` (BerkeleyDB header) only when `ENABLE_WALLET` is set
- *Rationale*: Otherwise compilation of the disable-wallet build will fail in environments without BerkeleyDB
General C++
-------------
- Assertions should not have side-effects
- *Rationale*: Even though the source code is set to to refuse to compile
with assertions disabled, having side-effects in assertions is unexpected and
makes the code harder to understand
- If you use the `.h`, you must link the `.cpp`
- *Rationale*: Include files define the interface for the code in implementation files. Including one but
not linking the other is confusing. Please avoid that. Moving functions from
the `.h` to the `.cpp` should not result in build errors
- Use the RAII (Resource Acquisition Is Initialization) paradigm where possible. For example by using
`scoped_pointer` for allocations in a function.
- *Rationale*: This avoids memory and resource leaks, and ensures exception safety
C++ data structures
--------------------
- Never use the `std::map []` syntax when reading from a map, but instead use `.find()`
- *Rationale*: `[]` does an insert (of the default element) if the item doesn't
exist in the map yet. This has resulted in memory leaks in the past, as well as
race conditions (expecting read-read behavior). Using `[]` is fine for *writing* to a map
- Do not compare an iterator from one data structure with an iterator of
another data structure (even if of the same type)
- *Rationale*: Behavior is undefined. In C++ parlor this means "may reformat
the universe", in practice this has resulted in at least one hard-to-debug crash bug
- Watch out for vector out-of-bounds exceptions. `&vch[0]` is illegal for an
empty vector, `&vch[vch.size()]` is always illegal. Use `begin_ptr(vch)` and
`end_ptr(vch)` to get the begin and end pointer instead (defined in
`serialize.h`)
- Vector bounds checking is only enabled in debug mode. Do not rely on it
- Make sure that constructors initialize all fields. If this is skipped for a
good reason (i.e., optimization on the critical path), add an explicit
comment about this
- *Rationale*: Ensure determinism by avoiding accidental use of uninitialized
values. Also, static analyzers balk about this.
- Use explicitly signed or unsigned `char`s, or even better `uint8_t` and
`int8_t`. Do not use bare `char` unless it is to pass to a third-party API.
This type can be signed or unsigned depending on the architecture, which can
lead to interoperability problems or dangerous conditions such as
out-of-bounds array accesses
- Prefer explicit constructions over implicit ones that rely on 'magical' C++ behavior
- *Rationale*: Easier to understand what is happening, thus easier to spot mistakes, even for those
that are not language lawyers
Strings and formatting
------------------------
- Be careful of `LogPrint` versus `LogPrintf`. `LogPrint` takes a `category` argument, `LogPrintf` does not.
- *Rationale*: Confusion of these can result in runtime exceptions due to
formatting mismatch, and it is easy to get wrong because of subtly similar naming
- Use `std::string`, avoid C string manipulation functions
- *Rationale*: C++ string handling is marginally safer, less scope for
buffer overflows and surprises with `\0` characters. Also some C string manipulations
tend to act differently depending on platform, or even the user locale
- Use `ParseInt32`, `ParseInt64`, `ParseDouble` from `utilstrencodings.h` for number parsing
- *Rationale*: These functions do overflow checking, and avoid pesky locale issues
- For `strprintf`, `LogPrint`, `LogPrintf` formatting characters don't need size specifiers
- *Rationale*: Bitcoin Core uses tinyformat, which is type safe. Leave them out to avoid confusion
Threads and synchronization
----------------------------
- Build and run tests with `-DDEBUG_LOCKORDER` to verify that no potential
deadlocks are introduced. As of 0.12, this is defined by default when
configuring with `--enable-debug`
- When using `LOCK`/`TRY_LOCK` be aware that the lock exists in the context of
the current scope, so surround the statement and the code that needs the lock
with braces
OK:
```c++
{
TRY_LOCK(cs_vNodes, lockNodes);
...
}
```
Wrong:
```c++
TRY_LOCK(cs_vNodes, lockNodes);
{
...
}
```
Source code organization
--------------------------
- Implementation code should go into the `.cpp` file and not the `.h`, unless necessary due to template usage or
when performance due to inlining is critical
- *Rationale*: Shorter and simpler header files are easier to read, and reduce compile time
- Don't import anything into the global namespace (`using namespace ...`). Use
fully specified types such as `std::string`.
- *Rationale*: Avoids symbol conflicts
GUI
-----
- Do not display or manipulate dialogs in model code (classes `*Model`)
- *Rationale*: Model classes pass through events and data from the core, they
should not interact with the user. That's where View classes come in. The converse also
holds: try to not directly access core data structures from Views.

11
doc/gitian-building.md
View File

@@ -74,11 +74,11 @@ In the VirtualBox GUI click "Create" and choose the following parameters in the
- File location and size: at least 40GB; as low as 20GB *may* be possible, but better to err on the safe side
- Click `Create`
Get the [Debian 8.x net installer](http://cdimage.debian.org/debian-cd/8.2.0/amd64/iso-cd/debian-8.2.0-amd64-netinst.iso) (a more recent minor version should also work, see also [Debian Network installation](https://www.debian.org/CD/netinst/)).
Get the [Debian 8.x net installer](http://cdimage.debian.org/debian-cd/8.3.0/amd64/iso-cd/debian-8.3.0-amd64-netinst.iso) (a more recent minor version should also work, see also [Debian Network installation](https://www.debian.org/CD/netinst/)).
This DVD image can be validated using a SHA256 hashing tool, for example on
Unixy OSes by entering the following in a terminal:
echo "d393d17ac6b3113c81186e545c416a00f28ed6e05774284bb5e8f0df39fcbcb9 debian-8.2.0-amd64-netinst.iso" | sha256sum -c
echo "dd25bcdde3c6ea5703cc0f313cde621b13d42ff7d252e2538a11663c93bf8654 debian-8.3.0-amd64-netinst.iso" | sha256sum -c
# (must return OK)
After creating the VM, we need to configure it.
@@ -259,15 +259,15 @@ adduser debian sudo
Then set up LXC and the rest with the following, which is a complex jumble of settings and workarounds:
```bash
# the version of lxc-start in Debian 7.4 needs to run as root, so make sure
# the version of lxc-start in Debian needs to run as root, so make sure
# that the build script can execute it without providing a password
echo "%sudo ALL=NOPASSWD: /usr/bin/lxc-start" > /etc/sudoers.d/gitian-lxc
# add cgroup for LXC
echo "cgroup /sys/fs/cgroup cgroup defaults 0 0" >> /etc/fstab
# make /etc/rc.local script that sets up bridge between guest and host
echo '#!/bin/sh -e' > /etc/rc.local
echo 'brctl addbr br0' >> /etc/rc.local
echo 'ifconfig br0 10.0.3.2/24 up' >> /etc/rc.local
echo 'iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE' >> /etc/rc.local
echo 'echo 1 > /proc/sys/net/ipv4/ip_forward' >> /etc/rc.local
echo 'exit 0' >> /etc/rc.local
# make sure that USE_LXC is always set when logging in as debian,
# and configure LXC IP addresses
@@ -305,6 +305,7 @@ Clone the git repositories for bitcoin and Gitian.
```bash
git clone https://github.com/devrandom/gitian-builder.git
git clone https://github.com/bitcoin/bitcoin
git clone https://github.com/bitcoin/gitian.sigs.git
```
Setting up the Gitian image

240
doc/release-notes.md
View File

@@ -4,208 +4,11 @@ release-notes at release time)
Notable changes
===============
SSL support for RPC dropped
----------------------------
Example item
----------------
SSL support for RPC, previously enabled by the option `rpcssl` has been dropped
from both the client and the server. This was done in preparation for removing
the dependency on OpenSSL for the daemon completely.
Trying to use `rpcssl` will result in an error:
Error: SSL mode for RPC (-rpcssl) is no longer supported.
If you are one of the few people that relies on this feature, a flexible
migration path is to use `stunnel`. This is an utility that can tunnel
arbitrary TCP connections inside SSL. On e.g. Ubuntu it can be installed with:
sudo apt-get install stunnel4
Then, to tunnel a SSL connection on 28332 to a RPC server bound on localhost on port 18332 do:
stunnel -d 28332 -r 127.0.0.1:18332 -p stunnel.pem -P ''
It can also be set up system-wide in inetd style.
Another way to re-attain SSL would be to setup a httpd reverse proxy. This solution
would allow the use of different authentication, loadbalancing, on-the-fly compression and
caching. A sample config for apache2 could look like:
Listen 443
NameVirtualHost *:443
<VirtualHost *:443>
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key
<Location /bitcoinrpc>
ProxyPass http://127.0.0.1:8332/
ProxyPassReverse http://127.0.0.1:8332/
# optional enable digest auth
# AuthType Digest
# ...
# optional bypass bitcoind rpc basic auth
# RequestHeader set Authorization "Basic <hash>"
# get the <hash> from the shell with: base64 <<< bitcoinrpc:<password>
</Location>
# Or, balance the load:
# ProxyPass / balancer://balancer_cluster_name
</VirtualHost>
Random-cookie RPC authentication
---------------------------------
When no `-rpcpassword` is specified, the daemon now uses a special 'cookie'
file for authentication. This file is generated with random content when the
daemon starts, and deleted when it exits. Its contents are used as
authentication token. Read access to this file controls who can access through
RPC. By default it is stored in the data directory but its location can be
overridden with the option `-rpccookiefile`.
This is similar to Tor's CookieAuthentication: see
https://www.torproject.org/docs/tor-manual.html.en
This allows running bitcoind without having to do any manual configuration.
Low-level RPC API changes
--------------------------
- Monetary amounts can be provided as strings. This means that for example the
argument to sendtoaddress can be "0.0001" instead of 0.0001. This can be an
advantage if a JSON library insists on using a lossy floating point type for
numbers, which would be dangerous for monetary amounts.
Option parsing behavior
-----------------------
Command line options are now parsed strictly in the order in which they are
specified. It used to be the case that `-X -noX` ends up, unintuitively, with X
set, as `-X` had precedence over `-noX`. This is no longer the case. Like for
other software, the last specified value for an option will hold.
`NODE_BLOOM` service bit
------------------------
Support for the `NODE_BLOOM` service bit, as described in [BIP
111](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki), has been
added to the P2P protocol code.
BIP 111 defines a service bit to allow peers to advertise that they support
bloom filters (such as used by SPV clients) explicitly. It also bumps the protocol
version to allow peers to identify old nodes which allow bloom filtering of the
connection despite lacking the new service bit.
In this version, it is only enforced for peers that send protocol versions
`>=70011`. For the next major version it is planned that this restriction will be
removed. It is recommended to update SPV clients to check for the `NODE_BLOOM`
service bit for nodes that report versions newer than 70011.
Any sequence of pushdatas in OP_RETURN outputs now allowed
----------------------------------------------------------
Previously OP_RETURN outputs with a payload were only relayed and mined if they
had a single pushdata. This restriction has been lifted to allow any
combination of data pushes and numeric constant opcodes (OP_1 to OP_16). The
limit on OP_RETURN output size is now applied to the entire serialized
scriptPubKey, 83 bytes by default. (the previous 80 byte default plus three
bytes overhead)
Merkle branches removed from wallet
-----------------------------------
Previously, every wallet transaction stored a Merkle branch to prove its
presence in blocks. This wasn't being used for more than an expensive
sanity check. Since 0.12, these are no longer stored. When loading a
0.12 wallet into an older version, it will automatically rescan to avoid
failed checks.
BIP65 - CHECKLOCKTIMEVERIFY
---------------------------
Previously it was impossible to create a transaction output that was guaranteed
to be unspendable until a specific date in the future. CHECKLOCKTIMEVERIFY is a
new opcode that allows a script to check if a specific block height or time has
been reached, failing the script otherwise. This enables a wide variety of new
functionality such as time-locked escrows, secure payment channels, etc.
BIP65 implements CHECKLOCKTIMEVERIFY by introducing block version 4, which adds
additional restrictions to the NOP2 opcode. The same miner-voting mechanism as
in BIP34 and BIP66 is used: when 751 out of a sequence of 1001 blocks have
version number 4 or higher, the new consensus rule becomes active for those
blocks. When 951 out of a sequence of 1001 blocks have version number 4 or
higher, it becomes mandatory for all blocks and blocks with versions less than
4 are rejected.
Bitcoin Core's block templates are now for version 4 blocks only, and any
mining software relying on its `getblocktemplate` must be updated in parallel
to use either libblkmaker version 0.4.3 or any version from 0.5.2 onward. If
you are solo mining, this will affect you the moment you upgrade Bitcoin Core,
which must be done prior to BIP65 achieving its 951/1001 status. If you are
mining with the stratum mining protocol: this does not affect you. If you are
mining with the getblocktemplate protocol to a pool: this will affect you at
the pool operator's discretion, which must be no later than BIP65 achieving its
951/1001 status.
Automatically listen on Tor
----------------------------
Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket
API, to create and destroy 'ephemeral' hidden services programmatically.
Bitcoin Core has been updated to make use of this.
This means that if Tor is running (and proper authorization is available),
Bitcoin Core automatically creates a hidden service to listen on, without
manual configuration. This will positively affect the number of available
.onion nodes.
This new feature is enabled by default if Bitcoin Core is listening, and
a connection to Tor can be made. It can be configured with the `-listenonion`,
`-torcontrol` and `-torpassword` settings. To show verbose debugging
information, pass `-debug=tor`.
Reduce upload traffic
---------------------
A major part of the outbound traffic is caused by serving historic blocks to
other nodes in initial block download state.
It is now possible to reduce the total upload traffic via the `-maxuploadtarget`
parameter. This is *not* a hard limit but a threshold to minimize the outbound
traffic. When the limit is about to be reached, the uploaded data is cut by not
serving historic blocks (blocks older than one week).
Moreover, any SPV peer is disconnected when they request a filtered block.
This option can be specified in MiB per day and is turned off by default
(`-maxuploadtarget=0`).
The recommended minimum is 144 * MAX_BLOCK_SIZE (currently 144MB) per day.
Whitelisted peers will never be disconnected, although their traffic counts for
calculating the target.
A more detailed documentation about keeping traffic low can be found in
[/doc/reducetraffic.md](/doc/reducetraffic.md).
Signature validation using libsecp256k1
---------------------------------------
ECDSA signatures inside Bitcoin transactions now use validation using
[https://github.com/bitcoin/secp256k1](libsecp256k1) instead of OpenSSL.
Depending on the platform, this means a significant speedup for raw signature
validation speed. The advantage is largest on x86_64, where validation is over
five times faster. In practice, this translates to a raw reindexing and new
block validation times that are less than half of what it was before.
Libsecp256k1 has undergone very extensive testing and validation.
A side effect of this change is that libconsensus no longer depends on OpenSSL.
0.12.0 Change log
0.13.0 Change log
=================
Detailed release notes follow. This overview includes changes that affect
@@ -215,33 +18,20 @@ git merge commit are mentioned.
### RPC and REST
Asm representations of scriptSig signatures now contain SIGHASH type decodes
----------------------------------------------------------------------------
Asm script outputs now contain OP_CHECKLOCKTIMEVERIFY in place of OP_NOP2
-------------------------------------------------------------------------
The `asm` property of each scriptSig now contains the decoded signature hash
type for each signature that provides a valid defined hash type.
OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP
65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki)
The following items contain assembly representations of scriptSig signatures
and are affected by this change:
- RPC `getrawtransaction`
The following outputs are affected by this change:
- RPC `getrawtransaction` (in verbose mode)
- RPC `decoderawtransaction`
- RPC `decodescript`
- REST `/rest/tx/` (JSON format)
- REST `/rest/block/` (JSON format when including extended tx details)
- `bitcoin-tx -json`
For example, the `scriptSig.asm` property of a transaction input that
previously showed an assembly representation of:
304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c509001
now shows as:
304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c5090[ALL]
Note that the output of the RPC `decodescript` did not change because it is
configured specifically to process scriptPubKey and not scriptSig scripts.
### Configuration and command-line options
### Block and transaction handling
@@ -260,13 +50,3 @@ configured specifically to process scriptPubKey and not scriptSig scripts.
### Miscellaneous
- Removed bitrpc.py from contrib
Addition of ZMQ-based Notifications
==================================
Bitcoind can now (optionally) asynchronously notify clients through a
ZMQ-based PUB socket of the arrival of new transactions and blocks.
This feature requires installation of the ZMQ C API library 4.x and
configuring its use through the command line or configuration file.
Please see docs/zmq.md for details of operation.

2
doc/release-notes/release-notes-0.6.3.md
View File

@@ -23,7 +23,7 @@ hundreds of blocks long.
Bitcoin-Qt no longer automatically selects the first address
in the address book (Issue #1384).
Fixed minimize-to-dock behavior of Bitcon-Qt on the Mac.
Fixed minimize-to-dock behavior of Bitcoin-Qt on the Mac.
Added a block checkpoint at block 185,333 to speed up initial
blockchain download.

33
doc/release-process.md
View File

@@ -41,6 +41,7 @@ Check out the source code in the following directory hierarchy.
pushd ./bitcoin
export SIGNER=(your Gitian key, ie bluematt, sipa, etc)
export VERSION=(new version, e.g. 0.8.0)
git fetch
git checkout v${VERSION}
popd
@@ -83,25 +84,16 @@ NOTE: Offline builds must use the --url flag to ensure Gitian fetches only from
```
The gbuild invocations below <b>DO NOT DO THIS</b> by default.
###Build (and optionally verify) Bitcoin Core for Linux, Windows, and OS X:
###Build and Sign Bitcoin Core for Linux, Windows, and OS X:
./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-linux --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-linux ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
mv build/out/bitcoin-*.tar.gz build/out/src/bitcoin-*.tar.gz ../
./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-win-unsigned --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
mv build/out/bitcoin-*-win-unsigned.tar.gz inputs/bitcoin-win-unsigned.tar.gz
mv build/out/bitcoin-*.zip build/out/bitcoin-*.exe ../
./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml
./bin/gsign --signer $SIGNER --release ${VERSION}-osx-unsigned --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml
./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml
mv build/out/bitcoin-*-osx-unsigned.tar.gz inputs/bitcoin-osx-unsigned.tar.gz
mv build/out/bitcoin-*.tar.gz build/out/bitcoin-*.dmg ../
popd
Build output expected:
@@ -111,6 +103,27 @@ The gbuild invocations below <b>DO NOT DO THIS</b> by default.
4. OS X unsigned installer and dist tarball (bitcoin-${VERSION}-osx-unsigned.dmg, bitcoin-${VERSION}-osx64.tar.gz)
5. Gitian signatures (in gitian.sigs/${VERSION}-<linux|{win,osx}-unsigned>/(your Gitian key)/
###Verify other gitian builders signatures to your own. (Optional)
Add other gitian builders keys to your gpg keyring
gpg --import ../bitcoin/contrib/gitian-downloader/*.pgp
Verify the signatures
./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-linux ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml
###Move the outputs to the correct directory
mv build/out/bitcoin-*.tar.gz build/out/src/bitcoin-*.tar.gz ../
mv build/out/bitcoin-*-win-unsigned.tar.gz inputs/bitcoin-win-unsigned.tar.gz
mv build/out/bitcoin-*.zip build/out/bitcoin-*.exe ../
mv build/out/bitcoin-*-osx-unsigned.tar.gz inputs/bitcoin-osx-unsigned.tar.gz
mv build/out/bitcoin-*.tar.gz build/out/bitcoin-*.dmg ../
popd
###Next steps:
Commit your signature to gitian.sigs:

6
doc/translation_process.md
View File

@@ -74,10 +74,10 @@ The Transifex Bitcoin project config file is included as part of the repo. It ca
To assist in updating translations, we have created a script to help.
1. `python contrib/devtools/update-translations.py`
2. Update `src/qt/bitcoin.qrc` manually or via
2. Update `src/qt/bitcoin_locale.qrc` manually or via
`ls src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/<file alias="\2">locale\/\1.qm<\/file>/'`
3. Update `src/qt/Makefile.am` manually or via
`ls src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/ locale\/\1.ts \\/'`
3. Update `src/Makefile.qt.include` manually or via
`ls src/qt/locale/*ts|xargs -n1 basename|sed 's/\(bitcoin_\(.*\)\).ts/ qt\/locale\/\1.ts \\/'`
4. `git add` new translations from `src/qt/locale/`
**Do not directly download translations** one by one from the Transifex website, as we do a few post-processing steps before committing the translations.

10
doc/unit-tests.md
View File

@@ -1,18 +1,18 @@
Compiling/running unit tests
------------------------------------
Unit tests will be automatically compiled if dependencies were met in configure
Unit tests will be automatically compiled if dependencies were met in `./configure`
and tests weren't explicitly disabled.
After configuring, they can be run with 'make check'.
After configuring, they can be run with `make check`.
To run the bitcoind tests manually, launch src/test/test_bitcoin .
To run the bitcoind tests manually, launch `src/test/test_bitcoin`.
To add more bitcoind tests, add `BOOST_AUTO_TEST_CASE` functions to the existing
.cpp files in the test/ directory or add new .cpp files that
.cpp files in the `test/` directory or add new .cpp files that
implement new BOOST_AUTO_TEST_SUITE sections.
To run the bitcoin-qt tests manually, launch src/qt/test/test_bitcoin-qt
To run the bitcoin-qt tests manually, launch `src/qt/test/test_bitcoin-qt`
To add more bitcoin-qt tests, add them to the `src/qt/test/` directory and
the `src/qt/test/test_main.cpp` file.