diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/Doxyfile | 2 | ||||
| -rw-r--r-- | doc/README.md | 2 | ||||
| -rw-r--r-- | doc/README_windows.txt | 2 | ||||
| -rw-r--r-- | doc/bips.md | 1 | ||||
| -rw-r--r-- | doc/build-unix.md | 2 | ||||
| -rw-r--r-- | doc/release-notes.md | 268 |
6 files changed, 15 insertions, 262 deletions
diff --git a/doc/Doxyfile b/doc/Doxyfile index 925a33ee89..428fba98e1 100644 --- a/doc/Doxyfile +++ b/doc/Doxyfile @@ -34,7 +34,7 @@ PROJECT_NAME = Bitcoin # This could be handy for archiving the generated documentation or # if some version control system is used. -PROJECT_NUMBER = 0.11.99 +PROJECT_NUMBER = 0.12.99 # Using the PROJECT_BRIEF tag one can provide an optional one line description # for a project that appears at the top of each page and should give viewer diff --git a/doc/README.md b/doc/README.md index f6df28a89b..c0f9ee5220 100644 --- a/doc/README.md +++ b/doc/README.md @@ -1,4 +1,4 @@ -Bitcoin Core 0.11.99 +Bitcoin Core 0.12.99 ===================== Setup diff --git a/doc/README_windows.txt b/doc/README_windows.txt index e4fd9bdf90..2d1c4503c9 100644 --- a/doc/README_windows.txt +++ b/doc/README_windows.txt @@ -1,4 +1,4 @@ -Bitcoin Core 0.11.99
+Bitcoin Core 0.12.99
=====================
Intro
diff --git a/doc/bips.md b/doc/bips.md index 962b216123..e73add0130 100644 --- a/doc/bips.md +++ b/doc/bips.md @@ -18,4 +18,5 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.12.0**): * [`BIP 66`](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki): The strict DER rules and associated version 3 blocks have been implemented since **v0.10.0** ([PR #5713](https://github.com/bitcoin/bitcoin/pull/5713)). * [`BIP 70`](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki) [`71`](https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki) [`72`](https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki): Payment Protocol support has been available in Bitcoin Core GUI since **v0.9.0** ([PR #5216](https://github.com/bitcoin/bitcoin/pull/5216)). * [`BIP 111`](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki): `NODE_BLOOM` service bit added, but only enforced for peer versions `>=70011` as of **v0.12.0** ([PR #6579](https://github.com/bitcoin/bitcoin/pull/6579)). +* [`BIP 125`](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki): Opt-in full replace-by-fee signaling honoured in mempool and mining as of **v0.12.0** ([PR 6871](https://github.com/bitcoin/bitcoin/pull/6871)). * [`BIP 130`](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki): direct headers announcement is negotiated with peer versions `>=70012` as of **v0.12.0** ([PR 6494](https://github.com/bitcoin/bitcoin/pull/6494)). diff --git a/doc/build-unix.md b/doc/build-unix.md index 159a140608..31bbab7f0f 100644 --- a/doc/build-unix.md +++ b/doc/build-unix.md @@ -61,7 +61,7 @@ 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 diff --git a/doc/release-notes.md b/doc/release-notes.md index 96c830d177..801b684e6b 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -4,236 +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 use Tor hidden services -------------------------------------- - -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. Bitcoin Core will also use Tor automatically to connect -to other .onion nodes if the control socket can be successfully opened. This -will positively affect the number of available .onion nodes and their usage. - -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. - -Direct headers announcement (BIP 130) -------------------------------------- - -Between compatible peers, BIP 130 direct headers announcement is used. This -means that blocks are advertized by announcing their headers directly, instead -of just announcing the hash. In a reorganization, all new headers are sent, -instead of just the new tip. This can often prevent an extra roundtrip before -the actual block is downloaded. - -Negative confirmations and conflict detection ---------------------------------------------- - -The wallet will now report a negative number for confirmations that indicates -how deep in the block chain the conflict is found. For example, if a transaction -A has 5 confirmations and spends the same input as a wallet transaction B, B -will be reported as having -5 confirmations. If another wallet transaction C -spends an output from B, it will also be reported as having -5 confirmations. -To detect conflicts with historical transactions in the chain a one-time -`-rescan` may be needed. - -Unlike earlier versions, unconfirmed but non-conflicting transactions will never -get a negative confirmation count. They are not treated as spendable unless -they're coming from ourself (change) and accepted into our local mempool, -however. The new "trusted" field in the `listtransactions` RPC output -indicates whether outputs of an unconfirmed transaction are considered -spendable. - -0.12.0 Change log +0.13.0 Change log ================= Detailed release notes follow. This overview includes changes that affect @@ -243,33 +18,20 @@ git merge commit are mentioned. ### RPC and REST -Asm representations of scriptSig signatures now contain SIGHASH type decodes ----------------------------------------------------------------------------- - -The `asm` property of each scriptSig now contains the decoded signature hash -type for each signature that provides a valid defined hash type. +Asm script outputs now contain OP_CHECKLOCKTIMEVERIFY in place of OP_NOP2 +------------------------------------------------------------------------- -The following items contain assembly representations of scriptSig signatures -and are affected by this change: +OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP +65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) -- RPC `getrawtransaction` +The following outputs are affected by this change: +- RPC `getrawtransaction` (in verbose mode) - RPC `decoderawtransaction` +- RPC `decodescript` - REST `/rest/tx/` (JSON format) - REST `/rest/block/` (JSON format when including extended tx details) - `bitcoin-tx -json` -For example, the `scriptSig.asm` property of a transaction input that -previously showed an assembly representation of: - - 304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c509001 - -now shows as: - - 304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c5090[ALL] - -Note that the output of the RPC `decodescript` did not change because it is -configured specifically to process scriptPubKey and not scriptSig scripts. - ### Configuration and command-line options ### Block and transaction handling @@ -288,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. |