|
|
|
|
(note: this is a temporary file, to be added-to by anybody, and moved to
|
|
|
|
|
release-notes at release time)
|
|
|
|
|
|
|
|
|
|
Notable changes
|
|
|
|
|
===============
|
|
|
|
|
|
|
|
|
|
SSL support for RPC dropped
|
|
|
|
|
----------------------------
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
- Removed bitrpc.py from contrib
|
|
|
|
|
|
