1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
(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.
`NODE_BLOOM` node 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 only enforced for peer 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.
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
|
