Now that 0.12 has been branched, master is 0.12.99

... in preparation for 0.13

configure.ac

@@ -1,7 +1,7 @@
 dnl require autoconf 2.60 (AS_ECHO/AS_ECHO_N)
 AC_PREREQ([2.60])
 define(_CLIENT_VERSION_MAJOR, 0)
-define(_CLIENT_VERSION_MINOR, 11)
+define(_CLIENT_VERSION_MINOR, 12)
 define(_CLIENT_VERSION_REVISION, 99)
 define(_CLIENT_VERSION_BUILD, 0)
 define(_CLIENT_VERSION_IS_RELEASE, false)

contrib/gitian-descriptors/gitian-linux.yml

@@ -1,5 +1,5 @@
 ---
-name: "bitcoin-linux-0.12"
+name: "bitcoin-linux-0.13"
 enable_cache: true
 suites:
 - "trusty"

contrib/gitian-descriptors/gitian-osx.yml

@@ -1,5 +1,5 @@
 ---
-name: "bitcoin-osx-0.12"
+name: "bitcoin-osx-0.13"
 enable_cache: true
 suites:
 - "trusty"

contrib/gitian-descriptors/gitian-win.yml

@@ -1,5 +1,5 @@
 ---
-name: "bitcoin-win-0.12"
+name: "bitcoin-win-0.13"
 enable_cache: true
 suites:
 - "trusty"

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 

doc/README.md

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

doc/README_windows.txt

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

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:
+0.13.0 Change log
-
-    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
 =================
 
 Detailed release notes follow. This overview includes changes that affect
@@ -243,33 +18,6 @@ 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.
-
-The following items contain assembly representations of scriptSig signatures
-and are affected by this change:
-
-- RPC `getrawtransaction`
-- RPC `decoderawtransaction`
-- 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 +36,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.

src/clientversion.h

@@ -15,7 +15,7 @@
 
 //! These need to be macros, as clientversion.cpp's and bitcoin*-res.rc's voodoo requires it
 #define CLIENT_VERSION_MAJOR 0
-#define CLIENT_VERSION_MINOR 11
+#define CLIENT_VERSION_MINOR 12
 #define CLIENT_VERSION_REVISION 99
 #define CLIENT_VERSION_BUILD 0