|
|
|
@ -4,236 +4,11 @@ release-notes at release time) |
|
|
|
Notable changes |
|
|
|
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 |
|
|
|
Detailed release notes follow. This overview includes changes that affect |
|
|
|
@ -243,33 +18,6 @@ git merge commit are mentioned. |
|
|
|
|
|
|
|
|
|
|
|
### RPC and REST |
|
|
|
### 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 |
|
|
|
### Configuration and command-line options |
|
|
|
|
|
|
|
|
|
|
|
### Block and transaction handling |
|
|
|
### Block and transaction handling |
|
|
|
@ -288,13 +36,3 @@ configured specifically to process scriptPubKey and not scriptSig scripts. |
|
|
|
|
|
|
|
|
|
|
|
### Miscellaneous |
|
|
|
### 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. |
|
|
|
|
|
|
|
|
Wladimir J. van der Laan
9 years ago